I strongly dislike Python 3
in [Python]
|
From: Stephen Hansen on 30 Jun 2010 22:13 On 6/30/10 6:48 PM, John Nagle wrote: > The 10th anniversary of the announcement of PERL 6 is coming > up on July 19th, and it still hasn't displaced PERL 5 as the > "primary" version. Now, I may be totally off-base, because I do not grok perl and so have never made much of an effort to follow perl-- but ... isn't Perl 6 not _unfinished_? If so, I don't quite see the comparison. I mean, sure. Python 3 has some rough edges, but it is released and supported. Its basically an evolution (with an extinction event going on at the same time), and not a redesign or rewrite, which to my understanding, Perl 6 is. I do realize Perl 6 is actually a specification and not an implementation(and that it very carefully makes that distinction), and there is more then one implementation of that spec-- but I was under the impression it was only partially completed and/or still manifesting. I just hadn't ever heard of or seen Perl6 in _use_ anywhere, or even available*. Granted, I am neither omniscient nor in any way connected to those sorts of places where you are likely to see that, so it might be my own personal tunnel vision. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ *To contrast, the last two hosting providers I did business with, both had Python 3 available... now, I qualify that contrast with an acknowledgment that while available, it's probably of very little use in the current state, with WSGI** not being ready for the bytes/unicode split yet. These claims or observations are not meant to be 'This P is better then that P'. ** Yes, I have drank the WSGI kool-aid offiically, and can't really acknowledge the viability of non-WSGI based Python web development. I admit it is quite possibly an entirely uninformed position to hold and therefore shall not evangelize my faith, since I have enough sense to realize its probably not reasonable. It still works for me!
From: MRAB on 30 Jun 2010 22:26 John Nagle wrote: > On 6/27/2010 1:09 PM, Martin v. Loewis wrote: >>> I agree that there may be not much reason to port custom proprietary >>> apps that are working fine and which would hardly benefit from, let >>> alone need, and new Py3 features. >> >> In the long run, there will be a benefit: at some point in the future >> (surely years from now), /usr/bin/python will be Python 3. > > I'd argue that the name of Python 3 should be consistently > be "python3" in distributions. Python versions are going to have to > coexist for most of the next decade, and this will avoid > confusion. > > The 10th anniversary of the announcement of PERL 6 is coming > up on July 19th, and it still hasn't displaced PERL 5 as the > "primary" version. > Perl 6 is a lot of more different from Perl 5 than Python 3 is from Python 2.
From: geremy condra on 30 Jun 2010 22:50 On Wed, Jun 30, 2010 at 10:06 PM, Steven D'Aprano <steve-REMOVE-THIS(a)cybersource.com.au> wrote: > On Wed, 30 Jun 2010 18:57:58 -0400, geremy condra wrote: > >>>> Actually, I agree with this complaint though- it is much easier to >>>> type spaces than parens. >>> >>> Yes. And typing "p" is easier than typing "print". Perhaps we should >>> replace all Python built-ins with one letter names so that we can >>> *really* optimize our typing effort? > [...] >>> Perhaps not. >>> >>> The rule against premature optimization doesn't just apply to *code*. >> >> Hypocrite. You just took Jorgen Grahn to task in another thread for >> slaying exactly this kind of strawman. You're too smart to think that >> this is what I was advocating. > > You're correct, I didn't think that's what *you* were advocating, and I'm > sorry if that's the impression I gave. I agreed with you that typing > "print space args" is easier than "print left-paren args right-parens", > but then took that micro-optimization to its (il)logical conclusion, and > demonstrated that trying to minimize typing effort is a mug's game. You > might call it a strawman, but I prefer to call it reductio ad absurdum. > > (That's not to say that we should *maximize* typing either.) Fair enough. > Consistency, expressiveness, readability and re-usability are at least as > important as minimizing typing, and probably more so. The micro-cost of > typing print-as-a-function over print-as-a-statement is, I believe, far > outweighed by the other advantages. Personally I don't use print often enough to either be a significant victim of its the change or to take substantial advantage of it, but it is jarring enough that it annoys, which is pretty much all I was saying. > But like all optimizations, measure measure measure. If it turns out that > adding parentheses to print really does add a significant drain on > programmer productivity, then removing them again would no longer be a > premature micro-optimization but an actual optimization. > > But, honestly, is there anyone here, even the most heavy users of print, > who would seriously expect that adding parentheses to print calls will do > more than add a tiny fraction to the amount of typing effort already > required to use Python? I suppose in principle those extra three key > presses (shift-9 shift-0 vs space) could be the straw that breaks the > camel's back, but I doubt it. It certainly wasn't for me. I'm probably one of the very few people who is currently paid to write pure python3 and I'm fairly confident that print could have been entirely removed without greatly changing the fact that I prefer it. Having said that, I do occasionally find myself cursing at the command prompt over it. Geremy Condra
From: Ben Finney on 30 Jun 2010 23:13 Steven D'Aprano <steve-REMOVE-THIS(a)cybersource.com.au> writes: > But, honestly, is there anyone here, even the most heavy users of > print, who would seriously expect that adding parentheses to print > calls will do more than add a tiny fraction to the amount of typing > effort already required to use Python? I suppose in principle those > extra three key presses (shift-9 shift-0 vs space) could be the straw > that breaks the camel's back, but I doubt it. There's also Fitt's Law to consider: the space bar is big and easily-placed and hence easy to type in the middle of a stream of other keystrokes. None of that is true for the parens. -- \ “I turned to speak to God/About the world's despair; But to | `\ make bad matters worse/I found God wasn't there.” —Robert Frost | _o__) | Ben Finney
From: Steven D'Aprano on 1 Jul 2010 00:47
On Thu, 01 Jul 2010 13:13:53 +1000, Ben Finney wrote: > Steven D'Aprano <steve-REMOVE-THIS(a)cybersource.com.au> writes: > >> But, honestly, is there anyone here, even the most heavy users of >> print, who would seriously expect that adding parentheses to print >> calls will do more than add a tiny fraction to the amount of typing >> effort already required to use Python? I suppose in principle those >> extra three key presses (shift-9 shift-0 vs space) could be the straw >> that breaks the camel's back, but I doubt it. > > There's also Fitt's Law to consider: the space bar is big and > easily-placed and hence easy to type in the middle of a stream of other > keystrokes. None of that is true for the parens. This is true, but there's nothing unique to print about that. Personally, I think that the parentheses should be where the square brackets are, square brackets should be moved to where curly brackets are, and curly brackets moved to shift-9 and shift-0. But I don't care enough to remap my keyboard. -- Steven |