Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Article on the future of Python

Reply
Thread Tools

Article on the future of Python

 
 
rusi
Guest
Posts: n/a
 
      09-28-2012
On Sep 28, 5:54*pm, Steven D'Aprano <steve
(E-Mail Removed)> wrote:
> On Fri, 28 Sep 2012 05:08:24 -0700, rusi wrote:
> > On Sep 27, 5:11*pm, Devin Jeanpierre <(E-Mail Removed)> wrote:
> >> On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano

>
> >> <(E-Mail Removed)> wrote:
> >> > On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a
> >> > response:

>
> >> >http://data.geek.nz/python-is-doing-just-fine

>
> >> Summary of that article:

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

>
> >> -- Devin

>
> > 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%27...mputer_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.
>
> --
> Steven


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

http://litmus.com/blog/email-client-...hare-june-2012
 
Reply With Quote
 
 
 
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      09-28-2012
On Fri, 28 Sep 2012 14:37:21 +1000, Chris Angelico <(E-Mail Removed)>
declaimed the following in gmane.comp.python.general:


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

Then again, I've got too many database engines on this desktop:
SQLite3, Access/JET, MSDE/SQL Server, Firebird...
--
Wulfraed Dennis Lee Bieber AF6VN
http://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      09-28-2012
On Sat, Sep 29, 2012 at 12:31 AM, Dennis Lee Bieber
<(E-Mail Removed)> wrote:
> On Fri, 28 Sep 2012 14:37:21 +1000, Chris Angelico <(E-Mail Removed)>
> declaimed the following in gmane.comp.python.general:
>
>
>> 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.


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...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
 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      09-28-2012
On Fri, Sep 28, 2012 at 8:58 AM, Chris Angelico <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      09-28-2012
On Sat, Sep 29, 2012 at 1:14 AM, Ian Kelly <(E-Mail Removed)> wrote:
> On Fri, Sep 28, 2012 at 8:58 AM, Chris Angelico <(E-Mail Removed)> wrote:
>> 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.


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
 
Reply With Quote
 
rurpy@yahoo.com
Guest
Posts: n/a
 
      09-28-2012
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.)
 
Reply With Quote
 
rurpy@yahoo.com
Guest
Posts: n/a
 
      09-28-2012
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.)
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-28-2012
On Fri, 28 Sep 2012 06:14:32 -0700, rusi wrote:

> It would be good to pay attention before calling others to pay
> attention.
>
> http://litmus.com/blog/email-client-...s-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.



--
Steven
 
Reply With Quote
 
Devin Jeanpierre
Guest
Posts: n/a
 
      09-28-2012
On Thu, Sep 27, 2012 at 8:59 PM, alex23 <(E-Mail Removed)> wrote:
> On Sep 28, 2:17 am, Devin Jeanpierre <(E-Mail Removed)> wrote:
>> 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?


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
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-29-2012
On Fri, 28 Sep 2012 14:50:14 -0400, Devin Jeanpierre wrote:

> 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?



--
Steven
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Article on the future of Python Michael Harleman Python 0 09-25-2012 10:51 AM
Re: Calling a Perl Module from Python ( future direction of Python) Steve Holden Python 1 04-07-2005 02:44 PM
Re: Calling a Perl Module from Python ( future direction of Python) gf gf Python 5 04-07-2005 02:09 PM
Toward Python's future article daniel narf Python 3 10-08-2004 05:18 AM
My future Python IDE article David Mertz Python 41 09-13-2003 02:25 PM



Advertisments