PEP Parade
Tim Peters
http://www.python.org/doc/essays/pepparade.html
"""
To start off Developer's Day at the Python10 conference I gave a keynote
ending in what I dubbed "the parade of the PEPs". It was a brief overview of
all open PEPs, where I gave my highly personal and subjective opinion for
each PEP. Later, I realized that this might have been of interest to other
developers. I didn't take notes at the conference, so below is a different
set of comments that I created from scratch during a single two-hour sitting
on March 7, 2002.
"""
Since Guido's "highly personal and subjective opinions" are nevertheless
destined to circumscribe every waking moment of your Python life, everyone
interested in Python development should give it a good read.
It's also linked to from the PEP Index page at SourceForge:
Note that Guido wants to keep 2.3 free of new core language features. You
can deduce that from reading the essay, or-- like me --you can just believe
it because it's true <wink>. There's a huge backlog of good ideas for
improving the internals and libraries, and I wouldn't be surprised to see
the focus remain there for 2.4 too.
Paul Rubin
ZIP files. A JAR file is basically ZIP file with digital signatures
for the files inside the ZIP.
Is there a method for adding comments to PEP's?
Roman Suzi
>Quoting Guido's new "Parade of the PEPs" essay at
>
> http://www.python.org/doc/essays/pepparade.html
Just one comment about
PEP 270 - uniq method for list objects
- maybe adding dict <-> list conversion functions
will make this automatically?
But how? Perlishly:
dict([1, 2, 3, 4]) -> {1: 2, 3: 4}
or some other way:
dict([1,2], [3,4]) -> {1:3, 2:4}
or
dict([(1,2), (3,4)]) -> {1:3, 2:4}
(so, dict.items() will be automatically reverse operation)
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Friday, March 08, 2002 _/ Powered by Linux RedHat 6.2 _/
_/ "People are always available for work in the past tense." _/
Tim Peters
> ...
> Is there a method for adding comments to PEP's?
Not unless the PEP author supplies one, and that's something I haven't seen
yet. PEP 1 describes the PEP process. You need to get your comments in
front of the PEP author(s).
Skip Montanaro
Roman> Just one comment about
Roman> PEP 270 - uniq method for list objects
Roman> maybe adding dict <-> list conversion functions will make this
Roman> automatically?
Nothing new is necessary since 2.2 was released:
>>> mylist = [1,2,3,5,6,6,9,9,1,2,3,4]
>>> mydict = dict(zip(mylist,mylist))
>>> mydict
{1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 9: 9}
>>> mydict.values()
[1, 2, 3, 4, 5, 6, 9]
--
Skip Montanaro (sk...@pobox.com - http://www.mojam.com/)
Roman Suzi
>
> Roman> Just one comment about
>
> Roman> PEP 270 - uniq method for list objects
>
> Roman> maybe adding dict <-> list conversion functions will make this
> Roman> automatically?
>
>Nothing new is necessary since 2.2 was released:
>
> >>> mylist = [1,2,3,5,6,6,9,9,1,2,3,4]
> >>> mydict = dict(zip(mylist,mylist))
> >>> mydict
> {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 9: 9}
> >>> mydict.values()
> [1, 2, 3, 4, 5, 6, 9]
Wow. Then I am a bit underinformed. What uniq is for then?
To cover lengthy:
def uniq(x):
return dict(map(None, x, [None])).keys()
?
:-)
OK, uniq is convenient, I agree. But then other set operations
should follow.
d.update(d1) # d = d + d1
??? # d = d * d1
??? # d = d - d1
(i know it's easy to make class for them, but
so is for uniq)
Roy Smith
> Note that Guido wants to keep 2.3 free of new core language features. You
> can deduce that from reading the essay, or-- like me --you can just believe
> it because it's true <wink>. There's a huge backlog of good ideas for
> improving the internals and libraries, and I wouldn't be surprised to see
> the focus remain there for 2.4 too.
Not touching the core language is a Good Thing. It's really tough to
convince people that python is a viable tool when it's a moving target.
It's been somewhat of an uphill battle to get my development group to
accept the fact that I write tools for the whole group's use in python.
Having the core language change from version to version just makes it
worse, as we discover imcompatabilities between whatever version I'm using
to develop on and whateve they're running on their boxes. Telling people,
"Oh, you need to upgrade to version X" gets old pretty fast. As the saying
goes, "if you're explaining, you've already lost."
Donn Cave
I have proposed before that those of us who are into having
a viable tool instead of a moving target, should just pick one
and stick with it. 2.1.1, for example. Of course you and I
can do that, solving the problems with our respective groups -
but putting us in kind of a backwater. If we sort of collectively
agree on 2.1.1 (or whatever) for that role, though, that backwater
could get pretty lively.
Donn Cave, do...@u.washington.edu
Raymond Hettinger
news:mailman.1015592594...@python.org...
>
> Roman> Just one comment about
>
> Roman> PEP 270 - uniq method for list objects
>
> >>> mylist = [1,2,3,5,6,6,9,9,1,2,3,4]
> >>> mydict = dict(zip(mylist,mylist))
> >>> mydict
> {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 9: 9}
> >>> mydict.values()
> [1, 2, 3, 4, 5, 6, 9]
Here's a one-liner version that works for all iterables
(using mylist only once):
>>> print map(None, dict(map(None, mylist, (None,))))
[1, 2, 3, 4, 5, 6, 9]
Raymond Hettinger
Tim Peters
> I have proposed before that those of us who are into having
> a viable tool instead of a moving target, should just pick one
> and stick with it. 2.1.1, for example.
2.1.2 would be a better choice, unless you also object to people fixing bugs
for you <wink>.
> Of course you and I can do that, solving the problems with our
> respective groups - but putting us in kind of a backwater. If we
> sort of collectively agree on 2.1.1 (or whatever) for that role,
> though, that backwater could get pretty lively.
I expect PythonLabs will continue wrapping up bugfix releases in the 2.1.x
series for as long as someone volunteers to produce them. At the moment,
2.1.2 is the end of that line, as 2.1.2 was the last 2.1.x release to
attract a volunteer. The longer someone waits to start on a 2.1.3, the
harder it will be to sort through, and backport, relevant fixes now going
into 2.2.1 (which Michael Hudson is producing) and 2.3 (where most current
development occurs).
"lively"-is-less-useful-than-someone-willing-to-work-ly y'rs - tim
Geoff Gerrietts
I agree with the sentiment expressed in these posts. I'm not sure if
the proposed solution is the best one. On the other hand, I know that
I would feel more comfortable pushing for adoption of a given version
if I knew that six months from now, I wouldn't hafta start the whole
push all over again because some new feature made everything uncertain
again.
I think a lot of people and projects froze on 1.5.2, because it was
the last 1.* series release, but advice in this newsgroup tends to
suggest this is a very bad idea; bugfixes haven't been pushed back
into the 1.5 series, and there's no active maintenance.
I think my fear about picking a version and sticking with it is that
the same thing would happen, again, and trying to catch the moving
target would be even harder than trying to keep up with it.
--G.
--
Geoff Gerrietts <geoff at gerrietts dot net>
"Ordinarily he was insane, but he had lucid moments
when he was merely stupid." --Heinrich Heine
Hernan M. Foffani
> On Fri, 8 Mar 2002, Skip Montanaro wrote:
> >Nothing new is necessary since 2.2 was released:
> >
> > >>> mylist = [1,2,3,5,6,6,9,9,1,2,3,4]
> > >>> mydict = dict(zip(mylist,mylist))
> > >>> mydict
> > {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 9: 9}
> > >>> mydict.values()
> > [1, 2, 3, 4, 5, 6, 9]
>
> Wow. Then I am a bit underinformed. What uniq is for then?
> To cover lengthy:
>
> def uniq(x):
> return dict(map(None, x, [None])).keys()
>
> ?
>
keys in a dictionary have to be inmutable objects. The list
we want to remove duplicates can contain other object type.
See Tim's recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52560/index_txt
-Hernan
A.M. Kuchling
> but putting us in kind of a backwater. If we sort of collectively
> agree on 2.1.1 (or whatever) for that role, though, that backwater
> could get pretty lively.
Seems unlikely; if people can't muster enough interest to participate
in handling bugs and patches in the current CVS tree, the likelihood
of taking on the even drier and duller job of backporting fixes seems
an order of magnitude less probable. Unless someone can be found to
pay money for it, of course.
(I wonder why more people don't maintain forks of the Python source
tree for specific things like oddball platforms, though. Right now
Linux is having a mini-explosion of different trees, some managed with
an eye for stability, some for including all the bleeding edge
patches; I don't think that would harm Python any.)
--amk (www.amk.ca)
"We're running out of places to run."
"The story of our lives."
-- Turlough and Tegan, in "The Awakening"
Joshua Macy
> Not touching the core language is a Good Thing. It's really tough to
> convince people that python is a viable tool when it's a moving target.
>
> It's been somewhat of an uphill battle to get my development group to
> accept the fact that I write tools for the whole group's use in python.
> Having the core language change from version to version just makes it
> worse, as we discover imcompatabilities between whatever version I'm using
> to develop on and whateve they're running on their boxes. Telling people,
> "Oh, you need to upgrade to version X" gets old pretty fast. As the saying
> goes, "if you're explaining, you've already lost."
>
Just out of curiosity, what does the rest of your group develop in
then? FORTRAN? COBOL? ("and none of this ANSI85 crap, either...it gets
old trying to hit a moving target!")
Joshua
Stephen J. Turnbull
Roy> It's really tough to convince people that python is a viable
Roy> tool when it's a moving target.
Tell that to Bill Gates, hey!<wink>
Not to deny your point. Rather to point out that if Bill can do it,
somehow, so can we. And if we manage it better than the infamous
Word (whichever, 96?) transition, there's a lot of good will to be had.
Roy> Having the core language change from version to version just
Roy> makes it worse, as we discover imcompatabilities between
Roy> whatever version I'm using to develop on and whateve they're
Roy> running on their boxes.
So you standardize locally.
--
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.
Chris Gonnerman
From: "Joshua Macy" <l0819m0v...@sneakemail.com>
>
> Just out of curiosity, what does the rest of your group develop in
> then? FORTRAN? COBOL? ("and none of this ANSI85 crap, either...it gets
> old trying to hit a moving target!")
Yeah, but "major" language standards change every few years... Python
releases come about 1-2 per year. We have to resist the urge to change
something major in the core too frequently.
Donn Cave
| In article <a6b91d$oau$1...@nntp6.u.washington.edu>, Donn Cave wrote:
| > but putting us in kind of a backwater. If we sort of collectively
| > agree on 2.1.1 (or whatever) for that role, though, that backwater
| > could get pretty lively.
|
| Seems unlikely; if people can't muster enough interest to participate
| in handling bugs and patches in the current CVS tree, the likelihood
| of taking on the even drier and duller job of backporting fixes seems
| an order of magnitude less probable. Unless someone can be found to
| pay money for it, of course.
Could be just the opposite, though. If you're submitting a fix so that
it will turn up in the next release with everyone else's fixes, then
people working with 2.1.x have it pretty good (because the next release
is a minor one, not 2.3 or whatever comes out of the CVS tree next.)
But I really wasn't thinking of fixes so much. If there are lots of
people using 2.1.2 and it has a serious bug, then I'm sure someone
will come up with a fix sooner or later, but I was thinking more in
terms of 3rd party work, so to speak. Packages. Like the phenomenon
Roy was describing, but on a more global scale - you find out there's
a cool module out there, but alas, you'd need to upgrade to use it,
and the upgrade would be more pain than it's worth. Steve Turnbull's
solution "So you standardize locally", but applied at this scale -
so you standardize globally. 2.1.2 is really a step forward for the
Python world as a whole, since there's a massive 1.5.2 contingent out
there right now. I don't know, there's been some gnashing of teeth
about Redhat's release schedule vs. Python's, maybe they and other
platform vendors really need a not-so-current release that's still
somewhat active.
Donn
Tim Peters
> ...
> If there are lots of people using 2.1.2 and it has a serious bug, then
> I'm sure someone will come up with a fix sooner or later,
Like there were many serious bugs in 1.5.2, and sooner or later they did get
fixed. However, because nobody volunteered to produce a bugfix release for
1.5.2 (and despite that Guido started asking for volunteers about 6 months
after 1.5.2 was released -- no response), none of those fixes do 1.5.2 users
any good. The only advice they get when they hit a 1.5.2 bug is "so
upgrade -- or pay someone for the pain of investigation and backporting".
If you're serious about holding on to 2.1, talk someone into starting work
on 2.1.3 now. It will already be more difficult for them than it would have
been had they started to produce 2.1.3 right after 2.1.2 was released. Let
a few more months pass, and the odds of another 2.1 bugfix release will be
down with the odds of a new 1.5.2 bugfix release.
If you're picturing individual patches for only those bugs you consider
"serious", the distribution, integration, and support problems will kill
that in practice. That is, very few will agree to hunt down and apply
random patches to an unsupported product, and those who do will eventually
hit bugs unique to the specific combination of patches they applied.
Keeping the 2.1.x series alive is a real solution to all that too.
reality-check-ly y'rs - tim
Roy Smith
> Roy> Having the core language change from version to version just
> Roy> makes it worse, as we discover imcompatabilities between
> Roy> whatever version I'm using to develop on and whateve they're
> Roy> running on their boxes.
>
> So you standardize locally.
It's one thing to say "so you standardize locally", but the fact is, even
requiring just that is an impediment to adoption. A typical scenario goes
like this:
Me: "Hey guys, I wrote a great new program, called foo.py. It's in CVS,
under tools."
Co-worker: "Neat, but when I go to run it, I get a syntax error"
Me: "Let me see.... Oh, you've got python 1.5.2! Do you have any idea how
old that is? You need to upgrade to 2.1.2"
Co-worker: "Oh, I don't have the time to do that. Nice looking tool, but I
guess I'll have to pass, thanks".
If there was management buy-in, there might be a chance of declaring "thou
shalt install python 2.1.2 on all development machines", but there's no
management buy-in. In fact, management sort of humors me by letting me
waste my time playing with Python as long as I get my "real work" done.
Quite reasonably, my boss wants to know what the "business case" is for the
group adopting python. The fact that python is cool and wonderful and perl
sucks eggs doesn't go very far in the face of the fact that perl tends to
be a lot more portable (or at least is percieved to be). The 1000's of
lines of production perl code I've written run without a hitch on
everybody's machine using whatever version of perl happened to come with
their box.
And, I think there lies the real problem. Python is facing an uphill
battle for acceptance by the business community. Anything that increases
the perception (true or false) that python is difficult to support makes it
just that much harder to get it accepted. Technical arguments
notwithstanding, frequent changes to the core language syntax sure increase
the perception that it's a risky language on which to risk the success of
your business.
Roy Smith
> Just out of curiosity, what does the rest of your group develop in
> then? FORTRAN? COBOL? ("and none of this ANSI85 crap, either...it gets
> old trying to hit a moving target!")
For internal tools, mostly perl. For production code, mostly C/C++ and TCL.
Joshua Macy
> Yeah, but "major" language standards change every few years... Python
> releases come about 1-2 per year. We have to resist the urge to change
> something major in the core too frequently.
>
The standards may only change every few years, if you don't count
Java as a "major" language, but all the vendors of implementations for
those languages I've ever dealt with release patches at the rate of 1-2
per year, or more frequently. Even the COBOL vendors. And every patch
release that fixes something stands a chance of breaking something else
(even if only code that worked around the old improper behavior). Shops
that really care about that and have no viable regression test strategy
upgrade less frequently, and if they ship software make sure that they
ship exactly what's needed to run their product (no easy task on
Windows, thanks to dll hell). My experience is that shops that take the
conservative approach (even mainframe shops) eventually end up throwing
out working systems because the exact compiler version that they rely on
fall off the vendor's support list and it becomes too painful to upgrade
through multiple releases. And in Microsoft shops insult is added to
injury when you have to pay to upgrade to something that will break your
existing code.
But nobody is holding a gun to your head and saying "upgrade or
die"--and unlike with closed source compilers, if you're bound and
determined never to move off 1.5.2 you have the source code so you can
continue to maintain it unto as-yet-undreamed-of platforms and
architectures. Equally true is that nobody is likely to agree to do
this maintenance for you for free.
As for me, I've yet to see a change to Python since 1.5.2 that I regard
as "major" in terms of incompatibility with existing, working code
(plenty of new features for what used to be invalid syntax) that you
didn't have to explicitly enable with a __future__ statement, and in
that case there was a whole release in between where you could test with
either behavior.
I can understand people taking a more conservative approach, but then I
lose them when they say they should build a sub-community around the
inviolability of a particular old release. And do what? Sit around
looking at the old source code and say "Yep, we're not going to change
that"? The obvious approach to me is that if you're not prepared, for
whatever reason, to upgrade: don't upgrade. If you are serious about
distributing a stable working system: distribute the whole system,
interpreter and library included.
Joshua
Joshua Macy
Perl's latest stable release is 5.6.1 My linux box has 5.005
installed standard, and I'm told that there are sites out there that are
still chugging away on Perl 4. Meanwhile the latest development version
of Perl is 5.7.3 and Perl 6 is in the works. If your fellow developers
think that makes Perl stable compared to Python's rate of change, I
think they're fooling themselves.
Joshua
Skip Montanaro
>>> Just out of curiosity, what does the rest of your group develop in
>>> then?
>> For internal tools, mostly perl. For production code, mostly C/C++
>> and TCL.
Joshua> If your fellow developers think that makes Perl stable compared
Joshua> to Python's rate of change, I think they're fooling themselves.
You just program in the stable subset. ;-)
Stephen J. Turnbull
Stephen J. Turnbull" <ste...@xemacs.org> wrote:
Roy> as we discover imcompatabilities between whatever version I'm
Roy> using to develop on and whateve they're running on their
Roy> boxes.
>> So you standardize locally.
Roy> It's one thing to say "so you standardize locally", but the
Roy> fact is, even requiring just that is an impediment to
Roy> adoption. A typical scenario goes like this:
Roy> Me: "Hey guys, I wrote a great new program, called foo.py.
Roy> It's in CVS, under tools."
Roy> Co-worker: "Neat, but when I go to run it, I get a syntax
Roy> error"
Roy> Me: "Let me see.... Oh, you've got python 1.5.2! Do you have
Roy> any idea how old that is? You need to upgrade to 2.1.2"
And I say, "Roy, what are you doing programming for 2.anything if the
people you're trying to sell to are running 1.5.2?" I didn't mean
"make _them_ standardize" (you already made your point, I was
listening!), I meant "_you_ comply with the de facto standard (least
common denominator)."
Marketing is about two things: convincing others to buy in to the
pain, and absorbing as much of the pain as you can yourself. Most
people seem to think that it's only the first part. One of the things
the Microsoft is really good at is postponing pain until the customer
is already locked in. But that cost them a lot up front.
If I have tools I want to distribute to folks who aren't bleeding-
edge-distro-Linux users, I program in python 1.5. It hurts, but it
wins. Once you've got them hooked, they come saying "why can't it do
...?" and _that's_ when you say "it's too hard in 1.5, I don't have
time. But if you'll upgrade to 2.1.2, it's already in CVS...."
If you're not doing that, then you're just programming for yourself.
Which is fine: unless your job is writing for others, your needs come
first. But it's not investing in support for your tools from your
coworkers.
Anthony Baxter
>>> Tim Peters wrote
> I expect PythonLabs will continue wrapping up bugfix releases in the 2.1.x
> series for as long as someone volunteers to produce them. At the moment,
> 2.1.2 is the end of that line, as 2.1.2 was the last 2.1.x release to
> attract a volunteer.
I've yet to see a bug that makes 2.1.3 seem a likely or useful upgrade.
There were a number of _critical_ bugs in 2.1.1 that made 2.1.2 useful.
--
Anthony Baxter <ant...@interlink.com.au>
It's never to late to have a happy childhood.