Article on the future of Python

R

rusi

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.

It would be good to pay attention before calling others to pay
attention.

http://litmus.com/blog/email-client...june-2012/email-client-market-share-june-2012
 
D

Dennis Lee Bieber

For further details, poke around on the web; I'm sure you'll find
plenty of good blog posts etc. But as for me and my house, we will
have Postgres serve us.

Please, at least use the proper name... "Postgres" is a non-SQL
database inspired by Ingres. "PostgreSQL" is Postgres with an SQL query
engine.

On my side... I have MySQL running on my desktop. When I started,
MySQL had a native build that would run on Win9X; PostgreSQL at the time
required installing a Cygwin environment.

MySQL v5 has improved a lot from those days (v3)... It now supports
stored procedures, triggers, a form of views, and prepared statements
(though MySQLdb is still pre v5 and sends completely formatted string
queries). They've even added GIS capabilities. (And then there is the
"drop-in" replacement for MySQL -- MariaDB:
http://kb.askmonty.org/en/mariadb-vs-mysql-compatibility/ )

Then again, I've got too many database engines on this desktop:
SQLite3, Access/JET, MSDE/SQL Server, Firebird...
 
C

Chris Angelico

Please, at least use the proper name... "Postgres" is a non-SQL
database inspired by Ingres. "PostgreSQL" is Postgres with an SQL query
engine.

http://www.postgresql.org/docs/9.1/static/history.html
"Many people continue to refer to PostgreSQL as "Postgres" (now rarely
in all capital letters) because of tradition or because it is easier
to pronounce. This usage is widely accepted as a nickname or alias."

There's lots of internal documentation that references "Postgres". I
don't see it as that big a deal.
On my side... I have MySQL running on my desktop. When I started,
MySQL had a native build that would run on Win9X; PostgreSQL at the time
required installing a Cygwin environment.

MySQL v5 has improved a lot from those days (v3)... It now supports
stored procedures, triggers, a form of views, and prepared statements
(though MySQLdb is still pre v5 and sends completely formatted string
queries). They've even added GIS capabilities. (And then there is the
"drop-in" replacement for MySQL -- MariaDB:
http://kb.askmonty.org/en/mariadb-vs-mysql-compatibility/ )

Yes, MySQL has definitely improved. There was a time when its
unreliability applied to all your data too, but now you can just click
in InnoDB and have mostly-real transaction support etc. But there's
still a lot of work that by requirement happens outside of
transactions - MySQL doesn't let you roll back DDL, for instance.

ChrisA
 
I

Ian Kelly

Yes, MySQL has definitely improved. There was a time when its
unreliability applied to all your data too, but now you can just click
in InnoDB and have mostly-real transaction support etc. But there's
still a lot of work that by requirement happens outside of
transactions - MySQL doesn't let you roll back DDL, for instance.

Neither does Oracle, for that matter. I don't really see any reason
why DDL *should* be transactional in nature. If your web app is
issuing DDL statements, then you're probably doing something wrong.
 
C

Chris Angelico

Neither does Oracle, for that matter. I don't really see any reason
why DDL *should* be transactional in nature. If your web app is
issuing DDL statements, then you're probably doing something wrong.

I have an auto-update script that ensures that our database is at the
correct patchlevel. It's fairly straight-forward: switch on
patchlevel, execute the statements required to get up to the next one,
at the bottom record the patchlevel in the database. (This relieves us
of issues of schema changes done in development that didn't get pushed
to production, for instance; our source code repository has
_everything_ needed.) If anything goes wrong, Postgres will roll the
transaction back. It doesn't matter if the first statement added a
column to a table and the second does an INSERT... SELECT; they both
get rolled back (as would any change to the patchlevel field, though
that happens at the very end so it's not significant here). I can
guarantee that the patch has either been completely applied or
completely rolled back - exactly what transactions are for.

ChrisA
 
R

rurpy

On 09/27/2012 10:37 PM, Chris Angelico wrote:>[...]
* MySQL is designed for dynamic web sites, with lots of reading and
not too much writing. Its row and table locking system is pretty
rudimentary, and it's quite easy for performance to suffer really
badly if you don't think about it. But if your needs are simple, MySQL
is probably enough. PostgreSQL uses MVCC to avoid locks in many cases.
You can happily read from a row while it's being updated; you'll be
unaware of the update until it's committed.

MVCC comes with a cost though, as anyone who has ever needed
to do a SELECT COUNT(*) on a large Postgresql table knows.
[...]
* Both engines have good support in popular languages, including
(dragging this back on topic, kicking and screaming) Python.

Maybe things are different now but a few years ago I was trying
to choose between Postgresql and Mysql about the time Python
2.4 (I think) was released. After waiting for over a year for
the Python mysql dbi module to be released for the then current
version of Python (I needed a binary for Windows) I finally
gave up and decided to go with Postgresql (the psycopg2 module
was available a very short time after the new Python was.)
 
R

rurpy

On 09/27/2012 10:37 PM, Chris Angelico wrote:>[...]
* MySQL is designed for dynamic web sites, with lots of reading and
not too much writing. Its row and table locking system is pretty
rudimentary, and it's quite easy for performance to suffer really
badly if you don't think about it. But if your needs are simple, MySQL
is probably enough. PostgreSQL uses MVCC to avoid locks in many cases.
You can happily read from a row while it's being updated; you'll be
unaware of the update until it's committed.

MVCC comes with a cost though, as anyone who has ever needed
to do a SELECT COUNT(*) on a large Postgresql table knows.
[...]
* Both engines have good support in popular languages, including
(dragging this back on topic, kicking and screaming) Python.

Maybe things are different now but a few years ago I was trying
to choose between Postgresql and Mysql about the time Python
2.4 (I think) was released. After waiting for over a year for
the Python mysql dbi module to be released for the then current
version of Python (I needed a binary for Windows) I finally
gave up and decided to go with Postgresql (the psycopg2 module
was available a very short time after the new Python was.)
 
S

Steven D'Aprano

It would be good to pay attention before calling others to pay
attention.

http://litmus.com/blog/email-client-market-share-stats-infographic-
june-2012/email-client-market-share-june-2012

Oh my, that's hilarious.

It's a big, flashy "infographic" with lots of graphics and absolutely no
meaningful information. As pure a case of "garbage in, garbage out" as
you can hope to see. Hidden in the fine print:

"Data for some email clients and mobiles may be over- and under-
represented due to image blocking."

You think?

I would have thought that the whole Thunderbird-doesn't-get-a-mention
might have given you a clue that the data there was rubbish. Or that they
think more people use Yahoo than Gmail. Riiiight. 1% of email users are
on AOL? Pull the other one, it has bells on.

Three years ago, there were about 2 billion active email users worldwide.
1% of that is 20 million. There are fewer than 4 million AOL subscribers,
or about 0.2% (or less, given that total email users are increasing and
AOL subscribers are not).

The only thing that link is good for is determining which mail clients
have crap privacy policies.

Thank you for sharing this, it is a great example of the use of bogus
statistics.
 
D

Devin Jeanpierre

But isn't that what counterpoint is all about?

Actually I think it's about the charitable interpretation. Nobody
writes an article and says, "I'm going to stick my head in the sand".
I do believe the article is trying to provide a counterweight to the
gloomy mood set by the first.
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.

Absolutely. But also, vice versa -- just because Python is a wonderful
language for education and research does not mean that its problems in
commercial video games are not worth looking at.
Does Python _have_ to be a go-to tool in gaming for it to not be on
its death march?

I don't think anyone is arguing it's on a death march, just that there
are issues that we downplay but should address to keep a vibrant and
diverse community. Or something.

I'm pretty sure nobody thinks Python is on a 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.

Haha, I wouldn't phrase it as "complaining".

Of these, I have mixed feelings. For example, Calvin has concerns that
Python isn't so good on mobile because battery usage (or some such
thing). I have no experience on mobile development, so no comment
there. I intend to use Kivy this weekend actually, so... Maybe this
one is very promising!

You didn't mention it, but for the browser issue there is PyJS... but
we've all heard the issues that project has. Not sure if there are
sane alternatives. Perhaps Silverlight? In all cases you end up with
output that's rather large. I'm not sure how practical it is, in the
end, to use Python. It may just be that the difference in productivity
for common web tasks, is tiny enough that the difficulty of setting up
an efficient python->JS toolchain is overwhelming.

As for pygame and pyglet, and game development, well, those are
things. That's a sort of frustrating response for a number of reasons,
but I'll keep it to just one:

Those have been around for a very long time, and are very stable (to
the point where the infrequency of updates sometimes leads to
questions as to whether they're even maintained (I think they are)).
The situation for using Python for game development is virtually
unchanged in the past several years, and it's been failing for the
past several years, so these two projects can't fix it. If these are
the best we have, barring additional argument we are going nowhere on
this front.

For what it's worth, I think there are much larger problems in the
game development world than how well Python is faring. Open source
projects for game development are few and of not-so-amazing quality.
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.

Absolutely! Python will never be perfect. There will always be paths
we can take to improve it. And we should always seek to improve it, as
long as we stand behind it as a good and useful language compared to
the alternatives.

On the other hand, I will not use Python "wherever I can". I will use
it wherever it makes the most sense to use it. For example, I would
write a first person shooter game in C# and Unity 3D, and I would
write my AJAX website in Javascript. It's just easier for me that way.
Why use Python if it makes my job harder?

-- Devin
 
S

Steven D'Aprano

I'm pretty sure nobody thinks Python is on a death march.

Don't be so sure. There's always *someone* complaining about something,
and they're usually convinced that (Language X) is on it's last legs
because (feature Y) is missing or (event Z) happened.

Seriously. If you believe the haters and the complainers, Python will
never be taken seriously as a language because:

- it has significant whitespace.
- it doesn't have braces.
- it doesn't have static typing.
- Python is too slow.
- it has lost momentum to Ruby on RAILS.
- it has lost momentum to Javascript.
- it doesn't have a real garbage collector that can collect cycles.
- oh, Python has had one of those for a decade? I meant a garbage
collector that can collect cycles involving objects with __del__
methods.
- threads aren't exactly like threads in some other language.
- Python only uses a single core of the CPU.
- I mean CPython. IronPython and Jython don't count.
- I mean ordinary Python code, using multiprocessing doesn't count.
- Neither do C extensions or numpy.
- Python changes too fast. People can't keep up. Python should be an ISO
standard managed by a committee, like C, with a guarantee that 30 year
old code will run in the latest version.
- Python changes too slow. People can't use all these great new features.
It has gotten too big and the developers care too much about backward
compatibility and aren't willing to delete cruft from the language.
- you can't compile to native machine code. No language can possibly be
successful with byte-code running in a virtual machine.
- it isn't a pure object-oriented language exactly like Java.
- you can't hide your source code from the end user. People will
STEEEAAAAAL MY INTELLECTUUUUUUUALLLLLL PROPERTY!!!
- oh, you can? Yeah, but it's too hard, and besides they might decompile
the .pyc files.
- Python 3 is a failure and has split the community.


I think I've got all the most common reasons for dismissing Python.
"Python has lost ground to Flash" is a new one for me, as is "Python ate
my mobile phone's batteries".


In a way, it's quite unfortunate that you can't write a blog post
discussing weaknesses of a language (as opposed to strengths) without
turning it into fuel for the haters:

http://news.ycombinator.com/item?id=4567023

But when you give a blog post an inflammatory title like "I am worried
about the future of Python", what do you expect?
 

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,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top