Article on the future of Python

S

Serhiy Storchaka

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.

Even for Latin-9 Python 3.3 can be a little faster 3.2.

$ ./python -m timeit -s "s=bytes(range(256))*100" "s.decode('latin1')"

Python 2.7: 105 usec
Python 3.2: 20.4 usec
Python 3.3: 4.98 usec

$ ./python -m timeit -s "s=bytes(range(256))*100" "s.decode('latin9')"

Python 2.7: 700 usec
Python 3.2: 94.6 usec
Python 3.3: 93.2 usec
 
T

Terry Reedy

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 already did, about a month ago, for windows. I think the actual
problem is with find, not replace (which does a find before the
replace). When I asked on pydev, Victor Stinner had no explanation, but
said he might look into it eventually. Others thought it not terribly
important since 7 times blazingly fast is still fast (in your example,
29 versus 3 microseconds per operation.

jmf wrapping a possible real issue with anti-3.3 crud did not help in
getting attention to the regression.

I also reported results of running stringbench.py on both 3.2 and 3.3 on
windows. Overall, Unicode is nearly as fast as bytes and 3.3 as fast as
3.2. Find/replace is the notable exception in stringbench, so it is an
anomaly. Other things are faster in 3.3.
I think this should be raised as a performance regression.

I agree, and Mark did it.
 
W

wxjmfauth

This flexible string representation is wrong by design.
Expecting to divide "Unicode" in chunks and to gain something
is an illusion.
It has been created by a computer scientist who thinks "bytes"
when on that field one has to think "bytes" and usage of the
characters at the same time.
The latin-1 chunk illustrates this wonderfully.

jmf
 
W

wxjmfauth

This flexible string representation is wrong by design.
Expecting to divide "Unicode" in chunks and to gain something
is an illusion.
It has been created by a computer scientist who thinks "bytes"
when on that field one has to think "bytes" and usage of the
characters at the same time.
The latin-1 chunk illustrates this wonderfully.

jmf
 
T

Terry Reedy

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).

The title was "i-am-worried-about-the-future-of-python" (as in 'I am
afraid Python will not have one'), not 'python has problems in some
application areas'. Given the doom-y title and the tone of the article,
excuse me for thinking doom was the topic.

As for community: Calvin is worried that all the hot new people in these
particular areas will not use and contribute to Python and the community.
Under that
interpretation, we would want other, more encouraging voices around,
talking about ways in which Python is good and will survive.

And that is what the second article was about. It turns out that there
are hot new people in other growing areas where Python is growing.
Computing for science, megadata, and education are not going away. Being
a glue language for numerical computing was Python's first killer
application nearly two decades ago, and it still is an important one.
 
M

Mark Lawrence

This flexible string representation is wrong by design.

Please state who agrees with this and why.
Expecting to divide "Unicode" in chunks and to gain something
is an illusion.

Please provide the benchmarks to support your claim.
It has been created by a computer scientist who thinks "bytes"
when on that field one has to think "bytes" and usage of the
characters at the same time.

Please name this computer scientist so everybody knows to whom you are
referring.
The latin-1 chunk illustrates this wonderfully.

I understand from an earlier post that latin-9 meets your needs
completely for all French language characters plus the Euro sign, why
don't you simply use that and stop rabitting on about latin-1.

Would you please be so kind as to stand up as your voice is rather muffled.
 
C

Chris Angelico

You're posting to both comp.lang.python and python-list, are you aware
that that's redundant?

This flexible string representation is wrong by design.
Expecting to divide "Unicode" in chunks and to gain something
is an illusion.
It has been created by a computer scientist who thinks "bytes"
when on that field one has to think "bytes" and usage of the
characters at the same time.

There's another range of numbers that, in some languages, is divided
for efficiency's sake: Integers below 1<<[bit size]. In Python 2, such
numbers were an entirely different data type (int vs long); other
languages let you use the same data type for both, but "(1<<5)+1" will
be executed much faster than "(1<<500)+1". (And far as I know, a
conforming Python 3 implementation should be allowed to do that; 3.2
on Windows doesn't seem to, though.) That's all PEP 393 is; it's a
performance improvement for a particular subset of values that happens
to fit conveniently into the underlying machine's data storage.

If Python were implemented on a 9-bit computer, I wouldn't be
surprised if the PEP 393 optimizations were applied differently. It's
nothing to do with Latin-1, except insofar as the narrowest form of
string _happens_ to contain everything that's in Latin-1.

Go blame the Unicode consortium for picking that.
The latin-1 chunk illustrates this wonderfully.

Aside from replace(), as mentioned in this thread, are there any other
ways that this is so wonderfully illustrated? Or is it "wonderfully"
as in "I wonder if people will believe me if I keep spouting
unsubstantiated claims"?

ChrisA
 
A

alex23

"... 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 :)

You should see how awesome _my_ imaginary implementation is!
 
A

alex23

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.

But isn't that what counterpoint is all about? Calvin's article
highlighted what he felt were areas that Python isn't successful,
while Tim McNamara's pointed out areas it was. Just because Python
isn't used much in commercial video games doesn't undermine the point
that it's heavily used in education and research.

Does Python _have_ to be a go-to tool in gaming for it to not be on
its death march?

Or more to the point: rather than just complain about it... It's not
like there aren't active communities that _are_ working in this area:
PyGame, pyglet, Kivy are all projects that can be contributed to.

I love using Python and will endeavour to do so wherever I can, but
it's always going to be the case that a language has strengths &
weaknesses that other languages lack.
 
W

Walter Hurry

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.

Fair enough, but it's the M in the LAMP stack I object to. I'd much
rather have P.
 
W

Wayne Werner

I know this isn't the list for database discussions, but I've never gotten a
decent answer. I don't know much about either, so I'm kind of curious why
postgresql over mysql?

I'll try not to get too OT... I had previously just used MySQL (and
SQLite), but have been reaading some PostGres stuff lately. I took a look
around and basically... you and I won't know or notice a difference
probably ever. There's all sorts of crazy tweaks you can get for
reliability, speed, and backups depending on what you use. So the only
advice I can give on that is just learn to use both.

And even better yet, just use SQLAlchemy if you're ever touching a
database from Python because it handles all the mucky SQL for you - you
just define the ORM. (Hey look! A Python module!)

My $0.02
-Wayne
 
G

Greg Donald

I know this isn't the list for database discussions, but I've never gotten a
decent answer. I don't know much about either, so I'm kind of curious why
postgresql over mysql?

MySQL is an open-source PRODUCT owned by a for-profit company.

PostgreSQL is an open-source PROJECT and is unowned.

A lot of the major technical differences are outlined here:

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
 
G

Greg Donald

the only advice I can give on that is
just learn to use both.

I find there's little to lose in having experience with both.

Most every good web framework out there supports lots of different
databases through generic ORM layers.. so flipping back and forth to
see which database is better for your particular app and workload is
trivial.
 
B

Bob Martin

in 681910 20120927 131113 Devin Jeanpierre said:
Summary of that article:

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

Quote : "This piece argues that Python is an easy-to-learn
language that where you can be almost immediately productive in."
 
D

Dwight Hutto

Summary of that article:
Quote : "This piece argues that Python is an easy-to-learn
language that where you can be almost immediately productive in."

It is, but so is every other language. "hello world" is the
standard... follow the syntax, import/include the appropriate library
functions, and create your own to use them.
 
M

Mark Lawrence

I already did, about a month ago, for windows. I think the actual
problem is with find, not replace (which does a find before the
replace). When I asked on pydev, Victor Stinner had no explanation, but
said he might look into it eventually. Others thought it not terribly
important since 7 times blazingly fast is still fast (in your example,
29 versus 3 microseconds per operation.

jmf wrapping a possible real issue with anti-3.3 crud did not help in
getting attention to the regression.

I also reported results of running stringbench.py on both 3.2 and 3.3 on
windows. Overall, Unicode is nearly as fast as bytes and 3.3 as fast as
3.2. Find/replace is the notable exception in stringbench, so it is an
anomaly. Other things are faster in 3.3.


I agree, and Mark did it.

http://bugs.python.org/issue16061 and you should read it. I've tried to
really muddy the waters by opening this issue, and the python devs are
giving out facts, how dare they!!! It's just not my day is it? :(
 
S

Steven D'Aprano

My summary of the first (worried about python) article: Python is about
to miss the Bell's law bus:

http://en.wikipedia.org/wiki/Bell's_Law_of_Computer_Classes


Except that very concept is stupid. Mainframes have not be replaced.
There are more mainframes around today than fifty years ago.
Minicomputers too, only we don't call them minicomputers, we call them
"servers".

In ten years time, there will be more desktop PCs around than now. Most
of them will be in the 90% of the world that isn't America. And most of
them will be laptops. But they'll be used as desktops too. Not everybody
wants to read email on a device smaller than your hand, clumsily poking
at a tiny virtual keyboard.

And anybody who thinks that Python can't run on tablets or smartphones
hasn't been paying attention.
 

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

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top