Did list comprehensions ever make it into 1.6? I thought I submitted a 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? To the patches list? -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395
Did list comprehensions ever make it into 1.6?
No (as far as I'm aware :-).
I thought I submitted a 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? To the patches list?
It's rather late in the release cycle -- I'm trying to get alpha 3 released, and i'm still 1400 messages behind on my email. But submitting a patch might be a good idea anyway so we won't forget about it (and maybe it's of such baffling simplicity that it'll charm its way past the guards :-). --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, 19 Jun 2000, Guido van Rossum wrote:
Did list comprehensions ever make it into 1.6?
No (as far as I'm aware :-). [...] But submitting a patch might be a good idea anyway so we won't forget about it (and maybe it's of such baffling simplicity that it'll charm its way past the guards :-).
I just have to say i thought list comprehensions were really cool. -- ?!ng
Ka-Ping Yee <ping@lfw.org>:
On Mon, 19 Jun 2000, Guido van Rossum wrote:
But submitting a patch might be a good idea anyway so we won't forget about it (and maybe it's of such baffling simplicity that it'll charm its way past the guards :-).
I just have to say i thought list comprehensions were really cool.
Ditto. I would like to see this in 1.6. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you!
[Ka-Ping Yee]
I just have to say i thought list comprehensions were really cool.
[Eric S. Raymond]
Ditto. I would like to see this in 1.6.
Nobody has been more vocal in support of these (& augmented assignments) than me, but I very strongly doubt they'll be in 1.6. In the interests of getting that out the door, Guido considers the 1.6 feature set to be frozen already. I think part of the pressure to get one more feature in Python (again & again & again) is that release cycles have been soooooo protracted, now slobbering well over the full year mark. If I accomplish nothing else at BeOpen, I want to give that a major speed boost -- I don't think we should ever let 6 months go by without at least pumping out a bugfix release. there-are-other-things-guido-doesn't-yet-know-he-believes-too<wink>-ly y'rs - tim
Tim Peters wrote:
... Nobody has been more vocal in support of these (& augmented assignments) than me, but I very strongly doubt they'll be in 1.6. In the interests of getting that out the door, Guido considers the 1.6 feature set to be frozen already.
Is there an argument for putting in features with flaming red neon lights: "warning, experimental, use at your risk." We want to follow a bazaar (if not outright bizarre) development strategy after all. Putting a patch "out there" really doesn't do much about having people really play with and comment on a feature. I would never have experimented (and decided against using...) metaclasses if they hadn't popped up as an experimental feature. Of course if there is a decent chance of breaking something already in there that works then that's another issue...
I think part of the pressure to get one more feature in Python (again & again & again) is that release cycles have been soooooo protracted, now slobbering well over the full year mark.
Nah, no matter how quick you do the turnarounds, nobody wants to wait for their favorite feature. :) -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Floggings will continue until morale improves.
On 21 June 2000, Paul Prescod said:
Is there an argument for putting in features with flaming red neon lights: "warning, experimental, use at your risk." We want to follow a bazaar (if not outright bizarre) development strategy after all. Putting a patch "out there" really doesn't do much about having people really play with and comment on a feature. I would never have experimented (and decided against using...) metaclasses if they hadn't popped up as an experimental feature.
Well, remember there will probably be a "--with-gc" option to the configure script in 1.6. That's a good example of getting an experimental feature out there. However, a "--with-list-comprehensions" option would be a really bad idea; all of a sudden, it's no longer enough to say, "You need Python 1.6" to run this script/use this module, now you need to say, "You need Python 1.6 built with list comprehensions". Ugh. Real language features should not be selectable: either the language is Python 1.6 or it isn't. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367
On Fri, Jun 23, 2000 at 11:45:16AM -0400, Greg Ward wrote:
idea; all of a sudden, it's no longer enough to say, "You need Python 1.6" to run this script/use this module, now you need to say, "You need Python 1.6 built with list comprehensions". Ugh.
The same argument applies to --with-gc, though, since people might write code that creates cycles and needs GC to run without leaking like a sieve. Making GC optional is still the right solution, though, because its performance effects are still unknown and might be costly. --amk
Greg Ward wrote:
idea; all of a sudden, it's no longer enough to say, "You need Python 1.6" to run this script/use this module, now you need to say, "You need Python 1.6 built with list comprehensions". Ugh.
Andrew Kuchling wrote:
The same argument applies to --with-gc, though, since people might write code that creates cycles and needs GC to run without leaking like a sieve. Making GC optional is still the right solution, though, because its performance effects are still unknown and might be costly.
Greg Wilson writes: I'm really looking forward to recycling my rusty SETL idioms when list comprehensions become part of the "official" release, and to creating graphs in the obvious way if GC ever becomes standard. However, the more variations there are in the "standard" (as opposed to "developer") release, the more expensive (in time and sweat) it is to manage Python at large sites (like Los Alamos). This in turn makes it harder to persuade people that using Python will make their lives easier... Thanks, Greg Footnote: The existence of JPython was one of the arguments in favor of choosing Python for the Software Carpentry project. The fact that JPython and CPython have very different memory management behaviors almost negated that point: as one thirty-year veteran said, "It's no use having code that runs in lots of places if it runs differently in each."
Tim Peters <tim_one@email.msn.com>:
Nobody has been more vocal in support of these (& augmented assignments) than me, but I very strongly doubt they'll be in 1.6. In the interests of getting that out the door, Guido considers the 1.6 feature set to be frozen already.
I think part of the pressure to get one more feature in Python (again & again & again) is that release cycles have been soooooo protracted, now slobbering well over the full year mark. If I accomplish nothing else at BeOpen, I want to give that a major speed boost -- I don't think we should ever let 6 months go by without at least pumping out a bugfix release.
OK, I can buy this. Are there concrete plans (as in, a specified timeframe) for a release in which new features will be admitted? -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law"
[Tim, sez the 1.6 feature set should be considered frozen, and that Python should move to a much less sloth-like release schedule thereafter] [esr@thyrsus.com]
OK, I can buy this.
Comes with a 30-day warranty, too <wink>.
Are there concrete plans (as in, a specified timeframe) for a release in which new features will be admitted?
There damn well ought to be. PythonLabs will be having its first all-hands meeting tomorrow (Guido's been gone, I've been in this state less than a week, & I'm still not sure Jeremy Hylton exists), and rational, timely release schedules are certainly on my agenda. I have no problem with new features in minor releases either, provided they're 100% backward-compatible (e.g., list comprehensions, yes (so long as they don't introduce new bytecodes); having str(long) strip the trailing "L", no). More when we know more. and-less-when-we-know-less-ly y'rs - tim
participants (9)
-
Andrew M. Kuchling -
esr＠thyrsus.com -
Greg Ward -
Greg Wilson -
Guido van Rossum -
Ka-Ping Yee -
Paul Prescod -
Skip Montanaro -
Tim Peters