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 1 of 2  [1] 2  Next page →

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

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.

[toc] | [next] | [standalone]

#24453

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

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

#24457

rantingrickjohnson@gmail.com writes:

> 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

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

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

#24459

Jeremiah Dodds, 26.06.2012 07:04:
> rantingrickjohnson@gmail.com writes:
> 
>> 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
> 
> 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

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

#24580

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.

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

#24582

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.

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

#24454

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

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

#24455

(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

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

#24456

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

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

#24458

On Mon, Jun 25, 2012 at 11:35 PM, Steven D'Aprano
<steve+comp.lang.python@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

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

#24463

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

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

#24460

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.

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

#24583

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.

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

#24585

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.

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

#24584

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.

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

#24499

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

#24500

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.

ChrisA

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

#24501

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

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

#24502

On Wed, Jun 27, 2012 at 7:02 AM, Chris Angelico <rosuav@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

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

#24504

On Wed, Jun 27, 2012 at 9:24 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> On Wed, Jun 27, 2012 at 7:02 AM, Chris Angelico <rosuav@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.

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web