Re: Why has python3 been created as a seperate language where there is still python2.7 ?

[Stefan Behnel]

gmspro, 24.06.2012 05:46:
> Why has python3 been created as a seperate language where there is still python2.7 ?
>
> What's the benifit to make python3 over python2.7 ? I have read this though: http://docs.python.org/release/3.0.1/whatsnew/3.0.html
>
> What's wrong editing/customizing/changin python2.7 instead of making a seperate language?
>
> What's wrong working with python2.7?
>
> As python3 is not backward compatible, so many packages built on python2.7 will be gone someday. Or you have to re-write/upgrade to python3. That's a tedious/labourious task.
>
> So after 5 years will we get another python4 as seperate language?
>
> Any answer will be highly appreciated.

Note that this topic has been discussed in full and overly full length
several times on this list. You may want to read up on it in the archives.

I'm not sure if you're just trolling (posting suggestive questions with
well-known answers is a well established troll metier) or if you really
want an answer to your questions, but here's a short answer anyway.

The intention of Py3 was to deliberately break backwards compatibility in
order to clean up the language. The situation is not as bad as you seem to
think, a huge amount of packages have been ported to Python 3 already
and/or work happily with both language dialects. It's not an either-or kind
of thing, you can have both with a little effort.

And, no, there won't be a Py4 in 5 years. The established release time
frame is way longer.

Stefan

[Andrew Berg]

On 6/23/2012 10:46 PM, gmspro wrote:
> What's wrong editing/customizing/changin python2.7 instead of making a
> seperate language?

py3k is not a separate language. In fact, it is possible to maintain a
codebase that supports 2.2 (maybe even older), 3.3, and every version in
between.

> What's wrong working with python2.7?

A lot. Off the top of my head:
In 2.7, the print statement has arbitrary and unobvious syntax. The
print() function has arguments.
In 2.7, input() evaluates incoming strings, which is almost always not
appropriate and can lead to exploits. In py3k, input() doesn't do this.
It returns exactly what it receives.

I barely work with 2.x at all; others will be able to list many more in
much more detail.

> As python3 is not backward compatible, so many packages built on
> python2.7 will be gone someday. Or you have to re-write/upgrade to
> python3. That's a tedious/labourious task.

Indeed. Backward compatibility is important, but it should not be king.
Python had (and arguably still has) major issues that could only be
fixed by breaking backward compatibility.
AFAIK, people use 2.x mainly because they depend on libraries that are
not compatible with py3k yet (e.g., Twisted) or because their preferred
implementation does not implement 3.x (e.g., Jython, PyPy).

> So after 5 years will we get another python4 as seperate language?

No, but there may be changes that aren't backward compatible.

--
CPython 3.3.0a4 | Windows NT 6.1.7601.17803

[Michiel Overtoom]

On Jun 24, 2012, at 05:46, gmspro wrote:

> Why has python3 been created as a seperate language where there is still python2.7?

It has not. Python2 and Python3 are very similar. It's not like if you learn Python using version 2, you have to relearn the language when you want to switch Python3. The syntax is the same, only 'print' is a function instead of a statement. Other improvements are unicode strings, cleanups in the library, lazy iterators, new-style classes by default etc... mostly background stuff you won't even notice in daily Python use.

Greetings,

--
Test your knowledge of flowers! http://www.learn-the-flowers.com
or http://www.leer-de-bloemen.nl for the Dutch version.

Test je kennis van bloemen! http://www.leer-de-bloemen.nl
of http://www.learn-the-flowers.com voor de Engelse versie.

[rantingri...@gmail.com]

On Monday, June 25, 2012 5:10:47 AM UTC-5, Michiel Overtoom wrote:
> It has not. Python2 and Python3 are very similar. It's not like if
> you learn Python using version 2, you have to relearn the language
> when you want to switch Python3. The syntax is the same, only
> 'print' is a function instead of a statement.

However, there is something to be said for "old habits die hard". I myself lament every time i must type->(, then blah, then->) AGAIN!. My fingers are hardwired for the old print statement. Damned that Guido and his mind games!

http://www.youtube.com/watch?v=-Ny42Mdg5qo

[rantingri...@gmail.com]

On Monday, June 25, 2012 5:10:47 AM UTC-5, Michiel Overtoom wrote:

> It has not. Python2 and Python3 are very similar. It's not like if
> you learn Python using version 2, you have to relearn the language
> when you want to switch Python3. The syntax is the same, only
> 'print' is a function instead of a statement.

[Steven D'Aprano]

(Rick, don't make me regret communicating with you again.)

On Mon, 25 Jun 2012 19:28:01 -0700, rantingrickjohnson wrote:

> However, there is something to be said for "old habits die hard". I
> myself lament every time i must type->(, then blah, then->) AGAIN!. My
> fingers are hardwired for the old print statement. Damned that Guido and
> his mind games!

There's no real difference between typing print(...) and all the other
functions in Python. Do you lament having to type len(obj) instead of
"len obj" or list(zip(a, b, c)) instead of "list zip a b c"?

Making print a statement in the first place was a mistake, but
fortunately it was a simple enough mistake to rectify once the need for
backward compatibility was relaxed.


--
Steven

[Terry Reedy]

On 6/25/2012 11:35 PM, Steven D'Aprano wrote:
> (Rick, don't make me regret communicating with you again.)
>
> On Mon, 25 Jun 2012 19:28:01 -0700, rantingrickjohnson wrote:
>
>> However, there is something to be said for "old habits die hard". I
>> myself lament every time i must type->(, then blah, then->) AGAIN!. My
>> fingers are hardwired for the old print statement. Damned that Guido and
>> his mind games!
>
> There's no real difference between typing print(...) and all the other
> functions in Python.

Yes there is ... as Rick said, habit. I still sometimes forget ;-(

> Do you lament having to type len(obj) instead of
> "len obj" or list(zip(a, b, c)) instead of "list zip a b c"?

No.

> Making print a statement in the first place was a mistake, but
> fortunately it was a simple enough mistake to rectify once the need for
> backward compatibility was relaxed.

Complete agreed. I have used all of sep=, end=, and file= at various times.

--
Terry Jan Reedy

[Jeremiah Dodds]

I'm of the opinion that the solution to this involves configuring your editor.

[Devin Jeanpierre]

On Mon, Jun 25, 2012 at 11:35 PM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> There's no real difference between typing print(...) and all the other
> functions in Python. Do you lament having to type len(obj) instead of
> "len obj" or list(zip(a, b, c)) instead of "list zip a b c"?

Surely you mean "list $ zip a b c"? ;)

But yes, it's really not a big deal. It's a trivial change, and one
that 2to3 can handle really easily.

>
> Making print a statement in the first place was a mistake, but
> fortunately it was a simple enough mistake to rectify once the need for
> backward compatibility was relaxed.

Hmmm, why is the function so much better than the statement? You like
using it in expressions? Or is it that you like passing it in as a
callback?

-- Devin

[Stefan Behnel]

Jeremiah Dodds, 26.06.2012 07:04:

> I'm of the opinion that the solution to this involves configuring your editor.

But wasn't the whole idea behind Python to be accessible for innocent
users? Isn't the one and only acceptable goal of a language cleanup that
those who do not have the expert knowledge to configure the editor of their
choice should finally be able to wholeheartedly type down their Pythonish
code without having the parser allude them to the one holy way from time to
time? It clearly cannot have achieved that goal, given the amount of
traffic on this list, can it?

Maybe we should add a remote error reporting mode to Python that sends all
syntax error messages not only to the local screen but also directly to the
PSF so that they can fund developers who are able to delete that error
message from the interpreter based on real world statistical evidence. That
would eventually make the language match the powerset of what all users
have in their fingers. A very worthy goal, if you ask me.

Stefan

[Stefan Behnel]

Devin Jeanpierre, 26.06.2012 08:15:

> On Mon, Jun 25, 2012 at 11:35 PM, Steven D'Aprano

>> Making print a statement in the first place was a mistake, but
>> fortunately it was a simple enough mistake to rectify once the need for
>> backward compatibility was relaxed.
>

> Hmmm, why is the function so much better than the statement? You like
> using it in expressions? Or is it that you like passing it in as a
> callback?

First of all, the statement has a rather special syntax that is not obvious
and practically non-extensible. It also has hidden semantics that are hard
to explain and mixes formatting with output - soft-space, anyone?

The function is straight forward, configurable, does one thing, works with
help() and doesn't get in the way. And something as rarely[1] used as a
print simply doesn't deserve special syntax. Oh, and, yes, you can even
pass it into some code as callback, although I rarely had a need for that.

Stefan


[1] Seriously, it's not very helpful in interactive mode and too simplistic
to be used in application code. Even scripts often work better with logging
than with prints.

[Steven D'Aprano]

On Tue, 26 Jun 2012 02:15:17 -0400, Devin Jeanpierre wrote:

>> Making print a statement in the first place was a mistake, but
>> fortunately it was a simple enough mistake to rectify once the need for
>> backward compatibility was relaxed.
>
> Hmmm, why is the function so much better than the statement? You like
> using it in expressions? Or is it that you like passing it in as a
> callback?

Simplicity: there doesn't seem to be anything special about print that
requires it to be syntax instead of just a built-in function. Nearly
everything else which is handled by syntax is special: assignment,
deletion, imports, flow control. (Decorators are the obvious exception,
but they are pure syntactic sugar.)

Consistency: print as a function isn't a special case to be learned.
There's no need to memorise magic syntax to control it, you just pass
ordinary arguments using ordinary syntax. Instead of arcane and bizarre
special cases like this:

print >>sys.stderr, spam, ham, eggs,

you just use:

print(spam, ham, eggs, file=sys.stderr, end='')

While it's a tad longer, there's no special syntax to be learned.

Practicality: as a function, you can use print anywhere you can use other
functions. You can bind it to another name, pass it as argument to
another function such as help(), store it in a list, use it as a
callback, or monkey-patch it, without needing to write a wrapper
"print_" (or "prnt", "pr", etc.) around it.


Compare that to print as a statement, which only has one argument in
favour: backwards compatibility.



--
Steven

[John Nagle]

On 6/25/2012 1:36 AM, Stefan Behnel wrote:
> gmspro, 24.06.2012 05:46:
>> Why has python3 been created as a seperate language where there is still python2.7 ?

> The intention of Py3 was to deliberately break backwards compatibility in
> order to clean up the language. The situation is not as bad as you seem to
> think, a huge amount of packages have been ported to Python 3 already
> and/or work happily with both language dialects.

The syntax changes in Python 3 are a minor issue for
serious programmers. The big headaches come from packages that
aren't being ported to Python 3 at all. In some cases, there's
a replacement package from another author that performs the
same function, but has a different API. Switching packages
involves debugging some new package with, probably, one
developer and a tiny user community.

The Python 3 to MySQL connection is still a mess.
The original developer of MySQLdb doesn't want to support
Python 3. There's "pymysql", but it hasn't been updated
since 2010 and has a long list of unfixed bugs.
There was a "MySQL-python-1.2.3-py3k" port by a third party,
but the domain that hosted it
("http://www.elecmor.mooo.com/python/MySQL-python-1.2.3-py3k.zip") is
dead. There's
MySQL for Python 3 (https://github.com/davispuh/MySQL-for-Python-3)
but it doesn't work on Windows. MySQL Connector
(https://code.launchpad.net/myconnpy) hasn't been updated in a
while, but at least has some users. OurSQL has a different
API than MySQLdb, and isn't quite ready for prime time yet.

That's why I'm still on Python 2.7.

John Nagle

[Chris Angelico]

On Wed, Jun 27, 2012 at 7:08 AM, John Nagle <na...@animats.com> wrote:
>    The Python 3 to MySQL connection is still a mess.
> The original developer of MySQLdb doesn't want to support
> Python 3.

This is where I would start asking: How hard is it to migrate to
another SQL database (eg Postgres)? That is, assuming that there's one
with proper Py3 support. But I would find it hard to believe that
there's _no_ good database with a Python 3 access module.

ChrisA

[HoneyMonster]

psycopg2 (Python interface to PostgreSQL) supports Python 3.1 and 3.2 as
well as Python 2. It works superbly.

PostgreSQL is a far better database then MySQL anyway.

[Christian Tismer]

On 26.06.12 08:34, Stefan Behnel wrote:
> Devin Jeanpierre, 26.06.2012 08:15:
>> On Mon, Jun 25, 2012 at 11:35 PM, Steven D'Aprano

>>> Making print a statement in the first place was a mistake, but
>>> fortunately it was a simple enough mistake to rectify once the need for
>>> backward compatibility was relaxed.

>> Hmmm, why is the function so much better than the statement? You like
>> using it in expressions? Or is it that you like passing it in as a
>> callback?

> First of all, the statement has a rather special syntax that is not obvious
> and practically non-extensible. It also has hidden semantics that are hard
> to explain and mixes formatting with output - soft-space, anyone?
>
> The function is straight forward, configurable, does one thing, works with
> help() and doesn't get in the way. And something as rarely[1] used as a
> print simply doesn't deserve special syntax. Oh, and, yes, you can even
> pass it into some code as callback, although I rarely had a need for that.
>

I agree, and I don't want to revive an old discussion of the print statement.
I just still don't see the point why the transition is made so uni-directional?

With python2.7, it is great that "from __future__ import print_function"
exists.

But porting old code (PIL for instance) imposes a lot of changes which
don't make sense, but produce overhead. Some are simple things like
the print statement, which is used only in the debugging code.
Enforcing the syntax change enforces changing many modules, which could
otherwise work just fine as they are.

I think, for the small importance of the print statement in code, it
would have made the transition easier, if python 3 was as flexible
as python 2.7, with a symmetric

"from __past__ import print_statement" construct.

That would have at least my acceptance much quicker, because the necessity
of modifying stuff would reduce to the few changes which are important
in a few modules.

So right now, I try to use python 3, but the flexibility is right now
in python2.7 .

cheers - Chris

--
Christian Tismer :^) <mailto:tis...@stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
work +49 173 24 18 776 mobile +49 173 24 18 776 fax n.a.
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Chris Angelico]

On Wed, Jun 27, 2012 at 8:25 PM, Christian Tismer <tis...@stackless.com> wrote:
> I think, for the small importance of the print statement in code, it
> would have made the transition easier, if python 3 was as flexible
> as python 2.7, with a symmetric
>
> "from __past__ import print_statement" construct.
>

For how long? Will Python require, in perpetuity, the code to support
this? Must the print statement be enhanced when the print function is?
What about bug fixes? How much dev time is required to enable backward
compatibility past a boundary across which backward compatibility was
not promised? And if there's a limit to the duration of this __past__
directive, when should it be and what should happen after that point?

Much easier to simply say no.

ChrisA

[Stefan Behnel]

Chris Angelico, 27.06.2012 13:02:

> On Wed, Jun 27, 2012 at 8:25 PM, Christian Tismer wrote:
>> I think, for the small importance of the print statement in code, it
>> would have made the transition easier, if python 3 was as flexible
>> as python 2.7, with a symmetric
>>
>> "from __past__ import print_statement" construct.
>
> For how long? Will Python require, in perpetuity, the code to support
> this? Must the print statement be enhanced when the print function is?
> What about bug fixes? How much dev time is required to enable backward
> compatibility past a boundary across which backward compatibility was
> not promised? And if there's a limit to the duration of this __past__
> directive, when should it be and what should happen after that point?
>
> Much easier to simply say no.

I concur. For supporting something that shouldn't have been there in the
first place, such as a print statement in production code, it's way too
much overhead to keep it working despite of significant changes in the I/O
layer that went into Python 3.x, including the removal of the soft-space
"feature".

For comparison, the revival of the "u" string prefix in Py3.3 is a simple
change in the parser grammar that's easy to maintain but that has a huge
impact on the Py3 compatibility of code that accepts to drop support for
Py2.5 and earlier (as well as Py3.[012]) but wants to keep working in
Py2.[67] (which supports the opposite "b" prefix). We've been supporting
that in Cython for a while and it worked out really well so far.

Stefan

[Devin Jeanpierre]

On Wed, Jun 27, 2012 at 7:02 AM, Chris Angelico <ros...@gmail.com> wrote:
> Much easier to simply say no.

It's also easier to cease developing Python at all.

By which I mean: just because something is hard doesn't mean it
shouldn't be done. Lots of things Python does are hard, but they make
users' lives easier. The question should probably be where developer
effort is best spent, not where developers spend the least effort.

-- Devin

[Roy Smith]

In article <mailman.1503.1340677...@python.org>,

On the other hand, I hate it (in P2) when I want to change a print to a
pprint and have to add the parens, then take them back out when I want
to go back to plain print.

[Chris Angelico]

Of course, of course. Easier doesn't necessarily mean better. But
there's a much larger cost to this kind of backward compatibility than
many people realize.

ChrisA

[Christian Tismer]

On 27.06.12 13:02, Chris Angelico wrote:

> On Wed, Jun 27, 2012 at 8:25 PM, Christian Tismer <tis...@stackless.com> wrote:
>> I think, for the small importance of the print statement in code, it
>> would have made the transition easier, if python 3 was as flexible
>> as python 2.7, with a symmetric
>>
>> "from __past__ import print_statement" construct.
>>
> For how long? Will Python require, in perpetuity, the code to support
> this? Must the print statement be enhanced when the print function is?
> What about bug fixes? How much dev time is required to enable backward
> compatibility past a boundary across which backward compatibility was
> not promised? And if there's a limit to the duration of this __past__
> directive, when should it be and what should happen after that point?
>

> Much easier to simply say no.

Just as a note:
It is not that I'm lazy or against python3 or anything.
The opposite is true, as I'm a long-term developer and python evangelist.

My argument simply addresses to get as much acceptance of python3
as quickly as possible, and some hard work put into a backward
feature would IMHO have been better for python3.

I would even like much more drastic changes that python3 actually
does, to make the move really worth moving.

What happened was a bit the opposite: huge effort for making a really
useful python 2.7. My strategy would have put less effort into that,
and more to make python3 clearly the thing that people want and need.
Right now I think python 2.7 is simply too good.

-----
And especially for the print statement:

It is a bad idea that the print statement _must_ create a syntax error.
It is IMHO not important to support it really and could just work more
or less, with no new features, because as said:

print, function or not, is not important enough to enforce a rewrite
everywhere because of syntax error. That hides the real semantic
changes which _are_ important.

So what I would have done is to let it work in an imperfect way. People
then have the chance to rewrite with the print function, where it makes
sense. But old packages which need to be changed, only because they
have lots of

if DEBUG:
print xxx, yyy, ...

could just stay unchanged or migrated later after the real meat has
been properly tested etc. Well, I missed the right time to discuss that,
so this is just a useless note about history.

cheers -- Chris

[Chris Angelico]

On Wed, Jun 27, 2012 at 11:15 PM, Christian Tismer <tis...@stackless.com> wrote:
> So what I would have done is to let it work in an imperfect way. People
> then have the chance to rewrite with the print function, where it makes
> sense. But old packages which need to be changed, only because they
> have lots of
>
>    if DEBUG:
>        print xxx, yyy, ...
>
> could just stay unchanged or migrated later after the real meat has
> been properly tested etc.

Far as I can tell, these sorts of things ought all to be handled by
2to3. No problem once you're looking at migrating.

ChrisA

[Stefan Behnel]

Christian Tismer, 27.06.2012 15:15:

> print, function or not, is not important enough to enforce a rewrite
> everywhere because of syntax error. That hides the real semantic
> changes which _are_ important.
>

> So what I would have done is to let it work in an imperfect way. People
> then have the chance to rewrite with the print function, where it makes
> sense. But old packages which need to be changed, only because they
> have lots of
>
> if DEBUG:
> print xxx, yyy, ...
>
> could just stay unchanged or migrated later after the real meat has
> been properly tested etc.

Well, at least a SyntaxError makes it easy to find. And even if you don't
intend to use 2to3, you can still run it once to generate a patch for you
that only fixes up "print". In many cases, that will also make it work in
Py2 in such an "imperfect" way, either by doing the right thing already or
by printing out a tuple instead of a space separated string. If it's only
for debug output (which, as I said, would better be served by the logging
module), I can't see why that would be all that unacceptable.

Stefan

[Christian Tismer]

Ok, here comes the real story:
I extracted a few files from the old PIL package and made the stuff that was
needed for my own little utility with a couple of monkey-patches, import
hooks etc. After quite some trouble, this worked unter python 2.6 and 2.7,
with the unchanged original PIL files.
And I was after that: abuse PIL without maintaining it!

Then I got real problems when trying to make it run under python 3.2,
and from then on I needed two sets of source files, mostly because of
the print mess.
Most other things were adjustable by monkey-patches, moving to the io
module etc. etc.

In the end, the only thing that required a real change of source code
that I could not circumvent was the indexing of bytes, which is giving
chars under python 2.x, but integers under 3.x.

At this point my hope to keep the unmodified PIL files died, although
without print, this would have been an isolated single 20 lines block
in the TiffImagePlugin only, instead of much more changes criss-cross over
several sources.

Anyway, I ended up with a port of the relevant PIL files to python 3
with some backward-compatible additions (for heaven's sake, at least
python 3 accepts the __future__ imports), so now I'm down to single
source files, but unfortunately changed files, and I have to track
changes in the future.

That battle was lost: I wanted the PIL files simply to be drop-ins,
without going to work on PIL, because then I would do a complete
rewrite after some discussion with the author.

That's why I was unhappy with py3's missing flexibility.

ciao -- Chris

[Serhiy Storchaka]

On 27.06.12 17:34, Christian Tismer wrote:
> That's why I was unhappy with py3's missing flexibility.

Excessive flexibility is amorphism.

[Serhiy Storchaka]

On 27.06.12 14:22, Stefan Behnel wrote:
> For comparison, the revival of the "u" string prefix in Py3.3 is a simple
> change in the parser grammar that's easy to maintain but that has a huge
> impact on the Py3 compatibility of code that accepts to drop support for
> Py2.5 and earlier (as well as Py3.[012]) but wants to keep working in
> Py2.[67] (which supports the opposite "b" prefix).

And even this simple change has caused unexpected issues (see issues
#15054 and #15096), which were not predicted by the preceding stormy
discussion. IMHO, the negative consequences of this change are undervalued.

[Terry Reedy]

On 6/27/2012 3:08 PM, Serhiy Storchaka wrote:
> On 27.06.12 14:22, Stefan Behnel wrote:
>> For comparison, the revival of the "u" string prefix in Py3.3 is a simple
>> change in the parser grammar that's easy to maintain

> And even this simple change has caused unexpected issues (see issues
> #15054 and #15096), which were not predicted by the preceding stormy
> discussion.

#15054 was mostly not about 'u'.

http://bugs.python.org/issue15096 is about 'u', or rather about the post
discussion extension of 'u' to 'ur'. During the discussion of 'u', I
predicted that adding 'innocuous' 'u' would lead to efforts to add other
things. Adding 'ur' was the first example of that. We are fortunate that
someone decided to test the new feature at the alpha stage. At least the
near fiasco is a lesson.

> IMHO, the negative consequences of this change are undervalued.

Another prediction: people who code Python without reading the manual,
at least not for new features, will learn about 'u' somehow (such as by
reading this list) and may do either of the following, both of which are
bad.

1. They will confuse themselves by thinking that 'u' actually means
somethings. They may then confuse others by writing about its supposed
meaning. This might get amusing.

2. They will use 'u' in Python 3 only code, thereby making it
incompatible with 3.2-, even if it otherwise would not be.

These two actions will reinforce each other.

--
Terry Jan Reedy

[Christian Tismer]

Random notes without context and reasoning are no better than spam.
My answer as well, of course, so let's stop here.

[alex23]

On Jun 28, 8:11 am, Christian Tismer <tis...@stackless.com> wrote:
> Random notes without context and reasoning are no better than spam.
> My answer as well, of course, so let's stop here.

It's more that all of this has been discussed at length. Repeatedly.
It's very easy to criticise the current state of affairs when you
didn't actively participate in the lead up to it and, by your own
admission, really just want tools to "abuse" existing libraries
without putting effort into migration. It's fine that you want this,
but don't expect anyone else to put in effort where you're not
prepared.

If you believe providing a complementary __past__ namespace will work
- even though I believe Guido has explicitly stated it will never
happen - then the onus is on you to come up with an implementation.

[rantingri...@gmail.com]

On Monday, June 25, 2012 10:35:14 PM UTC-5, Steven D&#39;Aprano wrote:
> (Rick, don't make me regret communicating with you again.)

Well unfortunately Steven i am not sure what causes you to stop communicating with me for these seeming random periods of time -- although i can deduce from past experiences that you have difficulty accepting diverse opinions, then, your emotions take control causing you to wield the only weapon of recourse you have available to you: the kill file -- so in that sense, i cannot provide a solution for a problem that exists beyond my control. HTH.

> On Mon, 25 Jun 2012 19:28:01 -0700, rantingrickjohnson wrote:
> There's no real difference between typing print(...) and all the other
> functions in Python. Do you lament having to type len(obj) instead of
> "len obj" or list(zip(a, b, c)) instead of "list zip a b c"?

No. I actually like the forced parenthesis -- even when on a function declaration with no arguments. I think this is a consistent approach. And boy do i love consistency!

> Making print a statement in the first place was a mistake, but
> fortunately it was a simple enough mistake to rectify once the need for
> backward compatibility was relaxed.

Agreed. However, my comment was not a rant against the new print function, more that, it is a warning against pushing people to learn Python 2.x FIRST, and therby "training" them with the bad habit of using a "naked print syntax" that they will surely lament in the future.

For me the print statement is like a big old delicious chocolate chip cookie and the print function is like a plate of leafy vegetables. I know i should eat my vegetables; but that damn cookie is just too tempting!

[rantingri...@gmail.com]

On Tuesday, June 26, 2012 1:24:43 AM UTC-5, Stefan Behnel wrote:

> Maybe we should add a remote error reporting mode to Python that sends all
> syntax error messages not only to the local screen but also directly to the
> PSF so that they can fund developers who are able to delete that error
> message from the interpreter based on real world statistical evidence. That
> would eventually make the language match the powerset of what all users
> have in their fingers. A very worthy goal, if you ask me.

I'm sure you meant this a joke, however, some feedback like this would be greatly beneficial to the developers and community. It's not something you'd want to send each time an exception is thrown, but a log could be requested for delivery from time to time. I think it would be a great addition to any python editor; especially those geared toward neophytes: like IDLE and such.

[rantingri...@gmail.com]

On Tuesday, June 26, 2012 1:24:43 AM UTC-5, Stefan Behnel wrote:

> Maybe we should add a remote error reporting mode to Python that sends all
> syntax error messages not only to the local screen but also directly to the
> PSF so that they can fund developers who are able to delete that error
> message from the interpreter based on real world statistical evidence. That
> would eventually make the language match the powerset of what all users
> have in their fingers. A very worthy goal, if you ask me.

[rantingri...@gmail.com]

On Tuesday, June 26, 2012 1:34:03 AM UTC-5, Stefan Behnel wrote:
> First of all, the statement has a rather special syntax that is not obvious
> and practically non-extensible. It also has hidden semantics that are hard
> to explain and mixes formatting with output - soft-space, anyone?
>
> The function is straight forward, configurable, does one thing, works with
> help() and doesn't get in the way. And something as rarely[1] used as a
> print simply doesn't deserve special syntax. Oh, and, yes, you can even
> pass it into some code as callback, although I rarely had a need for that.
>
> Stefan
>
>
> [1] Seriously, it's not very helpful in interactive mode and too simplistic
> to be used in application code. Even scripts often work better with logging
> than with prints.

Unfortunately, even though "print" is supposedly only used by the neophytes, the python<3.0 stdlib is full of print statements. For instance, out of 3173 files, 986 contained the word "print"[1]. Heck just in the Lib folder alone (without recusing down sub directories) there are 1352 instances of "print" in a "py" file!

Naive Nancy Mused: "If only neophtes use print, and the Python Lib is full of prints statements, then the python developers must be...OH DEAR GAWD!"

[1] of course that is when using `filestr.count("print")` -- I assume that the word "print" is not used excessively in comments or docstrings. Someone else can do a less naive search if they like.

[rantingri...@gmail.com]

On Tuesday, June 26, 2012 1:34:03 AM UTC-5, Stefan Behnel wrote:

> First of all, the statement has a rather special syntax that is not obvious
> and practically non-extensible. It also has hidden semantics that are hard
> to explain and mixes formatting with output - soft-space, anyone?
>
> The function is straight forward, configurable, does one thing, works with
> help() and doesn't get in the way. And something as rarely[1] used as a
> print simply doesn't deserve special syntax. Oh, and, yes, you can even
> pass it into some code as callback, although I rarely had a need for that.
>
> Stefan
>
>
> [1] Seriously, it's not very helpful in interactive mode and too simplistic
> to be used in application code. Even scripts often work better with logging
> than with prints.

[alex23]

Rick, fix your mail reader/sender, your lines aren't wrapping
properly.

On Jun 28, 1:53 pm, rantingrickjohn...@gmail.com wrote:
> Unfortunately, even though "print" is supposedly only used by the neophytes, the python<3.0 stdlib is full of print statements. For instance, out of 3173 files, 986 contained the word "print"[1]. Heck just in the Lib folder alone (without recusing down sub directories) there are 1352 instances of "print" in a "py" file!

Stefan said "rarely used". Until you count all keywords & built-ins in
those files and provide a relative basis of comparison, you're not
saying anything here.

> Naive Nancy Mused: "If only neophtes use print, and the Python Lib is full of prints statements, then the python developers must be...OH DEAR GAWD!"

It's a good thing there's no open flame around given the sheer number
of strawmen you stuff into your posts.

No one made any such claim about "neophytes", just that logging can be
better than print() as a general debugging tool.

> [1] of course that is when using `filestr.count("print")` -- I assume that the word "print" is not used excessively in comments or docstrings. Someone else can do a less naive search if they like.

So you couldn't even be bothered to do it right, but you're happy to
form a noisy opinion on this crap, and now the onus is on someone else
to correct the ignorance you've pushed onto this list. Again.

[Steven D'Aprano]

On Wed, 27 Jun 2012 17:44:23 -0700, alex23 wrote:

> If you believe providing a complementary __past__ namespace will work -
> even though I believe Guido has explicitly stated it will never happen -
> then the onus is on you to come up with an implementation.

Guido speaks only for CPython. Other implementations can always do
differently.

The Python 3 naysayers are welcome to fork Python 2.7 and support it
forever, with or without a __past__ namespace. That's the power of open
source software.

And who knows, if it becomes popular enough, perhaps it will be ported to
CPython too.



--
Steven

[Serhiy Storchaka]

On 28.06.12 00:14, Terry Reedy wrote:
> Another prediction: people who code Python without reading the manual,
> at least not for new features, will learn about 'u' somehow (such as by
> reading this list) and may do either of the following, both of which are
> bad.
>
> 1. They will confuse themselves by thinking that 'u' actually means
> somethings. They may then confuse others by writing about its supposed
> meaning. This might get amusing.
>
> 2. They will use 'u' in Python 3 only code, thereby making it
> incompatible with 3.2-, even if it otherwise would not be.
>
> These two actions will reinforce each other.

Yes, this is what I mean. I can even make a prediction: in just 5 years,
as this feature would be banned in a decent society. The authors of the
books will be strongly advise not to use it, and in software companies
'u' will be prohibited in coding style. But get rid of this will be
difficult.

[Stefan Behnel]

Serhiy Storchaka, 28.06.2012 07:36:

Once Py2.7 is out of maintenance, we can deprecate that feature in one
release and start warning about it in the next one. You're then free to use
the corresponding 2to3 fixer to get it back out of your code with a single
patch.

Stefan

[wxjm...@gmail.com]

On the other side, one can argue this (elegancy):

b'a serie of bytes'
u'a unicode, a serie of code points'

'python2? str? python3? encoded _unicode?'

jmf

[wxjm...@gmail.com]

On Thursday, June 28, 2012 7:47:24 AM UTC+2, Stefan Behnel wrote:

[Chris Angelico]

On Thu, Jun 28, 2012 at 7:34 PM, <wxjm...@gmail.com> wrote:
> On the other side, one can argue this (elegancy):
>

> b'a series of bytes'
> u'a unicode, a series of code points'

Alas, not perfectly so. A 'bytes' object and a 'unicode' object can be
described that way (with 'str' an alias for one or t'other), but
literal strings are never that simple. (Backslash escapes, delimiters,
newlines, etc, etc, etc.) However, it is a nice idea, to the extent
that it's possible.

ChrisA