The language vs. the environment
Skip Montanaro
There has been a huge amount of recent PEP activity related to further
enhancements to the language. I think in general that if more of this
energy was directed at the overall environment (library, support tools,
installers, documentation, etc) we'd be better off in the long run.
For the most part, I think the proposals currently on the table, while some
are very nice, aren't going to make a significant change in programmer
productivity, code maintainability or accessibility of the language by new
users. I understand the lure. I have succumbed to the lure myself on many
occasions. It's cool to participate in a bit of language design, most of us
are pretty good programmers and we can project how we might use a particular
feature. As Andrew Kuchling said on his page about the Frank Willison award
he received last month:
Thanks to Guido, first, for writing a language that's both fun to hack
in, and fun to hack on.
Still, even though Andrew is clearly a damn talented programmer, if you
think about what he's best known for in the Python community, it's likely
his "What's New" documents, e.g.:
If you're looking for something to munch on, here are some suggestions, not
all of which require that you write code:
* breathe some life into the catalog-sig:
http://www.python.org/sigs/catalog-sig/
* find a Python bug without a proposed fix and write one (there are
currently between 250 and 300 open bug reports):
http://sourceforge.net/tracker/?group_id=5470&atid=105470
* document an undocumented module from the standard library:
http://www.python.org/doc/current/lib/undoc.html
* write a HOWTO (another of Andrew's little sideline projects!) about
your little niche of Python expertise:
http://py-howto.sourceforge.net/
--
Skip Montanaro (sk...@pobox.com - http://www.mojam.com/)
Sean 'Shaleh' Perry
> If you're looking for something to munch on, here are some suggestions, not
> all of which require that you write code:
>
> * breathe some life into the catalog-sig:
> http://www.python.org/sigs/catalog-sig/
>
> * find a Python bug without a proposed fix and write one (there are
> currently between 250 and 300 open bug reports):
> http://sourceforge.net/tracker/?group_id=5470&atid=105470
>
> * document an undocumented module from the standard library:
> http://www.python.org/doc/current/lib/undoc.html
>
> * write a HOWTO (another of Andrew's little sideline projects!) about
> your little niche of Python expertise:
> http://py-howto.sourceforge.net/
>
help release more python modules so perl mongers will quite wagging CPAN in
front of our faces.
Steve Lamb
<shale...@attbi.com> wrote:
> help release more python modules so perl mongers will quite wagging CPAN in
> front of our faces.
Quality over Quantity. :)
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
To email: Don't despair! | -- Lenny Nero, Strange Days
-------------------------------+---------------------------------------------
Paul Rubin
> There has been a huge amount of recent PEP activity related to further
> enhancements to the language. I think in general that if more of this
> energy was directed at the overall environment (library, support tools,
> installers, documentation, etc) we'd be better off in the long run.
While we're at it, am I the only one bothered by how unsharp the
boundary is between the language and the environment? I'd consider
things like sys.exc_info to be part of the environment, but there's no
other way to get the info.
Fernando Pérez
>
> There has been a huge amount of recent PEP activity related to further
> enhancements to the language. I think in general that if more of this
> energy was directed at the overall environment (library, support tools,
> installers, documentation, etc) we'd be better off in the long run.
[snip]
Let me add to your list distutils. They are nice but need a fair amount of
work. Projects such as PyXML and SciPy have ended up writing a lot of
wraparound utility code basically to provide functionality which it would be
nice to have in the core system (useful to all). So one more for the list of
'useful things that benefit the community even though they don't sound cool'
:)
Cheers,
f.
Sean 'Shaleh' Perry
On 06-Mar-2002 Steve Lamb wrote:
> On Wed, 06 Mar 2002 13:21:35 -0800 (PST), Sean 'Shaleh' Perry
> <shale...@attbi.com> wrote:
>> help release more python modules so perl mongers will quite wagging CPAN in
>> front of our faces.
>
> Quality over Quantity. :)
>
not to disagree, however there are FAR more interesting perl modules out there
than python ones.
Richard Jones
Excellent!
Skip's marvellous post about how people could contribute to python's growth
has already reduced itself to a slanging match that _completelty_ misses the
point he was trying to make! What was that, about 10 minutes? Wow.
Sorry Skip, I know you meant well.
Richard
Sean 'Shaleh' Perry
On 06-Mar-2002 Skip Montanaro wrote:
>
> Sean> On 06-Mar-2002 Steve Lamb wrote:
> >> On Wed, 06 Mar 2002 13:21:35 -0800 (PST), Sean 'Shaleh' Perry
> >> <shale...@attbi.com> wrote:
> >>> help release more python modules so perl mongers will quite wagging
> >>> CPAN in front of our faces.
> >>
> >> Quality over Quantity. :)
>
> Sean> modules out there than python ones.
>
> Correct, which is why a better solution than CPAN or VoP might include some
> sort of module rating system. However, this discussion probably belongs on
> the catalog-sig. (my first bullet. hint, hint... ;-)
>
oh, so that is what the catalog-sig is (-:
Skip Montanaro
Sean> On 06-Mar-2002 Steve Lamb wrote:
>> <shale...@attbi.com> wrote:
>>> help release more python modules so perl mongers will quite wagging
>>> CPAN in front of our faces.
>>
>> Quality over Quantity. :)
Sean> not to disagree, however there are FAR more interesting perl
Sean> modules out there than python ones.
Correct, which is why a better solution than CPAN or VoP might include some
sort of module rating system. However, this discussion probably belongs on
the catalog-sig. (my first bullet. hint, hint... ;-)
Skip
Skip Montanaro
Paul> While we're at it, am I the only one bothered by how unsharp the
Paul> boundary is between the language and the environment? I'd
Paul> consider things like sys.exc_info to be part of the environment,
Paul> but there's no other way to get the info.
Paul,
I was thinking of much larger granularity things and things that are more
clearly separated from the language as delivered in python2.2.tgz or
python2.2.exe. It appears you'd like to conisder the standard library as
part of the environment. It is, certainly in a technical sense, but since
it is also part of the standard distribution, a semantic change there has a
much larger potential impact on programmers than, say an incompatible change
to a third-party package like PIL or MySQLdb. So, I think it kind of
straddles the fence a bit and has to be considered in a slightly different
light.
Skip
Stephen J. Turnbull
Skip> There has been a huge amount of recent PEP activity related
Skip> to further enhancements to the language. I think in general
Skip> that if more of this energy was directed at the overall
Skip> environment (library, support tools, installers,
Skip> documentation, etc) we'd be better off in the long run.
There are also proposed enhancements that are dangerous as additions
to the language, while they would be unobjectionable (and serve the
purpose equally well) as part of the environment. (Cf. PEP 263
discussion.)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
John Baxter
Skip Montanaro <sk...@pobox.com> wrote:
> There has been a huge amount of recent PEP activity related to further
> enhancements to the language. I think in general that if more of this
> energy was directed at the overall environment (library, support tools,
> installers, documentation, etc) we'd be better off in the long run.
Thanks, Skip!
More and more often, I look at a language-domain proposal, and think:
1. that might be nice...it makes good sense
2. do we need to tinker with the language that way?
3. probably not
PEP 284 triggered that sequence, and hasn't yet triggered the next step:
4. well OK, probably this one is justified.
I used 284 just as an example, not to pick on it.
--John
Tim Peters
> There has been a huge amount of recent PEP activity related to further
> enhancements to the language. I think in general that if more of this
> energy was directed at the overall environment (library, support tools,
> installers, documentation, etc) we'd be better off in the long run.
Let's not discount the short run either <wink>. Guido opined today that he
wants 2.3 to be a relatively modest "consolidation" release. As a result, I
don't expect he's going to approve "new feature" PEPs for 2.3 that aim at
the core language proper.
to-everything-there-is-a-season-and-a-time-for-every-purpose-under-
python-ly y'rs - tim
Raymond Hettinger
news:mailman.1015449438...@python.org...
>
> There has been a huge amount of recent PEP activity related to further
> enhancements to the language. I think in general that if more of this
> energy was directed at the overall environment (library, support tools,
> installers, documentation, etc) we'd be better off in the long run.
I certainly agree that effort needs to be put into the library, etc.
However, I would like to defend the PEP writers guild on a few points:
1. Writing a PEP is a disciplined activity that involves completely
thinking our design choices, rallying public opinion, collecting
all points of view for and against, and documenting all of that
information in a single, version controlled, standard format
document in a public place for everyone to study, ridicule,
or on extremely rare occassions, adopt.
In other words, PEP writing is contributing to science and is
not a wasted effort even if the idea never gets adopted.
While some people groan whenever a new PEP appears, I think
it's a good sign, rather than bad. It means we have smart people
who care and are willing to engage in public collaboration instead
of sitting on the sides slinging mud like other language forums (not
to mention any one particular four letter scripting language).
2. Having several PEPs relating to loop counters suggests that either
we're all nuts or that maybe this is a constant source of irritation
and that any one of the proposals may be fixing a real problem.
Note, the two options are not mutually exclusive; perhaps, we're
all nuts AND Python needs a loop counter solution.
My own recommendation is not entirely over top:
indexed( collection, start=0, limit=None )
One built-in function to improve readability and reliability while
solving the problem forever. Returning a generator is a low
over-head, lazy solution compared to PEP 212 creating a huge
new list of tuples. The real question is why there is so much
inertia on getting this one solved.
Please excuse the diatribe. Now that's out of my system, here are
are few random thoughts on the PEPs:
237 Unifying longs and shorts -- I sure hope this gets finished
for 2.3. It is long overdue (no pun intended)
246 Object Adaptation -- This has the potential to be a profound
improvement while not getting in the way of people who
don't need it.
265 Sorting Dictionaries by Value -- I don't think the world would
come to an end if this were adopted. It's kinda nice, very
easy to implement, and is invisible to people who don't need it.
What's all the fuss about? Let's just do it.
266, 267 -- Optimized Python good. Slow Python bad.
269 Pgen module -- I see the upside. Is there a downside?
270 Uniq method for list objects -- Same comment as for 265
274 Dictionary comprehensions -- Sounds cool but is not a compelling
advantage over dict( [(k,f(v) for k in alist] ). Hey, it only saves
fewer than ten characters and no lines.
275 Switching on Multiple Values -- Wouldn't be surprised if someone
told me this optimization were already in place. Which Pythonista
is going to stand-up and demand that we keep a slower implementation'
just because he or she hates the concept of change.
279 Enhanced Generators (my PEP) -- indexed() is WAY cool -- let's do it.
Okay, the x-functions may belong in a separate module. Generator
Comprehensions are loved by more than few, are trivially easy to
implement,
and invisible to those who don't care for them. And about .next(arg)
and
.throw(exception) -- yawn.
212, 276, 279(indexed), 281, and 284. Any of the above, all of the above,
pick one and solve a real problem.
My overall point is that it would be unhealthy to adopt an anti-pep attitude
and that many of the PEPs are darned useful and not at all hurtful.
This point may not apply to you. When I wrote 279, some replies were
supportive,
some were inquisitive, some were analytical, some were helpful, but there
were
some that had a scary attitude along the lines of:
"I don't care if the idea is good,
I will fight further changes till my dying breath"
That being said, Skip is right. The libraries, documentation, and patches
need work. I did not miss his point.
G' nite,
Raymond Hettinger
Skip Montanaro
Raymond> "Skip Montanaro" <sk...@pobox.com> wrote ...
>> There has been a huge amount of recent PEP activity related to
>> further enhancements to the language. I think in general that if
>> more of this energy was directed at the overall environment (library,
>> support tools, installers, documentation, etc) we'd be better off in
>> the long run.
Raymond> I certainly agree that effort needs to be put into the library,
Raymond> etc.
Raymond> However, I would like to defend the PEP writers guild on a few
Raymond> points:
...
Raymond> 1. Writing a PEP is a disciplined activity that involves
Raymond> completely thinking our design choices, rallying public
Raymond> opinion, collecting all points of view for and against, and
Raymond> documenting all of that information in a single, version
Raymond> controlled, standard format document in a public place for
Raymond> everyone to study, ridicule, or on extremely rare
Raymond> occassions, adopt.
Raymond> In other words, PEP writing is contributing to science and
Raymond> is not a wasted effort even if the idea never gets adopted.
No defense needed. We need PEPs related to the environment also, however.
I think some (most? all?) the blood, sweat, and tears poured into recent
PEPs related to what amount to relatively minor language design issues could
have more profitably been devoted to PEPs related to environment issues. If
the energy expended on just PEPs related to loop counters had been directed
at cataloging/module distribution ideas, we'd probably have a pretty
complete PEP with a fair amount of buy-in from the community by now, and
maybe one or more implemented trial systems by now.
Skip
Michael Hudson
You've lost me. Care to elaborate?
Cheers,
M.
PS: bear in mind my fondness for common lisp -- I'm not convinced
separation of language and environment is a good thing...
--
languages shape the way we think, or don't.
-- Erik Naggum, comp.lang.lisp
A.M. Kuchling
> Let me add to your list distutils. They are nice but need a fair amount of
> work. Projects such as PyXML and SciPy have ended up writing a lot of
> wraparound utility code basically to provide functionality which it would be
> nice to have in the core system (useful to all). So one more for the list of
Well, someone should actually contribute those changes back to
Distutils; they can't improve without patches.
--amk (www.amk.ca)
... see the sun set in the hand of the man ...
-- Rachel, in SANDMAN #3: "Dream a Little Dream of Me"
Paul Boddie
This was a great posting from Skip, and if I were still doing DDJ
Python-URL! it would go right in there at the very top. (Hint to the
current Python-URL! writer!)
> If you're looking for something to munch on, here are some suggestions, not
> all of which require that you write code:
>
> * breathe some life into the catalog-sig:
> http://www.python.org/sigs/catalog-sig/
We've got the Vaults and siphon has been around and yet failed to
maintain a high profile, as far as I've read on this list/group.
Interestingly, the CPAN issue just keeps coming up. Myself, I wrote a
script to query the Vaults, and I even have functionality for finding
dependencies, although with the "screen-scraping" techniques in use,
my code is possibly not that reliable. Nevertheless, I see a future
for "grass roots", really simple code in this area, and surely writing
that code would be *much* easier than writing a PEP about some banal
language change.
> * find a Python bug without a proposed fix and write one (there are
> currently between 250 and 300 open bug reports):
> http://sourceforge.net/tracker/?group_id=5470&atid=105470
Although one might think that this requires a "Python internals skill
level" of at least 7 out of 10, there are probably porting issues that
could usefully be resolved by people with access to the right
hardware. (If Python runs on RISC OS, Amiga and Mac OS - hats off to
the RISC OS, Amiga and Mac OS maintainers, by the way - it really
should run on HP-UX 10.x!)
> * document an undocumented module from the standard library:
> http://www.python.org/doc/current/lib/undoc.html
Or even write a nice wrapper around some of that code - nntplib was my
first standard library experience, but it surely hasn't changed that
much since 1995.
> * write a HOWTO (another of Andrew's little sideline projects!) about
> your little niche of Python expertise:
> http://py-howto.sourceforge.net/
Yes, even a HOWTO is much easier than a language change PEP - you
can...
* Write about something you know very well, because you've tried it
and it works.
* Ignore rigorous criticism - just say "in my experience" and people
will still be grateful for your contribution.
* Get positive feedback, rather than a 200 message thread of mixed
responses before you lose interest entirely or it's pointed out
that your changes will never be accepted, or at least not before
Python 4.1 (or, in some cases, before the Winter Olympics are
staged in Hell).
Paul
Skip Montanaro
Paul> We've got the Vaults and siphon has been around and yet failed to
Paul> maintain a high profile, as far as I've read on this list/group.
Paul> Interestingly, the CPAN issue just keeps coming up. Myself, I
Paul> wrote a script to query the Vaults, and I even have functionality
Paul> for finding dependencies, although with the "screen-scraping"
Paul> techniques in use, my code is possibly not that reliable.
Paul> Nevertheless, I see a future for "grass roots", really simple code
Paul> in this area, and surely writing that code would be *much* easier
Paul> than writing a PEP about some banal language change.
There was a lightning talk at IPC10 on Gideon, a prototype Python
repository. Since it's implemented as a Zope product I think you sort of
get an XML-RPC API for free, which would beat screen scraping hands down.
You can check it out:
http://www.zope.org/Members/k_vertigo/Products/Gideon
A prototype server is at:
Thanks to Andrew Kuchling for the references.
>> * find a Python bug without a proposed fix and write one (there are
>> currently between 250 and 300 open bug reports):
>> http://sourceforge.net/tracker/?group_id=5470&atid=105470
Paul> Although one might think that this requires a "Python internals
Paul> skill level" of at least 7 out of 10, there are probably porting
Paul> issues that could usefully be resolved by people with access to
Paul> the right hardware.
Correctamundo. I am in the midst of composing a note looking for new
developers, to be posted shortly.
Skip
Michael Hudson
> Skip Montanaro <sk...@pobox.com> wrote in message news:<mailman.1015449438...@python.org>...
> > * find a Python bug without a proposed fix and write one (there are
> > currently between 250 and 300 open bug reports):
> > http://sourceforge.net/tracker/?group_id=5470&atid=105470
>
> Although one might think that this requires a "Python internals skill
> level" of at least 7 out of 10,
This isn't true. You need to know how to use "cvs" and "diff", and
*some* bugs require a "Python internals skill level" of at least 11
out of 10, but most don't and many probably don't require more that 3
or 4 out of ten. Besides, what better way of acquiring the skill to
fix deep bugs than to practice fixing shallow ones?
CHeers,
M.
--
There are two ways of constructing a software design: one way is to
make it so simple that there are obviously no deficiencies and the
other way is to make it so complicated that there are no obvious
deficiencies. -- C. A. R. Hoare
Paul Boddie
>
> This isn't true. You need to know how to use "cvs" and "diff", and
> *some* bugs require a "Python internals skill level" of at least 11
> out of 10, but most don't and many probably don't require more that 3
> or 4 out of ten. Besides, what better way of acquiring the skill to
> fix deep bugs than to practice fixing shallow ones?
My point exactly. I increased my "skill level" by 1 point (alright,
0.5 points, then) when I went looking inside the import mechanism,
although I then took the easy way out and passed the problem over to
some willing Python gurus instead of fixing it myself. (Actually, I
couldn't have fixed it definitively myself - there was a "policy"
thing that needed addressing.)
Paul
Tom Good
This skill level point system sounds like it could be the basis of a
Python Role-Playing Game. "My Python Wizard character just gained a
level. Now which statistic should I increase: Python Internals,
ZOPE, Generators, or PEPs? ZOPE would help me in combat against
web-based monsters, but I'll recover hit points more quickly with
Generators . . ."
Martijn Faassen
[snip]
> This skill level point system sounds like it could be the basis of a
> Python Role-Playing Game. "My Python Wizard character just gained a
> level. Now which statistic should I increase: Python Internals,
> ZOPE, Generators, or PEPs? ZOPE would help me in combat against
> web-based monsters, but I'll recover hit points more quickly with
> Generators . . ."
See also:
http://www.twistedmatrix.com/users/jh.twistd/python/moin.cgi/PythonRolePlayingGame
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?