«

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

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

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

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/

On Jun 27, 7:16*am, Thomas Jollans <tho...@jollans.com> 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.

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/