Use the Source Luke
Raymond Hettinger
source code links in their documentation:
http://rhettinger.wordpress.com/2011/01/28/open-your-source-more/
I'm looking for more examples of projects that routinely
link their docs back into relavant sections of code.
Have any of you all seen other examples besides
the Go language docs and the Python docs?
Raymond
Paul Rubin
> http://rhettinger.wordpress.com/2011/01/28/open-your-source-more/
>
> I'm looking for more examples of projects that routinely
> link their docs back into relavant sections of code.
> Have any of you all seen other examples besides
> the Go language docs and the Python docs?
That is a very good post, and just about 2 days ago I happened to be
looking at the source of heapq for something I was doing, and I think I
got to it through the doc link that you added. So the link has already
been useful.
Haddock (Haskell's equivalent to Pydoc or Javadoc) can automatically
generate source links in Haskell documentation. For example, here's the
docs (including source links) for Haskell's standard library for dealing
with lists:
http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/Data-List.html
I've wanted for a long time for developer-oriented Linux distributions
to include full source code of everything as an integral part of the
distro rather than as a separate distribution. For example, you could
examine any application and instantly see its source. All programs
would be compiled with debugging enabled and a way to attach a debugger
to the running process, so you could at any time interrupt the program
and use gdb to see what it was doing, single step it, etc.
Giampaolo Rodolà
> http://mail.python.org/mailman/listinfo/python-list
>
Thanks, I think this is a great idea.
I think this definitively should be done for 2.7 documentation as well.
--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
Rui Maciel
> Have any of you all seen other examples besides
> the Go language docs and the Python docs?
Wasn't doxygen developed with that in mind?
Rui Maciel
Ben Finney
> I hoping a new trend will start with dev's putting direct
> source code links in their documentation:
>
> http://rhettinger.wordpress.com/2011/01/28/open-your-source-more/
That's a good article overall.
I have a quibble with the framing:
> The rest of the blame lies with installers. They all treat
> human-readable scripts like they were binaries and tuck the code away
> in a dark corner.
That’s hardly a “blame” of installers. The modules are placed in such
locations because they need to be accessible in a hierarchy at a
location that is known to not conflict with anything else, and be
predictable for the Python interpreter on the system.
If you want to blame anything for this (though I think it’s inaccurate
to frame it as a problem), the correct target of your accusation is the
fact that a filesystem path is the identifier for these modules that
will be used by programs to find them.
As for reading the source and making it more available to programmers,
yes, I agree wholeheartedly. Encouraging the routine reading of other
projects’s source code is a good thing, and thank you for beating the
drum.
--
\ “I distrust those people who know so well what God wants them |
`\ to do to their fellows, because it always coincides with their |
_o__) own desires.” —Susan Brownell Anthony, 1896 |
Ben Finney
Jack Diederich
I think you overestimate how common it used to be to carry around the
sourcecode for the software you use compared to now; In the past it
wasn't even always possible - if the Sun cc compiler core dumps you
have no recourse to code. Promoting the idea of doing it is good
because it /is/ a novel idea to many people. Promoting the idea of
making it extremely easy via documentation links is good because it is
new as well.
Modern tools are making this easier than it used to be so your call
for making it easier still is well timed. Github/bitbucket/launchpad
have combined the source with documentation; github especially because
the README on github is the canonical documentation and the source is
only one mouse click away. ack-grep has changed my life. Sure, I
could always do the same thing in the past with find+grep but ack-grep
makes it so easy (switches for language file types!) that I use it
much more; I have "ag" aliased to "ack-grep --python" and I use it
all the f'ing time because it costs me near zero to do so. Likewise I
have an alias "cdp" that "cd"s me into the directory where any given
python module lives. "cdp collections" puts me straight into
"/usr/local/lib/python2.6" - again, it makes it so easy to look at
sourcecode that I do it all the time. It is usually quicker to do
cdp/python/import module_name/help(module_name) than to look up the
docs. Worst case the docstrings suck and I just read the code.
* Anecdote. I was in a room with Tim Peters and has some questions
about the interface to code he wrote so I thought "Hey, I'll just ask
Tim!" I asked him and he replied "I'm not sure what you're asking -
do you want me to read the code aloud to you?" So I just went and
read it.
-Jack
Ben Finney
> I think you overestimate how common it used to be to carry around the
> sourcecode for the software you use compared to now; In the past it
> wasn't even always possible - if the Sun cc compiler core dumps you
> have no recourse to code.
Note that Raymond is speaking specifically in the context of free
software, where the license is by definition permitting free
redistribution of the source code.
So it doesn't cover the case of things like the Sun C compiler, either
now or in the past.
> Promoting the idea of doing it is good because it /is/ a novel idea to
> many people. Promoting the idea of making it extremely easy via
> documentation links is good because it is new as well.
When one notes that the context is specifically free software projects,
the promotion of reading the source code is even more a good idea.
--
\ “This [Bush] Administration is not sinking. This Administration |
`\ is soaring. If anything they are rearranging the deck chairs on |
_o__) the Hindenburg.” —Steven Colbert, 2006-04-29 |
Ben Finney
Raymond Hettinger
> I think you overestimate how common it used to be to carry around the
> sourcecode for the software you use compared to now; In the past it
> wasn't even always possible - if the Sun cc compiler core dumps you
> have no recourse to code.
You're right of course. For the Python world though, there does seem
to have been a change. A decade ago in this newsgroup, there were
frequent references to standard library source. I don't see that
much anymore.
> Promoting the idea of doing it is good
> because it /is/ a novel idea to many people. Promoting the idea of
> making it extremely easy via documentation links is good because it is
> new as well.
Judging from the comments so far, it looks like everyone here agrees.
> Modern tools are making this easier than it used to be so your call
> for making it easier still is well timed. Github/bitbucket/launchpad
> have combined the source with documentation;
Do they typically feature multiple links from documentation specifics
to corresponding code specifics?
Part of my thesis is that it is not enough to make docs and source
available, they need to be linked in a way that helps people
answer specific problems without having to invest a week in learning
the gestalt of a foreign code base.
> Worst case the docstrings suck and I just read the code.
That's a good habit to have. I find that my willingness to do it
varies across projects -- I'm happy to look at the Mercurial source
but could never being myself to look at the innards of Git or CouchDB.
> * Anecdote. I was in a room with Tim Peters and has some questions
> about the interface to code he wrote so I thought "Hey, I'll just ask
> Tim!" I asked him and he replied "I'm not sure what you're asking -
> do you want me to read the code aloud to you?" So I just went and
> read it.
Thanks for the anecdote. I love that story :-)
Uncle Timmy's style is both clever and pointed.
Raymond
rusi
> Note that Raymond is speaking specifically in the context of free
> software, where the license is by definition permitting free
> redistribution of the source code.
It is an obvious necessary condition that for code to be opened it
should be open (source).
However the necessary condition is not sufficient.
>
> I have a quibble with the framing:
>
> > The rest of the blame lies with installers. They all treat
> > human-readable scripts like they were binaries and tuck the code away
> > in a dark corner.
Consider this example:
The emacs source if compiled from source will give you help for each
lisp or even builtin (C) function out of the box from inside emacs.
However if you get the emacs package from debian/ubuntu you will get
neither unless you install el files -- which is fine -- just install
the el package. About the C sources? I dont believe that one can get
that linkage from within apt; one just hast to compile oneself. (I
would be happy to be surprised on this).
Isn't this an instance of the problem that Raymond is talking of?
[Personal note: Ive been a python user and teacher for nearly 10
years and would eagerly welcome more easy code-open-ness]
TP
> http://mail.python.org/mailman/listinfo/python-list
>
The Sphinx Python Documentation Generator
(http://sphinx.pocoo.org/index.html), used for documenting lots of
things other than Python, has an extension called "sphinx.ext.viewcode
– Add links to highlighted source code"
(http://sphinx.pocoo.org/ext/viewcode.html).
You can see my use of it here on a small PyQt project:
http://tpgit.github.com/MDIImageViewer/imageviewer.html. You can even
view the Sphinx documentation "code" by clicking the "Show Source"
link on the left.
-- TP
Miki
It's probably easy to implement in Python with the inspect module. Sadly this won't work for built-ins.
Clojure's irc clojurebot will answer "source <function>" with a link to github that points to the first line of definition.
Raymond Hettinger
> On Fri, Jan 28, 2011 at 10:32 AM, Raymond Hettinger <pyt...@rcn.com> wrote:
> > I hoping a new trend will start with dev's putting direct
> > source code links in their documentation:
>
> > http://rhettinger.wordpress.com/2011/01/28/open-your-source-more/
>
> > I'm looking for more examples of projects that routinely
> > link their docs back into relavant sections of code.
> > Have any of you all seen other examples besides
> > the Go language docs and the Python docs?
>
> > Raymond
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
> The Sphinx Python Documentation Generator
> (http://sphinx.pocoo.org/index.html), used for documenting lots of
> things other than Python, has an extension called "sphinx.ext.viewcode
> – Add links to highlighted source code"
> (http://sphinx.pocoo.org/ext/viewcode.html).
Thanks, I didn't know about that extension.
To support my effort to add source links to the Python docs,
Georg Brandl added a new directive :source: so that we could
write :source:`Lib/heapq.py` and the set the prefix somewhere else
(i.e. pointing at the py3k branch on subversion or on mercurial).
Raymond
Ben Finney
> On Jan 29, 4:10 am, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> > I have a quibble with the framing:
> >
> > > The rest of the blame lies with installers. They all treat
> > > human-readable scripts like they were binaries and tuck the code
> > > away in a dark corner.
>
> Consider this example:
> The emacs source if compiled from source will give you help for each
> lisp or even builtin (C) function out of the box from inside emacs.
> However if you get the emacs package from debian/ubuntu you will get
> neither unless you install el files -- which is fine -- just install
> the el package. […]
That's an example of the point I made in what followed in my message you
quoted. The description can be interpreted as accurate, but it's framed
poorly.
> Isn't this an instance of the problem that Raymond is talking of?
The “problem”, which I don't consider to be a problem per se, is one of
OS-wide policy, not “installers”. The policy is a matter of tradeoffs
across the system, and isn't “tucking the code away in a dark corner”.
> [Personal note: Ive been a python user and teacher for nearly 10
> years and would eagerly welcome more easy code-open-ness]
Agreed.
--
\ “When people believe that they have absolute knowledge, with no |
`\ test in reality, this [the Auschwitz crematorium] is how they |
_o__) behave.” —Jacob Bronowski, _The Ascent of Man_, 1973 |
Ben Finney
rusi
>
> The “problem”, which I don't consider to be a problem per se, is one of
> OS-wide policy, not “installers”. The policy is a matter of tradeoffs
> across the system, and isn't “tucking the code away in a dark corner”.
Earlier mail:
> If you want to blame anything for this (though I think it’s inaccurate
> to frame it as a problem), the correct target of your accusation is the
> fact that a filesystem path is the identifier for these modules that
> will be used by programs to find them.
I think this is a fairly accurate description of (one aspect of) the
problem.
If you dont see it as a problem how do you explain that google can
search the World Wide Web better than we can search our individual
hard disks?
Steven D'Aprano
I fail to see any connection between the location that operating systems
store files, and the ability of Google to index publicly available
websites. It sounds to me like the equivalent of "If you don't think
Python programmers are a problem, how do you explain that it takes me 45
minutes to drive to work in the morning but nearly an hour to drive home
in the evening?"
Google has approximately one million servers indexing the web, and
they're willing to use hundreds of terabytes of disk space to store the
indexes. My desktop is *one* PC with little free space, and I'd rather
trade off time for storage, so I don't keep any indexes of file content
on my system. If I *wanted* to index my files, I could do so, although in
fairness I'm not aware of any Linux tools which do this -- I know of
`locate`, which indexes file *names* but not content, and `grep`, which
searches file content but doesn't index what it finds.
On Windows and Mac, though, I believe there are standard utilities which
will index file content if you allow them.
So... Google can search the web better than we can search our local hard
drives because Google has invested tens or hundreds of millions into
building a world-class search engine, and we haven't.
--
Steven
rusi
+comp.lang.pyt...@pearwood.info> wrote:
>
> > I think this is a fairly accurate description of (one aspect of) the
> > problem.
> > If you dont see it as a problem how do you explain that google can
> > search the World Wide Web better than we can search our individual hard
> > disks?
>
> I fail to see any connection between the location that operating systems
> store files, and the ability of Google to index publicly available
> websites.
http://en.wikipedia.org/wiki/Content-addressable_storage#Content-addressed_vs._Location-addressed
Raymond Hettinger
> Raymond Hettinger <pyt...@rcn.com> writes:
> > The rest of the blame lies with installers. They all treat
> > human-readable scripts like they were binaries and tuck the code away
> > in a dark corner.
>
> That’s hardly a “blame” of installers. The modules are placed in such
> locations because they need to be accessible in a hierarchy at a
> location that is known to not conflict with anything else, and be
> predictable for the Python interpreter on the system.
Sure. Installers are just installing where they're supposed to.
And good people have given a lot of thought to the preferred
target directories. I'm just observing that the source files
are often ending-up out-of-sight and out-of-mind so that fewer
users ever see the source.
It's not deep a problem -- it would only take a symlink to
provide quick access.
My thesis is that we can do even better than that by adding
direct links from the docs to the relevant code with nice
syntax highlighting.
Raymond
P.S. Making it easy to get to relevant source is only half of
the solution. The remaining problem is cultural. Perhaps every
project should have a recommended reading list.
As a start, I think the following are instructive and make for a good
read:
http://svn.python.org/view/python/branches/py3k/Lib/ftplib.py?view=markup
http://svn.python.org/view/python/branches/py3k/Lib/heapq.py?view=markup
http://svn.python.org/view/python/branches/py3k/Lib/collections.py?view=markup
http://svn.python.org/view/python/branches/py3k/Lib/queue.py?view=markup
http://svn.python.org/view/python/branches/py3k/Lib/functools.py?view=markup
Steven D'Aprano
Nope, sorry, doesn't help. Both local files on your hard drive, and most
remote websites on the Internet, are location addressed. Google indexes
the content, but they don't provide content-addresses. Indeed, they
*can't* do so (except, possibly, for content they control such as Google
Books), since they can't prevent content owners from modifying either the
location address or the content. And as I've mentioned, there are desktop
utilities that index content for Windows and Macintosh. In fact, Google
themselves offer a desktop app that does just that:
http://desktop.google.com/features.html
--
Steven
David Boddie
> If I *wanted* to index my files, I could do so, although in
> fairness I'm not aware of any Linux tools which do this -- I know of
> `locate`, which indexes file *names* but not content, and `grep`, which
> searches file content but doesn't index what it finds.
You might find this page useful:
http://www.wikinfo.org/index.php/Comparison_of_desktop_search_software
David
Tim Wintle
> My thesis is that we can do even better than that by adding
> direct links from the docs to the relevant code with nice
> syntax highlighting.
+1 - I think the source links are very useful (and thanks for pushing
them).
However I think the biggest changes that have probably happened with
python itself are:
(1) More users for whom this is their first language.
(2) CS courses / training not teaching C (or pointer-based languages).
(2) is especially important IMO - under half of the python developers I
have regularly worked with would feel comfortable reading C - so for the
other half reading C source code probably isn't going to help them
understand exactly what's going on (although in the long run it might
help them a lot)
Tim Wintle
rusi
> You might find this page useful:
>
> http://www.wikinfo.org/index.php/Comparison_of_desktop_search_software
>
> David
Thanks for that link David
I note particularly the disclaimer that it was removed from wikipedia
[Like when <your-unfavorite-TV-channel> censors stuff you know it
deserves a second look ;-) ]
Raymond Hettinger
> +1 - I think the source links are very useful (and thanks for pushing
> them).
Happy to do it.
> However I think the biggest changes that have probably happened with
> python itself are:
>
> (1) More users for whom this is their first language.
> (2) CS courses / training not teaching C (or pointer-based languages).
>
> (2) is especially important IMO - under half of the python developers I
> have regularly worked with would feel comfortable reading C - so for the
> other half reading C source code probably isn't going to help them
> understand exactly what's going on (although in the long run it might
> help them a lot)
That would explain why fewer people look at the C source code.
However, even the parts of the standard library written in pure Python
don't seem to be getting read anymore, so I'm still inclined to
attribute the issue to 1) inconvenient placement of source code,
2) a largish code base, and 3) possibly a cultural shift.
I'm thinking that all of those can be addressed by efforts
to lower to intellectual investment required to find the
relevant source code.
Raymond
Emile van Sebille
> That would explain why fewer people look at the C source code.
>
> However, even the parts of the standard library written in pure Python
> don't seem to be getting read anymore, so I'm still inclined to
> attribute the issue to 1) inconvenient placement of source code,
> 2) a largish code base, and 3) possibly a cultural shift.
>
ISTM that around the time the list forked off py-dev fewer people
remained that were singing 'use the source'. . .
Emile
Steven D'Aprano
> However, even the parts of the standard library written in pure Python
> don't seem to be getting read anymore, so I'm still inclined to
> attribute the issue to 1) inconvenient placement of source code, 2) a
> largish code base, and 3) possibly a cultural shift.
I'd be inclined to say that #3 is by far the most important. When I
started programming, the internet wasn't even a distant object on radar.
(That is to say, it existed, but hardly anyone outside of a few gurus at
universities had even heard of it.) If you wanted to learn a language,
you bought a book and read it, if one existed and you could afford it,
and you read the sample code that came with the software. Often the book
you bought told you to read the sample code. You couldn't email a mailing
list to ask for help, or post to a forum, or google the answer. If you
were lucky, you could go to a Users Group once a month or so. And so "old
timers" learned to read the source, because that's almost all there was.
Today's newbies take the internet, web forums, mailing lists, usenet and
google for granted. This is a *big* cultural shift.
As for #1, in truth I don't believe it is actually a problem. Okay, it
might be a bit inconvenient to find the Python source code the first few
times you go looking (I can never remember whether to look in
/usr/lib/python or /usr/local/lib/python), but once you've found it, it
isn't difficult to create a shortcut for it. And as for #2, yes, there
may be a lot of code in the standard library, but it's all cut up into
small, easily swallowed chunks called "modules" :)
In my experience, the biggest obstacles for people to read the Python
code in the standard library are:
(1) thinking to do so in the first place; and
(2) the chicken-and-egg problem that as a newbie they often don't
understand what they're reading.
Your idea of including links to source in the documentation will
hopefully help with the first.
--
Steven
rusi
--------------------------
On Feb 1, 1:35 am, Raymond Hettinger <pyt...@rcn.com> wrote:
> However, even the parts of the standard library written in pure Python
> don't seem to be getting read anymore, so I'm still inclined to
> attribute the issue to 1) inconvenient placement of source code,
> 2) a largish code base, and 3) possibly a cultural shift.
There is another thread running where this was said (by a python
developer?)
> Actually I don't even understand how can IDLE source code quality have
> anything to do with python success or future adoption, as you implied
> in your statements.
> High priority bugs get fixed first. IDLE source code is clearly not a
> high priority issue, hence it doesn't get fixed: end of story.
Now if we can put aside for a moment the fact that the person to whom
this was said specializes in the art of raising others' blood
pressures and making them say what they may not otherwise have said,
it should be clear that this priority is at cross purposes with
Raymond's.
In short (at the risk of belonging to the equivalence class of others
whose names start with R) I would suggest a 4th point: Code cruft
Please note: I am thankful to all python devs for giving me python.
Its just that when functionality becomes as large as it is for python
and the target is fast moving, keeping code spic and span will
generally be perceived to be a priority that has crossed the point of
diminishing returns. Consequence: noobs will have a higher barrier to
entry than earlier
Stephen Hansen
> On Feb 1, 12:25 am, rusi <rustompm...@gmail.com> wrote:
>> In short (at the risk of belonging to the equivalence class of others
>> whose names start with R) I would suggest a 4th point: Code cruft
First tonight, you find sexism funny; now you find bigotry funny.
Disgusting.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
OKB (not okblacke)
> However I think the biggest changes that have probably happened
> with python itself are:
>
> (1) More users for whom this is their first language.
> (2) CS courses / training not teaching C (or pointer-based
> languages).
>
> (2) is especially important IMO - under half of the python
> developers I have regularly worked with would feel comfortable
> reading C - so for the other half reading C source code probably
> isn't going to help them understand exactly what's going on
> (although in the long run it might help them a lot)
I'd just like to note that (2) applies to me in spades. I'm not
sure how many other people are in my position, but I use Python because
I like how it works, and I do not want to use C because I find it
insufferable. I quite frequently look at the source of Python modules,
although more often third-party modules than the standard lib, but if I
have to look at the C source of something I basically stop and find
another solution (possibly abandoning Python altogether for that usage).
I think, in general, the less anyone needs to know C even exists,
the better for Python; likewise, the more that people have to mention
the existence of C in a Python context, the worse for Python. This may
be a somewhat extreme viewpoint, but that's my position.
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
rusi
<brenNOSPAMb...@NObrenSPAMbarn.net> wrote:
> Tim Wintle wrote:
> > (2) is especially important IMO - under half of the python
> > developers I have regularly worked with would feel comfortable
> > reading C - so for the other half reading C source code probably
> > isn't going to help them understand exactly what's going on
> > (although in the long run it might help them a lot)
>
> I'd just like to note that (2) applies to me in spades. I'm not
> sure how many other people are in my position, but I use Python because
> I like how it works, and I do not want to use C because I find it
> insufferable. I quite frequently look at the source of Python modules,
> although more often third-party modules than the standard lib, but if I
> have to look at the C source of something I basically stop and find
> another solution (possibly abandoning Python altogether for that usage).
>
> I think, in general, the less anyone needs to know C even exists,
> the better for Python; likewise, the more that people have to mention
> the existence of C in a Python context, the worse for Python. This may
> be a somewhat extreme viewpoint, but that's my position.
In 1990 I wrote a paper elaborating this. http://portal.acm.org/citation.cfm?id=126471
It is dated (before python, java, haskell and the internet as we know
it today)
It is also dated in the sense that I dont totally agree with the
strong views therein (I was half my age then :-)
Still if you want it its here
https://docs.google.com/document/d/1P-BQtpyzjjjOKxzhKjIGI-GLMXW5bOZ6xYBJhApwqLc/edit?hl=en
[PS Does not read properly in google docs though it reads ok in
acroread and evince ]
rusi
>
> [PS Does not read properly in google docs though it reads ok in
> acroread and evince ]
Sorry google docs does not like the pdf
Heres a ps
https://docs.google.com/leaf?id=0B3gsacOF56PxOWUxZTVmOTQtYWIxNy00ZGFjLWEwODUtZDVkM2MyZGI5ZmRk&hl=en
OKB (not okblacke)
> On Feb 2, 12:32�am, "OKB (not okblacke)"
>> � � � � I think, in general, the less anyone needs to know C even
>> exists, the better for Python; likewise, the more that people have
>> to mention the existence of C in a Python context, the worse for
>> Python. �This may be a somewhat extreme viewpoint, but that's my
>> position.
>
> In 1990 I wrote a paper elaborating this.
> http://portal.acm.org/citation.cfm?id=126471 It is dated (before
> python, java, haskell and the internet as we know it today)
> It is also dated in the sense that I dont totally agree with the
> strong views therein (I was half my age then :-)
Very interesting, thanks. I think Python has its own warts
comparable to some of those you mention, but not all. What bothers me
most is when "practicality beats purity" is invoked, with practicality
defined as "doing it this way is faster in C".
rusi
<brenNOSPAMb...@NObrenSPAMbarn.net> wrote:
>
> Very interesting, thanks. I think Python has its own warts
> comparable to some of those you mention, but not all. What bothers me
> most is when "practicality beats purity" is invoked, with practicality
> defined as "doing it this way is faster in C".
Yes Knuth is worshipped but his advice is not heeded
http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
Stefan Behnel
> I think Python has its own warts
> comparable to some of those you mention, but not all. What bothers me
> most is when "practicality beats purity" is invoked, with practicality
> defined as "doing it this way is faster in C".
Most of that should be gone in Python 3.
There's also the practicality in the sense of "someone has to write the
code". Both are certainly common in every open source developer community,
including python-dev, if you replace "C" by "the right language in the
given context". But I must say that I rarely read either of the two being
used as common meanings for "practicality" on python-dev. That term is very
user focussed in the Python community.
Stefan
Daniel Fetchinson
> to have been a change. A decade ago in this newsgroup, there were
> frequent references to standard library source. I don't see that
> much anymore.
Popularity has a price. A decade ago only hackers were exposed to
python who are happy to chat about the source code but these days
average computer users (my grandma) frequently come across python and
ask questions from a user perspective.
So I'd think your observation is correct that the ratio of source
related posts to non-source related posts on this list went down but
the reason is not because the total number of source related questions
decreased but because the total number of non-source related questions
increased.
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown