Re: I strongly dislike Python 3

Discussion in 'Python' started by Stefan Reich, Jun 26, 2010.

  1. Stefan Reich

    Stefan Reich Guest

    Stephen.

    Stephen Hansen schrieb:
    > If your biggest complaint is the print statement/function -- man,
    > you're looking small, and are in for a world of hurt when you get to
    > the bytes/[string|unicode] split hits.

    No, I'm not "looking small". I'm thinking big. I sometimes use seemingly
    small examples to illustrate a bigger problem which clearly seems to
    exist somewhere on your side.

    I'm also not in for a world of hurt, I'm glad to say.

    It really seems to me that you are an intellectually aggressive person
    that is not much worth talking to.
    > There's no "as long as" -- its done. Python 2 is over with 2.7.

    Well, then it is NOT done yet. And of course there is an "as long as".
    > The incompatibilities with Python 3 are intentional,

    What? For what reason? It seems that this is a pure power grabbing
    attempt. Forcing people to decide where, with proper project management,
    no hard decision of that kind would be necessary.
    > and although slow, momentum for migration to Python 3 does in my
    > anecdotal experience seem to be continuing steady -- so eventually,
    > Python 3'll be the norm.

    It may or not be the norm eventually; in either case, that doesn't
    explain or excuse the counterproductive choices made with Python 3.
    > Not that Python 2.7 will then die completely, I'm sure.

    Oh, so you are once again contradicting your earlier statement that "it
    is done". Seems to me you are trying to kill Python 2 a bit too fast.
    > The pydev's have even stated it'll have a longer then usual bugfix
    > maintenance period, recognizing some people will be on the Python 2
    > platform for years still.

    Hear hear! So we do exist, and we're not going away so quickly either.
    > --Stephen
    >
    > 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)

    God man, you need to stop bashing a perfectly good statement in an
    attempt to make you look like a "smart programmer" who "doesn't use
    print" in his "serious applications".

    Shaking my head,
    Stefan
    Stefan Reich, Jun 26, 2010
    #1
    1. Advertising

  2. Stefan Reich

    rantingrick Guest


    > > 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 ;-)
    rantingrick, Jun 27, 2010
    #2
    1. Advertising

  3. 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
    > [ ... ]
    Thomas Jollans, Jun 27, 2010
    #3
  4. On 6/27/10 5:16 AM, Thomas Jollans wrote:
    > 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...


    [replying to Rick here, just cuz! -- I can get two replies into one that
    way]

    You did see "or non-bash-script-style code" right? Or? Or, meaning it
    can be toy, or bash-script-style-code. Now you may have no idea what the
    latter means, but no: I rather explicitly included a whole category of
    uses which aren't toy code.

    [Now, back to Thomas!]

    > 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!


    Apparently he was confused between "a 'print' statement" and "the word
    print appearing somewhere in a file" :)

    > 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.


    I'd actually, personally, consider it a bug if any stdlib module used
    'print' in the normal course of operations (i.e., not during some
    test/debug mode, and not when the lib is run as a script and the print
    is just part of example/testing stuff in the __name__ == "__main__"
    guard) -- unless it was one of those platform-specific modules. I don't
    know if python-dev would agree with that assessment, but if I ever
    encountered one I'd write up a patch and submit a bug report.

    I haven't yet, so I'm pretty sure your analysis is correct.

    > 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.


    I was going a little bit down the hyperbole road with my wording of the
    statement, but yeah. I did a random checking of the list myself, and the
    only ones I found with actual print statements would qualify under what
    I *meant* in 'non-toy or non-bash-script-style code'.

    Its entirely possible that definition is not perfectly clear. But I'm
    really too tired to find a better way to describe it. You know. Quick
    glue-type and drive-other-things and test-this-out and one-off sort of
    activities.

    There's nothing *wrong* with that kind of code or the people who use it.
    Doing those kinds of activities in Python makes way more sense then
    doing it in say, bash or perl :) (I'm biased on the latter in that perl
    makes my eyes cross and despite many attempts, learning even rudimentary
    perl has defied me)

    But its also the kind of code which, in my personal experience, tends to
    -not- use advanced new features of the language, and which tends to
    -not- be the kind of stuff which gets run on a platform whose Python
    version evolves very fast if at all.

    Then again, I have seen one instance where a heavily "scripted"
    environment made up of basically a bunch of interlocking Python scripts,
    sort of spontaneously evolved into a MCP, and advanced features started
    spreading around. It wouldn't at all have surprised me if the MCP put
    various scripts into laser bike races to see which were the best for its
    purposes.

    --

    ... Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/
    Stephen Hansen, Jun 27, 2010
    #4
  5. Stefan Reich

    rantingrick Guest

    On Jun 27, 7:16 am, Thomas Jollans <> wrote:

    > 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.


    You sure are going to great lengths to protect Stephens assertion ;)

    > 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.


    No, Stephen's comments were NOT general in any way and they where in
    fact very specific... "If you use the print statement/function you're
    are a noob and your code is a toy". And i think there's and air of
    "also you're beneath me" in the tone of it too.
    rantingrick, Jun 27, 2010
    #5
  6. On 6/27/10 9:26 AM, rantingrick wrote:
    >> 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.

    >
    > No, Stephen's comments were NOT general in any way and they where in
    > fact very specific... "If you use the print statement/function you're
    > are a noob and your code is a toy". And i think there's and air of
    > "also you're beneath me" in the tone of it too.


    Excuse me?

    You do not speak for me. Do not put words into my mouth: especially
    words which are not at *all* what I said.

    I said, "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".

    If you actually practice your reading comprehension-- I know this is
    difficult for you-- then you would see there's three categories of
    places I have seen print statements:

    - Toys (do you even know what I mean by that?)
    - Bash-script-style code (this is /very/ broad, and I do it all the time)
    - Debugging (qualified as 'quick and dirty', as opposed to debugging
    using say, the logging module or some other framework)

    I then further qualified that its possible my own personal experience is
    the way it is, because I may be using applications and libraries which
    focus more on windows support then others who may be doing a great deal
    more in a pure-Unix environment where things are more sensible (i.e., a
    program always has a stdout, even if its /dev/null, as opposed to on
    windows, where you sometimes just have none at all, and writing to it
    kills your program).

    For you to mischaracterize that all into, "you're a noob and your code
    is a toy" goes far beyond simple misunderstanding and into malicious
    false attribution.

    Usually our disagreements have at least the vaguest *semblance* of an
    actual argument, notwithstanding your long wanderings in sophistry and
    substance-less rants. Now if you've decided to go down the path of
    rewriting what I say into something it completely isn't, instead of
    actually responding to it: then I have no time for you.

    You're *this* close to getting killfiled after all. Your usual nonsense
    is one thing, you usually have the barest sense of decency to actually
    quote me when you respond. If you're going to paraphrase me, do so
    accurately at least-- or do so after quoting what I actually said, if
    you wish to reinterpret my words.

    --

    ... Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/
    Stephen Hansen, Jun 27, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Reich

    I strongly dislike Python 3

    Stefan Reich, Jun 26, 2010, in forum: Python
    Replies:
    1
    Views:
    284
    Lawrence D'Oliveiro
    Jun 27, 2010
  2. Thomas Jollans

    Re: I strongly dislike Python 3

    Thomas Jollans, Jun 26, 2010, in forum: Python
    Replies:
    52
    Views:
    1,474
    Chris Rebert
    Jul 2, 2010
  3. Stephen Hansen

    Re: I strongly dislike Python 3

    Stephen Hansen, Jun 26, 2010, in forum: Python
    Replies:
    12
    Views:
    478
    Andreas Waldenburger
    Jun 27, 2010
  4. Terry Reedy

    Re: I strongly dislike Python 3

    Terry Reedy, Jun 27, 2010, in forum: Python
    Replies:
    43
    Views:
    1,144
  5. John Nagle
    Replies:
    79
    Views:
    1,892
    Philip Semanchuk
    Jul 8, 2010
Loading...

Share This Page