Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #24425 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why has python3 been created as a seperate language where there is still python2.7 ? Michiel Overtoom <motoom@xs4all.nl> - 2012-06-25 12:10 +0200
    Re: Why has python3 been created as a seperate language where there is still python2.7 ? rantingrickjohnson@gmail.com - 2012-06-25 19:28 -0700
      Re: Why has python3 been created as a seperate language where there is still python2.7 ? Jeremiah Dodds <jeremiah.dodds@gmail.com> - 2012-06-26 01:04 -0400
      Re: Why has python3 been created as a seperate language where there is still python2.7 ? Stefan Behnel <stefan_ml@behnel.de> - 2012-06-26 08:24 +0200
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? rantingrickjohnson@gmail.com - 2012-06-27 20:32 -0700
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? rantingrickjohnson@gmail.com - 2012-06-27 20:32 -0700
    Re: Why has python3 been created as a seperate language where there is still python2.7 ? rantingrickjohnson@gmail.com - 2012-06-25 19:28 -0700
      Re: Why has python3 been created as a seperate language where there is still python2.7 ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-26 03:35 +0000
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Terry Reedy <tjreedy@udel.edu> - 2012-06-26 00:33 -0400
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-06-26 02:15 -0400
          Re: Why has python3 been created as a seperate language where there is still python2.7 ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-26 07:40 +0000
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Stefan Behnel <stefan_ml@behnel.de> - 2012-06-26 08:34 +0200
          Re: Why has python3 been created as a seperate language where there is still python2.7 ? rantingrickjohnson@gmail.com - 2012-06-27 20:53 -0700
            Re: Why has python3 been created as a seperate language where there is still python2.7 ? alex23 <wuwei23@gmail.com> - 2012-06-27 21:05 -0700
          Re: Why has python3 been created as a seperate language where there is still python2.7 ? rantingrickjohnson@gmail.com - 2012-06-27 20:53 -0700
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Christian Tismer <tismer@stackless.com> - 2012-06-27 12:25 +0200
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Chris Angelico <rosuav@gmail.com> - 2012-06-27 21:02 +1000
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Stefan Behnel <stefan_ml@behnel.de> - 2012-06-27 13:22 +0200
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-06-27 07:24 -0400
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Chris Angelico <rosuav@gmail.com> - 2012-06-27 22:05 +1000
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Christian Tismer <tismer@stackless.com> - 2012-06-27 15:15 +0200
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Stefan Behnel <stefan_ml@behnel.de> - 2012-06-27 15:44 +0200
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Chris Angelico <rosuav@gmail.com> - 2012-06-27 23:44 +1000
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Christian Tismer <tismer@stackless.com> - 2012-06-27 16:34 +0200
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Serhiy Storchaka <storchaka@gmail.com> - 2012-06-27 21:58 +0300
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Serhiy Storchaka <storchaka@gmail.com> - 2012-06-27 22:08 +0300
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Terry Reedy <tjreedy@udel.edu> - 2012-06-27 17:14 -0400
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Christian Tismer <tismer@stackless.com> - 2012-06-28 00:11 +0200
          Re: Why has python3 been created as a seperate language where there is still python2.7 ? alex23 <wuwei23@gmail.com> - 2012-06-27 17:44 -0700
            Re: Why has python3 been created as a seperate language where there is still python2.7 ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-28 04:32 +0000
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? rantingrickjohnson@gmail.com - 2012-06-27 20:25 -0700
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Serhiy Storchaka <storchaka@gmail.com> - 2012-06-28 08:36 +0300
        Re: Why has python3 been created as a seperate language where there is still python2.7 ? Stefan Behnel <stefan_ml@behnel.de> - 2012-06-28 07:47 +0200
          Re: Why has python3 been created as a seperate language where there is still python2.7 ? wxjmfauth@gmail.com - 2012-06-28 02:34 -0700
          Re: Why has python3 been created as a seperate language where there is still python2.7 ? wxjmfauth@gmail.com - 2012-06-28 02:34 -0700
            Re: Why has python3 been created as a seperate language where there is still python2.7 ? Chris Angelico <rosuav@gmail.com> - 2012-06-28 20:14 +1000
      Re: Why has python3 been created as a seperate language where there is still python2.7 ? Roy Smith <roy@panix.com> - 2012-06-27 07:45 -0400

Page 2 of 2 — ← Prev page 1 [2]

#24510

On 27.06.12 13:02, Chris Angelico wrote:
> On Wed, Jun 27, 2012 at 8:25 PM, Christian Tismer <tismer@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

-- 
Christian Tismer             :^)   <mailto:tismer@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/

[toc] | [prev] | [next] | [standalone]

#24514

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

[toc] | [prev] | [next] | [standalone]

#24515

On Wed, Jun 27, 2012 at 11:15 PM, Christian Tismer <tismer@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

[toc] | [prev] | [next] | [standalone]

#24517

On 27.06.12 15:44, Stefan Behnel wrote:
> 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.
>
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

-- 
Christian Tismer             :^)   <mailto:tismer@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/

[toc] | [prev] | [next] | [standalone]

#24531

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

Excessive flexibility is amorphism.

[toc] | [prev] | [next] | [standalone]

#24533

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.

[toc] | [prev] | [next] | [standalone]

#24542

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

[toc] | [prev] | [next] | [standalone]

#24550

On 6/27/12 8:58 PM, Serhiy Storchaka wrote:
> On 27.06.12 17:34, Christian Tismer wrote:
>> That's why I was unhappy with py3's missing flexibility.
>
> Excessive flexibility is amorphism.
>

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

-- 
Christian Tismer             :^)   <mailto:tismer@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/

[toc] | [prev] | [next] | [standalone]

#24570

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.

[toc] | [prev] | [next] | [standalone]

#24588

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

[toc] | [prev] | [next] | [standalone]

#24578

On Monday, June 25, 2012 10:35:14 PM UTC-5, Steven D'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!

[toc] | [prev] | [next] | [standalone]

#24590

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.

[toc] | [prev] | [next] | [standalone]

#24591

Serhiy Storchaka, 28.06.2012 07:36:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#24599

On Thursday, June 28, 2012 7:47:24 AM UTC+2, Stefan Behnel wrote:
> Serhiy Storchaka, 28.06.2012 07:36:
> > 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.
> 
> 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

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

[toc] | [prev] | [next] | [standalone]

#24600

On Thursday, June 28, 2012 7:47:24 AM UTC+2, Stefan Behnel wrote:
> Serhiy Storchaka, 28.06.2012 07:36:
> > 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.
> 
> 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

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

[toc] | [prev] | [next] | [standalone]

#24601

On Thu, Jun 28, 2012 at 7:34 PM,  <wxjmfauth@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

[toc] | [prev] | [next] | [standalone]

#24503

In article <mailman.1503.1340677684.4697.python-list@python.org>,
 rantingrickjohnson@gmail.com wrote:

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

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web