I strongly dislike Python 3

[Stephen Hansen]

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/