From: Peter Kleiweg on
David Cournapeau schreef op de 27e dag van de zomermaand van het jaar 2010:

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

The latest NumPy is 1.4.1, and it does not install with Python 3.1.1

--
Peter Kleiweg L:NL,af,da,de,en,ia,nds,no,sv,(fr,it) S:NL,de,en,(da,ia)
info: http://www.let.rug.nl/kleiweg/ls.html
From: David Cournapeau on
On Sun, Jun 27, 2010 at 11:46 PM, Peter Kleiweg <p.c.j.kleiweg(a)rug.nl> wrote:
> David Cournapeau schreef op de 27e dag van de zomermaand van het jaar 2010:
>
>> 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.
>
> The latest NumPy is 1.4.1, and it does not install with Python 3.1.1

The 3.x support for numpy is in the trunk

David
From: Stephen Hansen on
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/

From: rantingrick on
On Jun 27, 7:16 am, Thomas Jollans <tho...(a)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.
From: Andreas Waldenburger on
On Sun, 27 Jun 2010 02:45:37 +0100 Nobody <nobody(a)nowhere.com> wrote:

> On Sat, 26 Jun 2010 21:08:48 +0200, Martin v. Loewis wrote:
>
> >> I think that's not true. If enough people want to support Python 2
> >> it might be possible to advance Python 2.
> >
> > That won't be sufficient: enough people wanting support won't have
> > any effect. People also need to want it enough to actually fork from
> > python.org.
>
> This will happen.
>
> > They would then have to convince Linux packagers to include
> > it in the distribution even though it's not available from
> > python.org,
>
> So will this.
>
> [snip]
>
So your crystal ball is working, eh?

Good for you, mine was a scam.

;)
/W


--
INVALID? DE!