I strongly dislike Python 3
in [Python]
|
From: Martin v. Loewis on 27 Jun 2010 03:54 > I didn't notice this level of angst when Python made equally significant > changes going from 1.5 to 2.0... I think the *level* was about the same (IIRC). People would say that they ignore 2.x for years, and that it is important to continue supporting 1.5.2 for a long time (about until 2.4 was released). What's different now is the *amount* of angst. That's not surprising: there is a much larger user community now with investment into Python 2.x, and they are concerned, and worried about the work that they have to perform. In addition to your observations: what the 3.x haters fail to recognize is that the porting effort is actually much smaller than they think it is. Would they try it out, they'd notice that it didn't take so long, after all. Of course, porting from 2.x to 3.x is a skill to acquire, so it gets easier the more you memorize the differences and pitfalls. Regards, Martin
From: rantingrick on 27 Jun 2010 07:46 > > P.S. Am I the only one who has never, ever, even *seen* a 'print' > > statement in non-toy or non-bash-script-style code in any application > > or even third-party library I looked at? Except, on occasion, for > > quick and dirty debugging. Perhaps because I'm more used to > > cross-platform to windows development, where a stray print can > > actually break the entire application (depending on contexts, if one > > is run under a service or sometimes even pythonw) Oh i dunno, these "toys" include print... C:\Python26\Lib\abc.py C:\Python26\Lib\aifc.py C:\Python26\Lib\asyncore.py C:\Python26\Lib\atexit.py C:\Python26\Lib\audiodev.py C:\Python26\Lib\base64.py C:\Python26\Lib\BaseHTTPServer.py C:\Python26\Lib\Bastion.py C:\Python26\Lib\bdb.py C:\Python26\Lib\calendar.py C:\Python26\Lib\cgi.py C:\Python26\Lib\cmd.py C:\Python26\Lib\code.py C:\Python26\Lib\collections.py C:\Python26\Lib\compileall.py C:\Python26\Lib\Cookie.py C:\Python26\Lib\cookielib.py C:\Python26\Lib\copy.py C:\Python26\Lib\cProfile.py C:\Python26\Lib\decimal.py C:\Python26\Lib\difflib.py C:\Python26\Lib\dis.py C:\Python26\Lib\doctest.py C:\Python26\Lib\DocXMLRPCServer.py C:\Python26\Lib\dummy_thread.py C:\Python26\Lib\filecmp.py C:\Python26\Lib\fileinput.py C:\Python26\Lib\formatter.py C:\Python26\Lib\fpformat.py C:\Python26\Lib\ftplib.py C:\Python26\Lib\getopt.py C:\Python26\Lib\getpass.py C:\Python26\Lib\gettext.py C:\Python26\Lib\gzip.py C:\Python26\Lib\heapq.py C:\Python26\Lib\htmllib.py C:\Python26\Lib\httplib.py C:\Python26\Lib\ihooks.py C:\Python26\Lib\imaplib.py C:\Python26\Lib\imghdr.py C:\Python26\Lib\imputil.py C:\Python26\Lib\io.py C:\Python26\Lib\keyword.py C:\Python26\Lib\linecache.py C:\Python26\Lib\locale.py C:\Python26\Lib\macurl2path.py C:\Python26\Lib\mailcap.py C:\Python26\Lib\mhlib.py C:\Python26\Lib\mimetools.py C:\Python26\Lib\mimetypes.py C:\Python26\Lib\mimify.py C:\Python26\Lib\modulefinder.py C:\Python26\Lib\netrc.py C:\Python26\Lib\nntplib.py C:\Python26\Lib\opcode.py C:\Python26\Lib\optparse.py C:\Python26\Lib\os.py C:\Python26\Lib\pdb.py C:\Python26\Lib\pickletools.py C:\Python26\Lib\pipes.py C:\Python26\Lib\platform.py C:\Python26\Lib\plistlib.py C:\Python26\Lib\poplib.py C:\Python26\Lib\pprint.py C:\Python26\Lib\profile.py C:\Python26\Lib\pstats.py C:\Python26\Lib\pyclbr.py C:\Python26\Lib\pydoc.py C:\Python26\Lib\pydoc_topics.py C:\Python26\Lib\py_compile.py C:\Python26\Lib\quopri.py C:\Python26\Lib\random.py C:\Python26\Lib\rexec.py C:\Python26\Lib\rfc822.py C:\Python26\Lib\rlcompleter.py C:\Python26\Lib\runpy.py C:\Python26\Lib\sgmllib.py C:\Python26\Lib\shlex.py C:\Python26\Lib\SimpleXMLRPCServer.py C:\Python26\Lib\site.py C:\Python26\Lib\smtpd.py C:\Python26\Lib\smtplib.py C:\Python26\Lib\sndhdr.py C:\Python26\Lib\SocketServer.py C:\Python26\Lib\sre_compile.py C:\Python26\Lib\sre_constants.py C:\Python26\Lib\sre_parse.py C:\Python26\Lib\ssl.py C:\Python26\Lib\string.py C:\Python26\Lib\StringIO.py C:\Python26\Lib\stringold.py C:\Python26\Lib\subprocess.py C:\Python26\Lib\sunaudio.py C:\Python26\Lib\symbol.py C:\Python26\Lib\symtable.py C:\Python26\Lib\tabnanny.py C:\Python26\Lib\tarfile.py C:\Python26\Lib\telnetlib.py C:\Python26\Lib\textwrap.py C:\Python26\Lib\this.py C:\Python26\Lib\threading.py C:\Python26\Lib\timeit.py C:\Python26\Lib\tokenize.py C:\Python26\Lib\trace.py C:\Python26\Lib\traceback.py C:\Python26\Lib\unittest.py C:\Python26\Lib\urllib.py C:\Python26\Lib\urlparse.py C:\Python26\Lib\uu.py C:\Python26\Lib\warnings.py C:\Python26\Lib\webbrowser.py C:\Python26\Lib\whichdb.py C:\Python26\Lib\xmllib.py C:\Python26\Lib\xmlrpclib.py C:\Python26\Lib\zipfile.py C:\Python26\Lib\__future__.py .... just children's toy's i guess ;-)
From: Thomas Jollans on 27 Jun 2010 08:16 On 06/27/2010 01:46 PM, rantingrick wrote: > >>> P.S. Am I the only one who has never, ever, even *seen* a 'print' >>> statement in non-toy or non-bash-script-style code in any application >>> or even third-party library I looked at? Except, on occasion, for >>> quick and dirty debugging. Perhaps because I'm more used to >>> cross-platform to windows development, where a stray print can >>> actually break the entire application (depending on contexts, if one >>> is run under a service or sometimes even pythonw) > > Oh i dunno, these "toys" include print... Do your homework properly. I randomly checked a few of these. base64 includes a "Small main program", which is certainly "bash-script-style". Quite a few of the other files don't use print-the-statement/function at all, but use "print" as part of an identifier. Your grepping is sloppy, my friend! Granted, some use print to emit warnings (aifc for example). This isn't perfectly clean, of course, but it's not used a whole lot either. Mostly rather old code too, I think. And some (abc for example) use print in what looks like internal diagnostics methods. That being said, Stephen's statement was very broad, but I think it's true: print is primarily used in small scripts, or script-like testing functions/methods. Thomas > > C:\Python26\Lib\abc.py > C:\Python26\Lib\aifc.py > [ ... ]
From: David Cournapeau on 27 Jun 2010 08:41 On Sun, Jun 27, 2010 at 4:54 PM, Martin v. Loewis <martin(a)v.loewis.de> wrote: >> I didn't notice this level of angst when Python made equally significant >> changes going from 1.5 to 2.0... > > I think the *level* was about the same (IIRC). People would say that > they ignore 2.x for years, and that it is important to continue > supporting 1.5.2 for a long time (about until 2.4 was released). > > What's different now is the *amount* of angst. That's not surprising: > there is a much larger user community now with investment into Python > 2.x, and they are concerned, and worried about the work that they have > to perform. > > In addition to your observations: what the 3.x haters fail to recognize > is that the porting effort is actually much smaller than they think it > is. I think one point which needs to be emphasized more is what does python 3 bring to people. The" what's new in python 3 page" gives the impression that python 3 is about removing cruft. That's a very poor argument to push people to switch. I doubt "porting is easier than you think" will convince many people if they don't know what the gain will be. For example, porting numpy and scipy to py3k has been easier than I thought, but besides making it easier for other people to switch, I can't see *any* benefit. That's bound to frustrate people. David
From: Malte Dik on 27 Jun 2010 09:26
quote: > > I didn't notice this level of angst when Python made equally significant > changes going from 1.5 to 2.0... admittedly Python 1.5 code would work > unchanged in 2.0, but the 2.x series introduced MUCH bigger additions to > Python than anything 3.0 and 3.1 have added, and anyone taking advantage > of those changes is implicitly writing code which is not backwards > compatible. Maybe the print statement is like the wart of Python. It maybe ugly, but it adds character. Could you imagine Lemmy lasered his? Of course people are angsty that *their* Python might not be the same! But I can relieve those who are: The interactive command line shell IPython delivers an autocompletion where parenthesis for _any_ function may be left out. Now, how does that sound? Ruby anyone? ;) Sincerely, Malte |