python 3's adoption

[Xah Lee]

Some thoughts about Python 3 Adoption.

Xah Lee, 2010-01-26

Some notes of Wikipedia readings related to Python.

Unladen Swallow, a new project from Google. It is a new python
compiler with the goal of 5 times faster than the de facto standand
implementation CPython. Also note Stackless Python, which is already
been used in some major commercial projects.

Was looking into what's new in Python 3. See: http://docs.python.org/dev/3.0/whatsnew/3.0.html.
From a quick reading, i don't really like it. Here's some highlights:

* Print is now a function. Great, much improvement.
* Many functions that return lists now returns “Views†or
“Iterators†Instead. A fucking **** all fucked up shit. A extraneous
“oop engineering†complication. (See: Lambda in Python 3000)
* The cmp() function used in sort is basically gone, users are now
supposed to use the “key†parameter instead. This is a flying-face-
**** to computer science. This would be the most serious fuckup in
python 3. (See: Sorting in Python and Perl)
* Integers by default is long. Great!
* Much more integrated unicode support, rewrite of most its text
or string semantics. Fantastic. Finally.

Am looking because i wonder if i should switch to python 3 for my own
few scripts, and rewrite my Python Tutorial for version 3. Am also
interested to know how python 3 is received by the computing industry.
Apparantly, a little search on the web indicates that vast majority of
python base have not switched, as expected, for many good reasons.
Vast majority of major python modules and tools have not switched.
Most linux distro have not switched, i don't find any large
corporation having adopted Python 3 (Google, Yahoo, Facebook,
NASA,... ). (sources: Source, Source) Basically, such a incompatible
change with trivial, ideological improvements, is too costy to switch.

I wonder, if by 2015, will most large corporate users have switched to
python 3. I give it a maybe. In today's Proliferation of Computing
Languages, such a major antic by Guido can just hurt itself. What is
he thinking? He of course thought himself as a god of lang designer,
who sincerely wants to push towards perfection, all future-looking.
Unfortunately, the tens of other major language designers all think
similarly.

perm archive of this post with possible updates here:
http://xahlee.org/comp/python3.html

Any comment on this?

Xah
∑ http://xahlee.org/

☄

 

[Alf P. Steinbach]

I'm responding to the original message by Xah Lee, which is not carried by my
Usenet provider.

* Alan Harris-Reid:
Actually not, IMHO. All it does is is to provide incompatibility. They forgot
Ronald Reagan's old maxim: if it don't need fixin', don't fix it.


On the contrary, this is a great improvement. It makes no sense to have to write
more code and less readable code for the common efficient case. And the default,
the way that takes 0.5 seconds less to do, does have a great influence on what
people choose, even in elections (Obama's latest "opt out" proposal is an
example that this principle is recognized even by the President of the United
States). When you want an explicit collection such as a 'list', introducing some
overhead for presumably a good reason, it's as easy as e.g. 'list(range(42))'.


I agree.

Probably there must have been some rationale, but to put it bluntly removing the
comparator is more like moronic than pythonic. If the rationale was efficiency,
then a rational solution could be to provide two sort methods, like 'sort' using
direct comparisions and 'custom_sort' using a specified comparator. Come to
think of it, that door is still open, except for the language spec freeze.

It's possible to work around the removal of 'cmp' in various kludgy ways, but
you shouldn't have to "work around" a library sort routine.


Yes, totally agree.

Nothing confuses the newbie or the now-and-then programmer so much as limited
range integers.

Well, perhaps floating point, but...


I'm not sure if the Unicode support is fantastic. I have the impression that
there are still some edges to iron out and corners to smooth, + bugs to kill.
But it's Very Good.


[snip]

Cheers,

- Alf

 

[Grant Edwards]

I'm responding to the original message by Xah Lee, which is
not carried by my Usenet provider.

A Usenet provider that doesn't carry messages from Xah Lee.

So... many... jokes.....

 

[alex23]

Actually not, IMHO. All it does is is to provide incompatibility. They forgot
Ronald Reagan's old maxim: if it don't need fixin', don't fix it. [...]
Probably there must have been some rationale, but to put it bluntly removing the
comparator is more like moronic than pythonic.

So in both cases, you haven't put any effort into researching why
these decisions were made, but you're happy to jump to conclusions
about the intelligence of the implementer(s) while regularly trotting
out complaints of ad hominem attacks against yourself.

The saddest part of all is you seem to consider yourself some kind of
educator.

 

[Alf P. Steinbach]

* alex23:

Actually not, IMHO. All it does is is to provide incompatibility. They forgot
Ronald Reagan's old maxim: if it don't need fixin', don't fix it. [...]
Probably there must have been some rationale, but to put it bluntly removing the
comparator is more like moronic than pythonic.

So in both cases, you haven't put any effort into researching why
these decisions were made, but you're happy to jump to conclusions
about the intelligence of the implementer(s) while regularly trotting
out complaints of ad hominem attacks against yourself.

The saddest part of all is you seem to consider yourself some kind of
educator.

Hi "alex23".

Ad hominem attacks like you try above, just reflect on the one doing it.

Adding in some obviously false assertions just makes you look even worse.

And posting anonymously, well, that article's got it all.

Such attacks constitute noise and, except for how they reflect on you, only noise.


Cheers & hth.,

- Alf

 

[Steve Holden]

[Off-list]

Actually not, IMHO. All it does is is to provide incompatibility. They forgot
Ronald Reagan's old maxim: if it don't need fixin', don't fix it. [...]
Probably there must have been some rationale, but to put it bluntly removing the
comparator is more like moronic than pythonic.

So in both cases, you haven't put any effort into researching why
these decisions were made, but you're happy to jump to conclusions
about the intelligence of the implementer(s) while regularly trotting
out complaints of ad hominem attacks against yourself.

The saddest part of all is you seem to consider yourself some kind of
educator.

<snort/> ;-)

regards
Steve

 

[Alf P. Steinbach]

* Steve Holden:

[Off-list]

Actually not, IMHO. All it does is is to provide incompatibility. They forgot
Ronald Reagan's old maxim: if it don't need fixin', don't fix it. [...]
Probably there must have been some rationale, but to put it bluntly removing the
comparator is more like moronic than pythonic.

So in both cases, you haven't put any effort into researching why
these decisions were made, but you're happy to jump to conclusions
about the intelligence of the implementer(s) while regularly trotting
out complaints of ad hominem attacks against yourself.

The saddest part of all is you seem to consider yourself some kind of
educator.

<snort/> ;-)

Please don't post more noise and ad hominem attacks to the group, Steve.


- Alf

 

[John Bokma]

Please don't post more noise and ad hominem attacks to the group,
Steve.

Funny that you talk about noise while replying yourself to noise. Xah
Lee is just a pathetic spammer. He's not going to reply in this
thread. He just shits out his stuff in as many groups as possible to
promote his website.

 

[Alf P. Steinbach]

* John Bokma:

Funny that you talk about noise while replying yourself to noise. Xah
Lee is just a pathetic spammer. He's not going to reply in this
thread. He just shits out his stuff in as many groups as possible to
promote his website.

Sorry, I didn't know.

Thanks for the heads-up.


Cheers,

- Alf

 

[John Bokma]

* John Bokma:

Sorry, I didn't know.

Thanks for the heads-up.

My apologies for the harsh tone of my reply. I am more than tired of how
Xah Lee spams weekly, and shouldn't have assumed you were aware of that.

 

[Terry Reedy]

Some thoughts about Python 3 Adoption.

Xah Lee, 2010-01-26

Some notes of Wikipedia readings related to Python.

Unladen Swallow, a new project from Google. It is a new python
compiler with the goal of 5 times faster than the de facto standand
implementation CPython. Also note Stackless Python, which is already
been used in some major commercial projects.

Was looking into what's new in Python 3. See: http://docs.python.org/dev/3.0/whatsnew/3.0.html.
From a quick reading, i don't really like it. Here's some highlights:

* Print is now a function. Great, much improvement.

Something we agree on. For simple scripts, it is a bit of a nuisance,
but it eliminates kludgy special-case syntax for options, which are now
normal keyword arguments.

* Many functions that return lists now returns “Views†or
“Iterators†Instead. A fucking **** all fucked up shit. A extraneous
“oop engineering†complication. (See: Lambda in Python 3000)

Something we disagree on. I consider the shift from list or iterator
orientation a major advance. If you ever want to iterate a 10 million
item dict or map or filter a 100 million item sequence, you might then
see the point.

* The cmp() function used in sort is basically gone, users are now
supposed to use the “key†parameter instead. This is a flying-face-
**** to computer science. This would be the most serious fuckup in
python 3. (See: Sorting in Python and Perl)

It is completely gone. Cmp was kludgy. Sort paid no attention to the
tri-state return but only paid attention to the less-than branch. Which
means a) that it was redundant with the less than method and that the
effort to split == from > was completely wasted. It is difficult to find
use cases where cmp= is superior to key=

* Integers by default is long. Great!
* Much more integrated unicode support, rewrite of most its text
or string semantics. Fantastic. Finally.

What is missing now on Windows is better support from the OS, at least
with XP. I have not tried 3.1 on Win7 yet (and never touched Vista).

Am looking because i wonder if i should switch to python 3 for my own
few scripts, and rewrite my Python Tutorial for version 3.

I am writing my book on algorithms using 3.1 because of the above and
other improvements (consistent / and elimination of old classes, for
instance).

> Am also
interested to know how python 3 is received by the computing industry.
Apparantly, a little search on the web indicates that vast majority of
python base have not switched,

Some people have panicked prematurely.

Guido never expected that working old apps would all be switched. There
is probably code still being run with 1.5 from 15 years ago. And there
will be 2.7 code running at least that far in the future.

Even before 3.0 was out, he also never expected major uptake until 3.2,
which is a year away. 3.0 was, well, a .0 release with a couple of .0
problems. 3.1 is pretty solid and modules are appearing for it.

as expected, for many good reasons.
Vast majority of major python modules and tools have not switched.

A few have, more will in the next year or after 3.2 is released, some
never will. The most important one, in my opinion, is numpy, since some
module authors who *want* to do a 3.x version are waiting on that.

Most linux distro have not switched,

Have any switched to 2.6 yet, as the default? Some do have 3.1 version
available.

> i don't find any large
corporation having adopted Python 3 (Google, Yahoo, Facebook,
NASA,... ). (sources: Source, Source) Basically, such a incompatible
change with trivial, ideological improvements, is too costy to switch.

The major reduction of redundancy by the overdue removal of obsolete
features makes it a much nicer language to learn than, say, 2.6. It is
much closer to the simplicity of 1.4, which is what I started with.

Terry Jan Reedy

 

[Steven D'Aprano]

Actually not, IMHO. All it does is is to provide incompatibility. They
forgot Ronald Reagan's old maxim: if it don't need fixin', don't fix it.

print as a function is more consistent and more convenient than print as
a statement. Or to put it another way, print as a statement is less
consistent and convenient, and therefore in need of fixing. By Ronald
Reagan's aphorism, it should be fixed, and now does.

Of course there's a bit of a learning curve for those used to the old
ways, but in two years from now, I expect no-one will remember what the
fuss was about. Python 2.6 users will start their script with "from
__future__ import print_function", Python 2.7 users may not even need to
do that, and we'll all pity those stuck with 2.5 or 2.4.

On the contrary, this is a great improvement.
Agreed.



I agree.

I did too, when I first heard cmp was to be dumped. But I changed my mind
and now agree with the decision to drop cmp. Custom sorts are nearly
always much better written with key rather than cmp: key adds an O(N)
overheard to the sorting, while cmp makes sorting O(N**2). In other
words, key is *much* faster, and generally easier to write as well.

There may be a handful of rare applications where there is no obvious way
to convert a cmp function to a key, but they are vanishingly rare. I
think, if you search the archives, Paul Rubin may have come up with one
example. There are a number of recipes for easily converting cmp sorts to
key sorts.

I think, in my perfect world, list.sort() and sorted() should continue
being key based, while the standard library contained (perhaps in the
functools module?) a sort function that contains all the bells and
whistles. You want cmp, it's there, and you can pay the extra cost if you
need it. You want to sort multiple lists by the contents of one? One
import away. But keep the general sort() function lean and super-fast.

 

[Paul Rubin]

print as a function is more consistent and more convenient than print as
a statement.

Convenience is subjective, but the 3.x 'print' behavior is definitely
inconsistent (i.e. different from 2.x). The change makes a lot of my
code silently produce wrong results, too. I often print tuples to show
what a program is doing:

print (timestamp, 'transmogrified', blob)

which in 2.x prints a parenthesized tuple that I can later read back in
with eval. That line of code still prints a message, but in a different
format, instead of throwing an error.

 

[Steven D'Aprano]

Convenience is subjective, but the 3.x 'print' behavior is definitely
inconsistent (i.e. different from 2.x).

Sorry, I meant consistent with the rest of Python, which mostly uses
functions/methods and only rarely statements (e.g. del and import).

The change makes a lot of my
code silently produce wrong results, too. I often print tuples to show
what a program is doing:

print (timestamp, 'transmogrified', blob)

which in 2.x prints a parenthesized tuple that I can later read back in
with eval. That line of code still prints a message, but in a different
format, instead of throwing an error.

I don't pretend that the transition between statement and function syntax
will be anything but inconvenient, but I believe the end result will be
worth it.

 

[Paul Rubin]

Sorry, I meant consistent with the rest of Python, which mostly uses
functions/methods and only rarely statements (e.g. del and import).

yield, assert, if/else, return, etc. If we're after that kind of
consistency, why not get rid of all those statements too? They have
already partly done it with yield, and they ended up introducing a new
separate if/else expression syntax as an alternative to the statement.

I don't pretend that the transition between statement and function syntax
will be anything but inconvenient, but I believe the end result will be
worth it.

This just seems like a gratuitous change with very little benefit.
Changing a bunch of list functions to instead return iterators is
a much deeper change that will cause larger amounts of breakage, but
it has quite a lot of benefits, so there's a stronger case for it.

 

[Steven D'Aprano]

yield, assert, if/else, return, etc. If we're after that kind of
consistency, why not get rid of all those statements too? They have
already partly done it with yield, and they ended up introducing a new
separate if/else expression syntax as an alternative to the statement.

Without becoming a purely functional language, you won't get rid of all
statements. In my opinion, outside of such purely functional languages
and unconventional languages like Forth, statements play a valuable role
in that they are controlling syntax. For example:

for, while, if, try, break, yield, return

are all used for flow control, and should remain as statements. But print
is not -- it's a function disguised as a statement. print, after all, is
just sugar for stdout.write, which is fine as far as it goes, but when
you want to do something slightly different from what the sugar does, it
becomes terribly inconvenient.

A consequence of print being a statement is that my modules are often
filled with functions and methods called "print_". Suppose I want to
print the type of each argument as well as it's value. I would like to do
this:


def decorator(pr):
def inner(*args, **kwargs):
args = [(type(a), a) for a in args]
pr(*args, **kwargs)
return inner

print = decorator(print)


and then use print as normal, but of course I can't. So instead I do
something like this:


def print_(*args, **kwargs):
args = [(type(a), a) for a in args]
kw = {'file': sys.stdout, 'sep': ' ', 'end': '\n'}
kw.update(kwargs)
if len(kw) != 3:
raise TypeError('invalid keyword argument')
file = kw['file']
sep = kw['sep']
end = kw['end']
for arg in args:
print >>file, (str(arg) + sep), # Don't forget the comma.
print >>file, end, # Another comma.


And then, I have to remember to call print_ instead of print.

 

[Paul Rubin]

Without becoming a purely functional language, you won't get rid of all
statements.

Why not? GCC lets you use any statement in an expression:

#include <stdio.h>

main()
{
int i, x, p=0;
x = ({ for (i=1; i<=10; i++) p += i; p;});
printf ("x=%d\n", x);
}

and C is certainly not a purely functional language.

for, while, if, try, break, yield, return
are all used for flow control, and should remain as statements.

What about assert, import, and pass?

 

[Daniel Fetchinson]

* Print is now a function. Great, much improvement.

Actually not, IMHO. All it does is is to provide incompatibility.

What incompatibility are you exactly talking about?

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?

Cheers,
Daniel

 

[Steve Holden]

Why not? GCC lets you use any statement in an expression:

#include <stdio.h>

main()
{
int i, x, p=0;
x = ({ for (i=1; i<=10; i++) p += i; p;});
printf ("x=%d\n", x);
}

and C is certainly not a purely functional language.


What about assert, import, and pass?

Remember that Guido stated (I think in the original FAQ entry for why
assignments don't produce results, but I could be wrong) that he
explicitly wanted Python to be a statement-based language.

regards
Steve

 

[Xah Lee]

Someone is badmouthing me, and it has been doing so over the years. I
feel obliged to post a off topic relpy. See:

• DreamHost.com and A Incidence of Harassment
http://xahlee.org/Periodic_dosage_dir/t2/harassment.html

• Why Can't You Be Normal?
http://xahlee.org/Netiquette_dir/why_cant_you_be_normal.html

Xah