Article on the future of Python

S

Steven D'Aprano

On Thu, Sep 27, 2012 at 10:44 AM, Steven D'Aprano


That's all very well, but unless I have my facts badly wrong, PyPy is
only compatible with Python 2 - right?

At the moment, yes. Support for Python 3 is in active development.

http://morepypy.blogspot.com/2012/09/py3k-status-update-6.html


[...]
Assuming it manages to catch up with Py3, which a decade makes entirely
possible, this I can well believe. And while we're sounding all hopeful,
maybe Python will be on popularity par with every other P in the classic
LAMP stack. *That* would be a Good Thing.

Given how Perl has slipped in the last decade or so, that would be a step
backwards for Python :p
 
C

Chris Angelico

Given how Perl has slipped in the last decade or so, that would be a step
backwards for Python :p

LAMP usually means PHP these days. There's a lot of that around.

ChrisA
 
S

Steven D'Aprano

Sorry guys, I'm "only" able to see this (with the Python versions an end
user can download):

[snip timeit results]

While you have been all doom and gloom and negativity that Python has
"destroyed" Unicode, I've actually done some testing. It seems that,
possibly, there is a performance regression in the "replace" method.

This is on Debian squeeze, using the latest rc version of 3.3, 3.3.0rc3:

py> timeit.repeat("('b'*1000).replace('b', 'a')")
[28.308280900120735, 29.012173799797893, 28.834429003298283]

Notice that Unicode doesn't come into it, they are pure ASCII strings.
Here's the same thing using 3.2.2:

py> timeit.repeat("('b'*1000).replace('b', 'a')")
[3.4444618225097656, 3.147739887237549, 3.132185935974121]

That's a factor of 9 slowdown in 3.3, and no Unicode. Obviously Python
has "destroyed ASCII".

(I get similar slowdowns for Unicode strings too, so clearly Python hates
all strings, not just ASCII.)

Now, for irrelevant reasons, here I swapped to Centos.

[steve@ando ~]$ python2.7 -m timeit "'b'*1000"
1000000 loops, best of 3: 0.48 usec per loop
[steve@ando ~]$ python3.2 -m timeit "'b'*1000"
1000000 loops, best of 3: 1.3 usec per loop
[steve@ando ~]$ python3.3 -m timeit "'b'*1000"
1000000 loops, best of 3: 0.397 usec per loop

Clearly 3.3 is the fastest at string multiplication, at least for this
trivial example. Just to prove that the result also applies to Unicode:

[steve@ando ~]$ python3.3 -m timeit "('ä½ '*1000)"
1000000 loops, best of 3: 1.38 usec per loop

Almost identical to 3.2. And the reason it is slower than the 3.3 test
using 'b' above is almost certainly because the string uses four times
more memory:

[steve@ando ~]$ python3.3 -m timeit "('abcd'*1000)"
1000000 loops, best of 3: 0.919 usec per loop

So a little slower that the pure-ASCII version for the same amount of
memory, but not significantly so.

But add a call to replace, and things are very different:

[steve@ando ~]$ python2.7 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 9.3 usec per loop
[steve@ando ~]$ python3.2 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 5.43 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 18.3 usec per loop


Three times slower, even for pure-ASCII strings. I get comparable results
for Unicode. Notice how slow Python 2.7 is:

[steve@ando ~]$ python2.7 -m timeit -s "s = u'ä½ '*1000" "s.replace(u'ä½ ', u'a')"
10000 loops, best of 3: 65.6 usec per loop
[steve@ando ~]$ python3.2 -m timeit -s "s = 'ä½ '*1000" "s.replace('ä½ ', 'a')"
100000 loops, best of 3: 2.79 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s "s = 'ä½ '*1000" "s.replace('ä½ ', 'a')"
10000 loops, best of 3: 23.7 usec per loop

Even with the performance regression, it is still over twice as fast as
Python 2.7.

Nevertheless, I think there is something here. The consequences are nowhere
near as dramatic as jmf claims, but it does seem that replace() has taken a
serious performance hit. Perhaps it is unavoidable, but perhaps not.

If anyone else can confirm similar results, I think this should be raised as
a performance regression.
 
A

Alex Strickland

Hi
Sorry guys, I'm "only" able to see this (with the Python versions an end
user can download):

[snip timeit results]

While you have been all doom and gloom and negativity that Python has
"destroyed" Unicode,

I thought that jmf's concerns were solely concerned with the selection
of latin1 as the 1 byte set. My impression was that if some set of
characters was chosen that included all characters commonly used in
French then all would be well with the world.

But now I'm confused because latin1 seems to cater for French quite well:

http://en.wikipedia.org/wiki/ISO/IEC_8859-1
 
S

Serhiy Storchaka

Nevertheless, I think there is something here. The consequences are nowhere
near as dramatic as jmf claims, but it does seem that replace() has taken a
serious performance hit. Perhaps it is unavoidable, but perhaps not.

If anyone else can confirm similar results, I think this should be raised as
a performance regression.

Yes, I confirm, it's a performance regression. It should be avoidable.
Almost any PEP393 performance regression can be avoided. At least for
such corner case. Just no one has yet optimized this case.
 
G

Grant Edwards

LAMP usually means PHP these days. There's a lot of that around.

Yea, unfortunately. What a mess of a language. I recently had to
learn enough PHP to make some changes to a web site we had done by an
outside contractor. PHP feels like it was designed by taking a
half-dozen other languages, chopping them into bits and then pulling
random features/syntax/semantics at random from the various different
piles. Those bits where then stuck together with duct tape and bubble
gum and called PHP...

As one of the contractors who wrote some of the PHP said: "PHP is like
the worst parts of shell, Perl, and Java all combined into one
language!"
 
S

Steven D'Aprano

Summary of that article:

"Sure, you have all these legitimate concerns, but look, cake!"

Did you read the article or just make up a witty response? If so, you
half succeeded.

It's more like, "Well, maybe, your concerns *might* be legitimate, but I
don't think so because..." and then he gives half a dozen or more reasons
why Python is in no danger. None of which involve cake, although one of
them did involve Raspberry Pi. An easy mistake to make.
 
C

Chris Angelico

Yea, unfortunately. What a mess of a language. I recently had to
learn enough PHP to make some changes to a web site we had done by an
outside contractor. PHP feels like it was designed by taking a
half-dozen other languages, chopping them into bits and then pulling
random features/syntax/semantics at random from the various different
piles. Those bits where then stuck together with duct tape and bubble
gum and called PHP...

As one of the contractors who wrote some of the PHP said: "PHP is like
the worst parts of shell, Perl, and Java all combined into one
language!"

I can't remember where I read it, and I definitely don't know if it's
accurate to current thinking, but the other day I found a quote
purporting to be from the creator of PHP saying that he didn't care
about memory leaks, just restart Apache periodically. It's definitely
true of most PHP scripts that they're unconcerned about resource
leakage, on the assumption that everything'll get cleared out at the
end of a page render. PHP seems to encourage sloppiness.

ChrisA
 
I

Ian Kelly

I thought that jmf's concerns were solely concerned with the selection of
latin1 as the 1 byte set. My impression was that if some set of characters
was chosen that included all characters commonly used in French then all
would be well with the world.

But now I'm confused because latin1 seems to cater for French quite well:

http://en.wikipedia.org/wiki/ISO/IEC_8859-1

I understand ISO 8859-15 (Latin-9) to be the preferred Latin character
set for French, as it includes the Euro sign as well as a few
characters that are not in Latin-1 but are nonetheless infrequently
found in French.
 
M

Mark Lawrence

Yes, I confirm, it's a performance regression. It should be avoidable.
Almost any PEP393 performance regression can be avoided. At least for
such corner case. Just no one has yet optimized this case.

I have taken a liberty and raised this on the bug tracker quoting Steven
D'Aprano's original figures and your response above.
 
D

Devin Jeanpierre

Did you read the article or just make up a witty response? If so, you
half succeeded.

It's more like, "Well, maybe, your concerns *might* be legitimate, but I
don't think so because..." and then he gives half a dozen or more reasons
why Python is in no danger. None of which involve cake, although one of
them did involve Raspberry Pi. An easy mistake to make.

Haha! :)

Well, I don't agree. But let me explain.

If we're going to have a serious discussion about the problems Python
faces in the future, then the topics that Calvin brings up are
relevant. These are problems that, ideally, we would overcome. And I
think, to some degree, we are working towards a future where these
problems are solved. (Except perhaps the game development one, which
is a rather tough problem in a lot of ways.)

As people have noted, we do have Kivy, we do have PyPy, we do have
PyJS and other such things. The future has possibilities for the
problems Calvin mentions to be solved, even if they are problems
today.

The article that was linked, the response, it doesn't talk about this.

When Calvin says that Python has problems with mobile, the article
doesn't even say "but Kivy does mobile" -- it says "but Science people
love Python!"

When Calvin says that Python has problems being done on the web, the
article doesn't even say "but PyJS!" (regardless of the problems of
relying on a hijacked project), it says "education loves Python!"

When Calvin says that Python has failed for game development, the
article doesn't try to explain any way that Python is moving to
success here, or any way that Calvin's assessment is wrong. Instead,
it says, "But The Web loves Python!"

There is a pattern here. The pattern is that the article does not
actually directly respond to anything Calvin said. It doesn't try to
carry a dialogue about concerns about problem areas Python has. It
ignores Python's problems, and focuses on its strengths.

Charitably, maybe we'd call this a way of encouraging people who are
discouraged by the bleaker tone of Calvin's post. And that's valid, if
we're worried about morale. Definitely Calvin's post could be -- and
has been -- taken the wrong way. It could be taken as a way of saying,
"Python is doomed!", even though that isn't something Calvin ever
wrote (he appears, from my reading, to be more worried about a
stagnating community than a failed language). Under that
interpretation, we would want other, more encouraging voices around,
talking about ways in which Python is good and will survive.

Uncharitably, it's just a way of hiding one's head in the sand,
ignoring any problems Python has by focusing on what problems it
doesn't have.

So that's why I said that the summary is, "but look, cake!". Instead
of being a dialogue about improving Python, it's a distraction from
the issues Calvin brought up. It brings up strengths, which are also
part of Python, but don't have much at all to do with Python's
weaknesses, or with what Calvin was talking about.

-- Devin
 
M

Mark Lawrence

Did you read the article or just make up a witty response? If so, you
half succeeded.

It's more like, "Well, maybe, your concerns *might* be legitimate, but I
don't think so because..." and then he gives half a dozen or more reasons
why Python is in no danger. None of which involve cake, although one of
them did involve Raspberry Pi. An easy mistake to make.

Haha! :)

Well, I don't agree. But let me explain.

[snipped]

-- Devin

The article Steven D'Aprano referred to is not a direct response to the
article I referred to, yet your words are written as if it were. May I
ask why? Or have I missed something?
 
M

Mark Lawrence


Well there's definite proof that the PyPy people are all completely
incompetent in a response on the above link, this is how easy it is "But
.... why does the runtime environment have to be so limiting? Operations
involving primitives could be easily compiled (on the fly - JIT) to
machine code and more advanced objects exist as plug-ins. Oh, and it
would be nice to be able to write such objects quickly and easily - not
the convoluted mess that it is currently."

Simples :)
 
C

Chris Angelico

The article Steven D'Aprano referred to is not a direct response to the
article I referred to, yet your words are written as if it were. May I ask
why? Or have I missed something?

Steven cited it with the words "And a response".

ChrisA
 
D

Devin Jeanpierre

The article Steven D'Aprano referred to is not a direct response to the
article I referred to, yet your words are written as if it were. May I ask
why? Or have I missed something?

Post hoc ergo propter hoc :(

-- Devin
 
E

Ethan Furman

Mark said:
Haha! :)

Well, I don't agree. But let me explain.

[snipped]

The article Steven D'Aprano referred to is not a direct response to the
article I referred to, yet your words are written as if it were. May I
ask why? Or have I missed something?

The second article didn't reference the first directly, but was aimed at
that general type of article. At any rate, Steven wrote as if it were a
direct response.

~Ethan~
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top