Article on the future of Python

[Mark Lawrence]

Hi all,

I though this might be of interest.

http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-python

--
Cheers.

Mark Lawrence.

[Michael Harleman]

That's a very interesting article.  It is encouraging to me, from reading many of the comments made, that I have chosen a good language to spend time learning despite the misgivings offered by the author.  I think Python does have a future in mobile markets as it is being used by some today according to one comment, and I can also see that apparently more development may need to be done, but I would think that would be true of any language.  What I like about Python among so many other things, is that it lends itself to be useful in almost any way I need it to.  Right now I am reading the Jython book, and realizing that Python can be wrapped around just about anything.  It truly is an amazing and versatile language.  Of course this is speaking as someone who has little experience at this point.  Thank you for sharing.  I'll be keeping this article bookmarked for future comparison.

Michael Harleman

>________________________________
> From: Mark Lawrence <bream...@yahoo.co.uk>
>To: pytho...@python.org
>Sent: Tuesday, September 25, 2012 4:15 AM
>Subject: Article on the future of Python

>-- http://mail.python.org/mailman/listinfo/python-list
>
>
> 

[Kevin Walzer]

On 9/25/12 4:15 AM, Mark Lawrence wrote:
> Hi all,
>
> I though this might be of interest.
>
> http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-python
>

Interesting article, but the comments of those who say "the only
language I need to know is Python" strike me as a bit limited. If this
is the case, then Python can never be moved forward, because it is
written in C.

I program in Python, C, Objective C, JavaScript, Tcl, AppleScript, and
I'm learning Perl. Python could *not* handle all the domains I target in
my projects. For instance: if I want to access Mac-native functionality
via Tkinter that isn't currently available in the library, I have to
drill down into C or Objective-C, write a wrapper that hooks in to the
primitives via Tcl's C API, then possibly write some additional Tcl code
to provide a cleaner interface, *then* write some kind of Python wrapper
that I can access in my Tkinter app.

I can understand loving the language and wanting to work just in the
language, but it's another thing entirely to call Python the One
Language to Rule Them All. (That's C, because all other languages are
implemented in it. :-) )

--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Roy Smith]

In article <k3sbdr$jce$1...@dont-email.me>,

Kevin Walzer <k...@codebykevin.com> wrote:

> the comments of those who say "the only
> language I need to know is Python" strike me as a bit limited.

I have been convinced that "X is the only language I need to know", for
many different values of X over the years.

[Martin P. Hellwig]

I glanced over the article but it seems to me another 'I am afraid this is not the silver bullet I wanted it to be' article without actually going into the need of a silver bullet or whether the concept of a silver bullet is sound at all.

--
mph

[Martin P. Hellwig]

On Tuesday, 25 September 2012 09:14:27 UTC+1, Mark Lawrence wrote:

[Steven D'Aprano]

On Tue, 25 Sep 2012 09:26:19 -0400, Kevin Walzer wrote:

> On 9/25/12 4:15 AM, Mark Lawrence wrote:
>> Hi all,
>>
>> I though this might be of interest.
>>
>> http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-
>> python
>>
>>
> Interesting article, but the comments of those who say "the only
> language I need to know is Python" strike me as a bit limited. If this
> is the case, then Python can never be moved forward, because it is
> written in C.

Incorrect.

IronPython in C#. Jython is written in Java. CLPython is written in Lisp.
Berp and HoPe are written in Haskell. Nuitka is written in C++. Skulpt is
written in Javascript. Vyper is written in Ocaml. PyPy is written in
RPython.

Some of those Python compilers are obsolete, unmaintained or
experimental. Others are not. But either way, it is certainly not true
that Python is written in C. One specific Python compiler happens to be
written in C, that is all.

> I program in Python, C, Objective C, JavaScript, Tcl, AppleScript, and
> I'm learning Perl. Python could *not* handle all the domains I target in
> my projects.

Unless you are writing code that operates on the bare metal (device
drivers, operating system kernels) Python probably *could*, even if it
doesn't *yet*. PyPy now allows you to write real-time video processing
filters in pure Python:

http://morepypy.blogspot.com.au/2011/07/realtime-image-processing-in-python.html


And if performance was irrelevant, you could even write an operating
system in Python. A really slow, painful operating system, but still an
operating system.

Given a sufficiently smart compiler, and sufficiently powerful libraries,
or sufficiently low expectations, pretty much any programming language
can do anything any other language can do. Almost all of them are Turing
complete.

But of course, in practice languages differ in their power and
capabilities.

> For instance: if I want to access Mac-native functionality
> via Tkinter that isn't currently available in the library,

That "isn't currently available" part is precisely what I'm talking
about. Just because it's not available now doesn't mean it can't be made
available.

> I can understand loving the language and wanting to work just in the
> language, but it's another thing entirely to call Python the One
> Language to Rule Them All. (That's C, because all other languages are
> implemented in it. :-) )

I see your smiley, but that is factually incorrect. Not all compilers or
interpreters are written in C. Many languages are self-hosted, that is,
they are written in themselves, using some clever bootstrapping
techniques. C is neither the most powerful, the oldest, the best, or the
most fundamental language around.


--
Steven

[Chris Angelico]

On Wed, Sep 26, 2012 at 1:35 AM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> I see your smiley, but that is factually incorrect. Not all compilers or
> interpreters are written in C. Many languages are self-hosted, that is,
> they are written in themselves, using some clever bootstrapping
> techniques. C is neither the most powerful, the oldest, the best, or the
> most fundamental language around.

Many compiled languages are bootstrapped, yes, but interpreted
languages less often so. And the bulk of implementations of the bulk
of interpreted languages seem to be implemented in C. But that's
largely because the bulk of Unix software is written in either C or a
high level language.

ChrisA

[Paul Rubin]

Kevin Walzer <k...@codebykevin.com> writes:
> language, but it's another thing entirely to call Python the One
> Language to Rule Them All. (That's C, because all other languages are
> implemented in it. :-) )

I got into a discussion about that in another newsgroup and noticed that
C seems to have been a 20th-century language that is still used for
maintaining old programs and in the embedded niche, but that very few
languages or compilers seem to have been newly implemented in C in the
current century. The main counterexample I was able to find was LuaJIT.

[Grant Edwards]

On 2012-09-25, Martin P. Hellwig <martin....@gmail.com> wrote:
> On Tuesday, 25 September 2012 09:14:27 UTC+1, Mark Lawrence wrote:
>> Hi all,
>>
>> I though this might be of interest.
>> http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-python

> I glanced over the article but it seems to me another 'I am afraid
> this is not the silver bullet I wanted it to be' article

Strange. I didn't get that _at_all_ from the article.

To me it was expressing concern about what happens when the range of
"niches" where Python is a good solution falls below a certain
critical mass -- will the "Python Community" start to stagnate because
it isn't attacting new developers in the quantity or diversity that it
used to...

--
Grant Edwards grant.b.edwards Yow! Alright, you!!
at Imitate a WOUNDED SEAL
gmail.com pleading for a PARKING
SPACE!!

[88888 Dihedral]

Grant Edwards於 2012年9月26日星期三UTC+8上午2時25分31秒寫道：

I don't think so in 201X. The uni-code support for users and clients
all over the world should not be taxed by WINTEL only in
multi-language support under the OS. I am glad to see a lot smart phones
or pads are fostering applications in various languages to help the IT
industry keeping growing and expanding to those regeions covered
by wirelees digital communications with devices priced in the range
200 to 12000 usd.

[Steven D'Aprano]

On Tue, 25 Sep 2012 18:25:30 +0000, Grant Edwards wrote:

> On 2012-09-25, Martin P. Hellwig <martin....@gmail.com> wrote:
>> On Tuesday, 25 September 2012 09:14:27 UTC+1, Mark Lawrence wrote:
>>> Hi all,
>>>
>>> I though this might be of interest.
>>> http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-
python
>
>> I glanced over the article but it seems to me another 'I am afraid this
>> is not the silver bullet I wanted it to be' article
>
> Strange. I didn't get that _at_all_ from the article.
>
> To me it was expressing concern about what happens when the range of
> "niches" where Python is a good solution falls below a certain critical
> mass -- will the "Python Community" start to stagnate because it isn't
> attacting new developers in the quantity or diversity that it used to...

Sounds like the same thing to me. Since Python fails to capture all the
development niches, it is not a silver bullet for programming, and
therefore it won't attract the fresh new blood it needs, because everyone
is programming for <insert list of niches here>.

I guarantee you that you could pick *any* language in existence, and find
three areas that are dominated by other languages, which *somebody* could
have convinced themselves is essential to the health of the community.

C? Once upon a time the C community was growing at a rapid rate because
of the Unix admins that picked it up from day-to-day scripting tasks
using c-shell. C became popular on the back of Unix, Unix has stagnated
and people have moved on from csh to bash and other shells. The default
shell on Linux is bash! C is in danger of no longer attracting new
developers, and if you think the Python 2 -> 3 transition was disruptive,
you should see what's happened in C: you have C, C++, Objective-C, C#,
even C-- and D.

SQL? All the exciting, innovative work in databases is happening in the
non-relational field of NoSQL languages. Without the ability to handle
Google's database needs, and with a name like NoSQL attracting all the
best and brightest database developers away from SQL, it's time to sell
your shares in Oracle.

Java? More and more development is moving to HTML5 and Javascript. With
the public's abandonment of the Java plugin for browsers, and schools
moving towards Python and PHP as a first language, Java's days are
numbered.

Cobol? Sure, eighty percent of the code in active use is written in
Cobol. Sure, there are 200 times more Cobol transactions per day than
Google searches -- about three quarters of *all* computer transactions
are done using Cobol. But Cobol only gets used for such boring stuff as
keeping your money safe in the bank. All the real innovation is in, well,
everything except Cobol. The imminent demise of Cobol is predicted for
1975^W 1980^W 1985^W 1990^W 1995^W 2005^W 2010^W 2015.



--
Steven

[Paul Rubin]

Steven D'Aprano <steve+comp....@pearwood.info> writes:
> C? Once upon a time the C community was growing at a rapid rate
> because of the Unix admins that picked it up from day-to-day scripting
> tasks using c-shell.

Er, I think it was developers rather than admins back then... the
sysadmin languages were awk then Perl.

> SQL? All the exciting, innovative work in databases is happening in the
> non-relational field of NoSQL languages.

Where have you been? That was LAST week...

http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html
(shorter: http://tinyurl.com/8v3dzyr )

;-)

> More and more development is moving to HTML5 and Javascript.

Yes. Python, Ruby, and Javascript are all pretty similar languages.
I'm pretty comfortable with Python so I don't feel much need to pursue
Ruby, and from the Ruby side the Python picture looks similar.
Javascript used to live mostly in browsers so it didn't come into the
question except for client-side web programmers. But, web client
programming has gotten more ubiquitous than ever, and Javascript is
metastasizing to the desktop and server through things like node.js. So
it may in fact put pressure on Python.

[Chris Angelico]

On Wed, Sep 26, 2012 at 10:54 AM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> SQL? ... it's time to sell your shares in Oracle.

Ehh, I wouldn't be investing in Oracle, but that's more because I
think free RDBMSes like PostgreSQL outshine it. And this is even more
true of MS SQL Server - this last week I've been researching options
for moving work's services to the cloud, and SQL Server licenses cost
ridiculous amounts (per month or per hour); what do you get for that
money that you can't get from Postgres?

On Wed, Sep 26, 2012 at 11:04 AM, Paul Rubin <no.e...@nospam.invalid> wrote:
> Yes. Python, Ruby, and Javascript are all pretty similar languages.
> I'm pretty comfortable with Python so I don't feel much need to pursue
> Ruby, and from the Ruby side the Python picture looks similar.
> Javascript used to live mostly in browsers so it didn't come into the
> question except for client-side web programmers. But, web client
> programming has gotten more ubiquitous than ever, and Javascript is
> metastasizing to the desktop and server through things like node.js. So
> it may in fact put pressure on Python.

Well, Python, Ruby, and
JavaScript/Javascript/ECMAScript/etceterascript aren't what I'd call
"similar languages", except that they're all modern high level
languages. But they're all able to solve similar problems, which I
think is what you're saying here.

The flip side to node.js is pyjs. One lets you write your server in
Javascript... the other lets you write your client in Python. And
there are quite a few other options for writing browser scripts in
other languages. Is JS dead yet? Nope.

There's room in this world for a lot of languages.

ChrisA

[Steven D'Aprano]

On Wed, 26 Sep 2012 14:10:28 +1000, Chris Angelico wrote:

> The flip side to node.js is pyjs.

After the ham-fisted, nasty way pyjamas project was hijacked this year,
I'm not entirely sure I'd want to touch it with a fifty-foot pole.

http://technogems.blogspot.com.au/2012/05/pyjamas-hijacked.html

Any pajamas users here want to comment on the fallout? Is the project
alive, dead, or walking dead?


--
Steven

[Chris Angelico]

That is true, but the concept is still around - that you can write
your code in some other language and compile to js. Personally, I'd
rather just write my js directly, and use Python to write Python code,
but I'm sufficiently multilingual to be able to do that. If you know
only 1-2 languages, there's (short-term) benefit in using them for
more tasks.

ChrisA

[Paul Rubin]

Chris Angelico <ros...@gmail.com> writes:
> That is true, but the concept is still around - that you can write
> your code in some other language and compile to js.

http://www.haskell.org/haskellwiki/The_JavaScript_Problem

[wxjm...@gmail.com]

Py 3.3 succeeded to somehow kill unicode and it has
been transformed into an "American" product for
"American" users.

---

From nnn:
> ...schools moving towards Python...

I do not know what "schools" covers.
Interestingly (and unfortunately), it just becomes
a no-tool for those who wish to teach Unicode. Or,
in one sense, it just become one!

PS I spent my last days with XeTeX and unicode-math.

jmf

[Steven D'Aprano]

On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote:

> Py 3.3 succeeded to somehow kill unicode and it has been transformed
> into an "American" product for "American" users.

For the first time in Python's history, Python on 32-bit systems handles
strings containing Supplementary Multilingual Plane characters correctly,
and it does so without doubling or quadrupling the amount of memory every
single string takes up.

Strings are ubiquitous in Python -- every module, every variable, every
function, every class is associated with at least one and often many
strings, and they are nearly all ASCII strings. The overhead of using
four bytes instead of one for every string is considerable.

Python finally has correct unicode handling for characters beyond the BMP,
and it does so with more efficient strings that potentially use as little
as one quarter of the memory that they otherwise would use, at the cost
of a small slowdown in the artificial and unrealistic case that you
repeatedly create millions of strings and then just throw them away
immediately. Most realistic cases of string handling are unchanged in
speed, either trivially faster or trivially slower. The real saving is in
memory.

According to wxjmfauth, this has "killed" unicode. Judge for yourself his
credibility. The best I can determine, he believes this because Americans
aren't made to suffer for using mostly ASCII strings.



--
Steven

[Ethan Furman]

wxjm...@gmail.com wrote:
> Py 3.3 succeeded to somehow kill unicode and it has
> been transformed into an "American" product for
> "American" users.

*plonk*

[Dwight Hutto]

On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman <et...@stoneleaf.us> wrote:
> wxjm...@gmail.com wrote:
>>
>> Py 3.3 succeeded to somehow kill unicode and it has
>> been transformed into an "American" product for
>> "American" users.
>
>

Well, we can all use american as a standard, or maybe you'd prefer to
borrow my Latin for Idiots handbook. But then again google has a
Universal Communicator going, so, does it matter?



--
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com

[Chris Angelico]

On Wed, Sep 26, 2012 at 5:39 PM, Dwight Hutto <dwight...@gmail.com> wrote:
> On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman <et...@stoneleaf.us> wrote:
>> wxjm...@gmail.com wrote:
>>>

>>> Py 3.3 succeeded to somehow kill unicode and it has
>>> been transformed into an "American" product for
>>> "American" users.
>>

> Well, we can all use american as a standard, or maybe you'd prefer to
> borrow my Latin for Idiots handbook. But then again google has a
> Universal Communicator going, so, does it matter?

Never in the field of human discussion has there been so much reason
for so many to plonk so few.

ChrisA

[Dwight Hutto]

>> Well, we can all use american as a standard, or maybe you'd prefer to
>> borrow my Latin for Idiots handbook. But then again google has a
>> Universal Communicator going, so, does it matter?
>
> Never in the field of human discussion has there been so much reason
> for so many to plonk so few.
>

"Plonk" it if you want. Your homosexual ideologies have no effect on
me. Butt, back to the discussion, there are quite a few ways to
encode, as well as translate code.

Plonk it in your mouth, and let the nut hairs tickle your throat.

> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list

[Terry Reedy]

On 9/26/2012 2:35 AM, wxjm...@gmail.com wrote:

> Py 3.3 succeeded to somehow kill unicode and it has
> been transformed into an "American" product for
> "American" users.

Python 3.3 is the first version that handles the full unicode character
set correctly on all platforms. If anything, it will make unicode more
alive and Python better suited for international applications.

--
Terry Jan Reedy

[Mark Lawrence]

On 26/09/2012 05:10, Chris Angelico wrote:

> On Wed, Sep 26, 2012 at 10:54 AM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:
>> SQL? ... it's time to sell your shares in Oracle.
>
> Ehh, I wouldn't be investing in Oracle, but that's more because I
> think free RDBMSes like PostgreSQL outshine it. And this is even more
> true of MS SQL Server - this last week I've been researching options
> for moving work's services to the cloud, and SQL Server licenses cost
> ridiculous amounts (per month or per hour); what do you get for that
> money that you can't get from Postgres?
>

> ChrisA
>

Maybe true but do free RDBMes have the sales and marketing budgets that
effectively shot down Ingres?

--
Cheers.

Mark Lawrence.

[Mark Lawrence]

On 26/09/2012 07:35, wxjm...@gmail.com wrote:
>
> Py 3.3 succeeded to somehow kill unicode and it has
> been transformed into an "American" product for
> "American" users.

> jmf
>

Why do you keep repeating this rubbish when you've already been shot to
pieces? Don't you know when it's time to make sure that you're safely
strapped in and reach for and use the release button for the ejector
seat. Further for somebody who is apparently up in the high tech world,
why are you using a gmail account and hence sending garbage in more ways
than one to mailing lists like this?

--
Cheers.

Mark Lawrence.

[Mark Lawrence]

On 26/09/2012 08:44, Chris Angelico wrote:
> On Wed, Sep 26, 2012 at 5:39 PM, Dwight Hutto <dwight...@gmail.com> wrote:
>> On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman <et...@stoneleaf.us> wrote:
>>> wxjm...@gmail.com wrote:
>>>>

>>>> Py 3.3 succeeded to somehow kill unicode and it has
>>>> been transformed into an "American" product for
>>>> "American" users.
>>>

>> Well, we can all use american as a standard, or maybe you'd prefer to
>> borrow my Latin for Idiots handbook. But then again google has a
>> Universal Communicator going, so, does it matter?
>
> Never in the field of human discussion has there been so much reason
> for so many to plonk so few.
>

> ChrisA
>

I tried to make a play on that some days ago and failed dismally.
Thanks for putting me out of my misery :)

--
Cheers.

Mark Lawrence.

[Chris Angelico]

On Wed, Sep 26, 2012 at 6:34 PM, Mark Lawrence <bream...@yahoo.co.uk> wrote:
> Further for somebody who is apparently up in the high tech world, why are
> you using a gmail account and hence sending garbage in more ways than one to
> mailing lists like this?

I use gmail too, largely because I prefer to keep mailing list posts
off my primary account.

ChrisA

[Dwight Hutto]

>
> Why do you keep repeating this rubbish when you've already been shot to
> pieces?

I still feel intact, so whatever little shards of pain you intended to
emit were lost on my ego.

Don't you know when it's time to make sure that you're safely
> strapped in and reach for and use the release button for the ejector seat.

You ain't shot down shit, but your own reputation. Look at the full
conversation.

> Further for somebody who is apparently up in the high tech world, why are
> you using a gmail account and hence sending garbage in more ways than one to
> mailing lists like this?

Um, using gmail instead of reinventing the wheel is now appropriate to you?

[Dwight Hutto]

> I tried to make a play on that some days ago and failed dismally.

That's the fucking understatement of the year.

Thanks for
> putting me out of my misery :)
--

No prob.

[Mark Lawrence]

On 26/09/2012 09:47, Dwight Hutto wrote:
>> I tried to make a play on that some days ago and failed dismally.
>
> That's the fucking understatement of the year.
>

You remind me of the opening to the song Plaistow Patricia by Ian Dury
and the Blockheads.

> Thanks for
>> putting me out of my misery :)


--

Cheers.

Mark Lawrence.

[Dwight Hutto]

>> That's the fucking understatement of the year.
>>
>
> You remind me of the opening to the song Plaistow Patricia by Ian Dury and
> the Blockheads.

Make a modern day/mainstream reference, and maybe someone will get it.

>
>
>> Thanks for
>>>
>>> putting me out of my misery :)

Again, no problem...anytime buddy.
--

[Ramchandra Apte]

On Tuesday, 25 September 2012 21:05:01 UTC+5:30, Steven D'Aprano wrote:
> On Tue, 25 Sep 2012 09:26:19 -0400, Kevin Walzer wrote:

>
>
>
> > On 9/25/12 4:15 AM, Mark Lawrence wrote:
>
> >> Hi all,
>
> >>
>
> >> I though this might be of interest.
>
> >>
>
> >> http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-
>
> >> python
>
> >>
>
> >>
>

> > Interesting article, but the comments of those who say "the only
>
> > language I need to know is Python" strike me as a bit limited. If this
>
> > is the case, then Python can never be moved forward, because it is
>
> > written in C.
>
>
>
> Incorrect.
>
>
>
> IronPython in C#. Jython is written in Java. CLPython is written in Lisp.
>
> Berp and HoPe are written in Haskell. Nuitka is written in C++. Skulpt is
>
> written in Javascript. Vyper is written in Ocaml. PyPy is written in
>
> RPython.
>
>
>
> Some of those Python compilers are obsolete, unmaintained or
>
> experimental. Others are not. But either way, it is certainly not true
>
> that Python is written in C. One specific Python compiler happens to be
>
> written in C, that is all.
>
>
>
>
>
> > I program in Python, C, Objective C, JavaScript, Tcl, AppleScript, and
>
> > I'm learning Perl. Python could *not* handle all the domains I target in
>
> > my projects.
>
>
>
> Unless you are writing code that operates on the bare metal (device
>
> drivers, operating system kernels) Python probably *could*, even if it
>
> doesn't *yet*. PyPy now allows you to write real-time video processing
>
> filters in pure Python:
>
>
>
> http://morepypy.blogspot.com.au/2011/07/realtime-image-processing-in-python.html
>
>
>
>
>
> And if performance was irrelevant, you could even write an operating
>
> system in Python. A really slow, painful operating system, but still an
>
> operating system.
>
That's what I plan to do.
But it will be converted to C/C++
>
>
> Given a sufficiently smart compiler, and sufficiently powerful libraries,
>
> or sufficiently low expectations, pretty much any programming language
>
> can do anything any other language can do. Almost all of them are Turing
>
> complete.
>
>
>
> But of course, in practice languages differ in their power and
>
> capabilities.
>
>
>
>
>
> > For instance: if I want to access Mac-native functionality
>
> > via Tkinter that isn't currently available in the library,
>
>
>
> That "isn't currently available" part is precisely what I'm talking
>
> about. Just because it's not available now doesn't mean it can't be made
>
> available.
>
>
>
>
>
> > I can understand loving the language and wanting to work just in the

>
> > language, but it's another thing entirely to call Python the One
>
> > Language to Rule Them All. (That's C, because all other languages are
>
> > implemented in it. :-) )
>
>
>

> I see your smiley, but that is factually incorrect. Not all compilers or
>
> interpreters are written in C. Many languages are self-hosted, that is,
>
> they are written in themselves, using some clever bootstrapping
>
> techniques. C is neither the most powerful, the oldest, the best, or the
>
> most fundamental language around.
>
>
>
>
>
> --
>
> Steven

[wxjm...@gmail.com]

Le mercredi 26 septembre 2012 09:23:47 UTC+2, Steven D'Aprano a écrit :
> On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote:
>
>
>
> > Py 3.3 succeeded to somehow kill unicode and it has been transformed
>
> > into an "American" product for "American" users.
>
>
>

Steven,

you are correct. But the price you pay for this is extremely
high. Now, practically all characters are affected, espacially
those *in* the Basic *** Multilingual*** Plane, these characters
used by non "American" user (No offense here, I just use this
word for ascii/latin-1).

I'm ready to be considered as an idiot, but I'm not blind.
As soon as I tested these characters, Py3.3 performs really
badly. It seems to me it is legitimate to consider, there
is a serious problem here.

- I'm speaking about "language characters", one should speak
about "scripting characters".
- Obviously affected are not only the "language characters",
but all characters, typographical signs, polytonic Greek,
up to mathematical "Bold italic sans serif, Latin, uppercase",
logically because all the "code points" are equivalent.

Many people are commmenting, I have the feeling, I'm the only
one who tested this. It is not necessary to dive in the Python
code, understanding all this "characters stuff" is enough.

And I am sorry, just saying "if you are not happy, switch
back to Python 2.7 or use Ruby" (you know where you can
read it) is in my mind not a correct answer. It only
reflect a "yes, there is a problem, but..."

Do not worry about me, I attempt to keep a neutral eye.
It is my point of view (and facts). I will not open a blog
with a "Python blah, blah, blah".

jmf

[Dwight Hutto]

>>
>> they are written in themselves, using some clever bootstrapping
>>
>> techniques. C is neither the most powerful, the oldest, the best, or the
>>
>> most fundamental language around.

Would you recommend Assembly, because C just becomea macros of
Assembly, or better yet machine language, which is line for line
procedural Assembly for the processor instruction set working in line
with the OS..

[Chris Angelico]

On Wed, Sep 26, 2012 at 7:31 PM, <wxjm...@gmail.com> wrote:
> you are correct. But the price you pay for this is extremely
> high. Now, practically all characters are affected, espacially
> those *in* the Basic *** Multilingual*** Plane, these characters
> used by non "American" user (No offense here, I just use this
> word for ascii/latin-1).
>
> I'm ready to be considered as an idiot, but I'm not blind.
> As soon as I tested these characters, Py3.3 performs really
> badly. It seems to me it is legitimate to consider, there
> is a serious problem here.

We've been over this thread. The only reason you're counting 3.3 as
worse is because you're comparing against a narrow build of Python
3.2. Narrow builds are **BUGGY** and this needed to be resolved.

When you compare against a wide build, semantics of 3.2 and 3.3 are
identical, and then - and ONLY then - can you sanely compare
performance. And 3.3 stacks up much better.

ChrisA

[Hannu Krosing]

Nope. They don't have budget to shoot down Ingres.

Also, free RDBMs do not engage in dubious promise-and-dont-deliver-
then-ask-more-money sales policies that got Oracle kicked out of US
Government simplified buying processes.

You can get only so far using "sales". At some point you have to deliver.

Hannu

[wxjm...@gmail.com]

At least when the others are sending a msg containing
non asii characters. I see them correctly.

When you send such a text, I'm only able to see
something like this (your_string):

>>> import fourbiunicode
>>> for c in your_string:
... fourbiunicode.FrenchNames[c]
...
'LETTRE MINUSCULE LATINE TRÉMA'
"POINT D'INTERROGATION RENVERSÉ"
'FRACTION UN DEMI'

You have all the elements to reconstruct what is
happening. (Notice, I'm not a Unicode illiterate)

jmf

[wxjm...@gmail.com]

Le mercredi 26 septembre 2012 10:35:04 UTC+2, Mark Lawrence a écrit :

[wxjm...@gmail.com]

Remember the TeX discussion a few days ago?

You are always selling the same argument.
Py3.3 is the only computer language I'm aware of which
is maltreating Unicode in such a way.

After all, if replacing a Nabla operator in a string take
10 times more times in Py33 than in Python32, it takes 10
times more . There is nothing more to say.

I proposed to make some tests with the characters
used by the IMPRIMERIE NATINALE", I can now suggest
to make some tests with random texts exceprt form
the "Guide du typographe romand".

What? Never heard from these? Do not worry too
much. The corporates (software producers) and
the foundries know these documents.

Finally, all in all, it's no a suprise, end users
are sticking with these products.

I'm not complaining, only disappointed.


jmf
(Time to go back to TeX)

[wxjm...@gmail.com]

Le mercredi 26 septembre 2012 10:13:58 UTC+2, Terry Reedy a écrit :

[Roy Smith]

In article <mailman.1421.1348653...@python.org>,

Hannu Krosing <ha...@krosing.net> wrote:

> You can get only so far using "sales". At some point you have to deliver.

But, by that time, the guy who closed the sale has already cashed his
bonus check, bought his new BMW, and moved on to another company.

And around that time, some poor schmuck of a dev manager is telling his
team what the sales guy sold. And that they have 12 weeks to design,
build, and deliver it.

[Mark Lawrence]

On 26/09/2012 10:31, wxjm...@gmail.com wrote:

>
> I'm ready to be considered as an idiot, but I'm not blind.

People here have seen enough of your writings to know that you're not an
idiot. I'm feeling far too polite right now to state what they actually
know about you.

> As soon as I tested these characters, Py3.3 performs really
> badly. It seems to me it is legitimate to consider, there
> is a serious problem here.

Your tests (for the lack of a better term) have been repeatedly shot to
pieces, refuted, you've shown nothing at all to indicate that Python 3.3
performs really badly.

>
> Many people are commmenting, I have the feeling, I'm the only
> one who tested this. It is not necessary to dive in the Python
> code, understanding all this "characters stuff" is enough.

Complete dross from a person who seems to know as much about the
combination of Python 3.3 and unicode as Hitler, Stalin and Pol Pot
amongst others knew about human rights.

--
Cheers.

Mark Lawrence.

[Mark Lawrence]

How long did you just say??? I promised it in 8 weeks, not 12 you
complete moron :)

--
Cheers.

Mark Lawrence.

[Kevin Walzer]

On 9/25/12 11:35 AM, Steven D'Aprano wrote:
> IronPython in C#. Jython is written in Java. CLPython is written in Lisp.
> Berp and HoPe are written in Haskell. Nuitka is written in C++. Skulpt is
> written in Javascript. Vyper is written in Ocaml. PyPy is written in
> RPython.
>
> Some of those Python compilers are obsolete, unmaintained or
> experimental. Others are not. But either way, it is certainly not true
> that Python is written in C. One specific Python compiler happens to be
> written in C, that is all.

Apart from IronPython, what constituency do these alternative
implementations of Python have that would raise them above the level of
interesting experiments?

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Littlefield, Tyler]

On 9/26/2012 2:11 AM, Dwight Hutto wrote:
>>> Well, we can all use american as a standard, or maybe you'd prefer to
>>> borrow my Latin for Idiots handbook. But then again google has a
>>> Universal Communicator going, so, does it matter?
>> Never in the field of human discussion has there been so much reason
>> for so many to plonk so few.
>>

> "Plonk" it if you want. Your homosexual ideologies have no effect on
> me. Butt, back to the discussion, there are quite a few ways to
> encode, as well as translate code.

You remind me of a little kid. When anything doesn't go your way, we
revert to homosexual comments (who said anything about homosexual
anyway), and you keep bringing up this whole nut hair deal. I think it's
you leaning that way buddy, especially since "most of us on here are guys."

> Plonk it in your mouth, and let the nut hairs tickle your throat.

> Take your trash somewhere else. You've provided nothing in terms of good feedback or responses, and I doubt you will provide more than insults.
PS: Anyone know if rantingrik had relatives? ;)

>> ChrisA
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
>


--

Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.

[Mark Lawrence]

On 26/09/2012 14:31, Littlefield, Tyler wrote:

>
> PS: Anyone know if rantingrik had relatives? ;)
>

I say steady on old chap that's just not cricket. I've been known to
have a go at rr in the past for good reasons, but when he gets stuck
into Tkinter he is an extremely useful contributor. I certainly prefer
him to Xah Lee, who's attempts at improving Python documentation were
beautifully torn to pieces here, IIRC by Ethan Furman, apologies to him
and the actual author if I'm incorrect.

--
Cheers.

Mark Lawrence.

[Chris Angelico]

On Wed, Sep 26, 2012 at 10:19 PM, <wxjm...@gmail.com> wrote:
> You are always selling the same argument.
> Py3.3 is the only computer language I'm aware of which
> is maltreating Unicode in such a way.

You mean, the only computer language that represents Unicode
characters as integers, and then stores them as an array of 8-bit,
16-bit, or 32-bit numbers depending on the highest codepoint? No, it's
not. I can disprove your statement with a single counterexample, but
it's entirely possible and (IMHO) likely that there are others too:

http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/String/width.html

Pike stores strings in largely the same way Python 3.3 does. Pike
strings are immutable and guaranteed to be interned, so it makes good
sense to store them as compactly as possible.

> After all, if replacing a Nabla operator in a string take
> 10 times more times in Py33 than in Python32, it takes 10
> times more . There is nothing more to say.

Comparing against a Py32 wide build, I find it hard to believe that
anything would take ten times as long. But I'll give you the benefit
of the doubt; maybe your number is in binary. I still do not expect
that it'd take twice as long. <voice imitate="Maxwell Smart">Would you
believe... barely slower?</voice> And even that's pushing it.

sigh... Why am I arguing this. I should get plonked myself for feeding
the trolls. Sorry all.

ChrisA

[Chris Angelico]

You know how people sometimes ask "What sort of idiot do you think I
am??!?", thus falling foul of the sage advice "Never test for an error
condition you don't know how to handle" [1]... well, on this list, it
makes good sense to ask what sort of troll someone is. We even have
Troll Rankings in which there's very definite striations of "useful
contributors who sometimes troll", "useless people who nevertheless
trigger interesting threads", and "utterly useless flamers". Troll
taxonomy is a science we could all benefit from studying...

ChrisA

[1] eg http://www.theregister.co.uk/2008/10/24/bofh_2008_episode_34/

[wxjm...@gmail.com]

No, I'm comparing Py33 with Py32 narrow build [*].
And I am not a Python newbie. Others in a previous
discussion have pointed "bad" numbers and even
TR wrote something like "I'm baffled (?) by these
numbers".

I took a look at the test suites, unfortunatelly
they are mainly testing "special cases", something
like one of the 3 internal representations, eg
"latin-1".

I can also add to this, that it is not only one
of the internal representation which may be
suspect (it is probably different now, Py32/Py33) but
also the "switch" between these representations
which is causing troubles.

[*] I have not the knowledge to compile a wide
build and I do not wish to spend my time in something
that will be most probably a nightmare for me.
I'm reacting like a "normal" Python user.

jmf

[wxjm...@gmail.com]

Le mercredi 26 septembre 2012 11:55:16 UTC+2, Chris Angelico a écrit :

[Chris Angelico]

On Thu, Sep 27, 2012 at 12:19 AM, <wxjm...@gmail.com> wrote:
> No, I'm comparing Py33 with Py32 narrow build [*].

Then look at the broken behaviour that Python, up until now, shared
with Javascript and various other languages, in which a one-character
string appears as two characters, and slicing and splicing strings can
split surrogates apart. The new rule is simple: One Unicode codepoint
takes up the space of one character. Anything else is mindbogglingly
counterintuitive.

ChrisA

[wxjm...@gmail.com]

I should add that I have not the knowledge to dive
in the Python code. But I "see" what has been done.
As I have a very good understanding of all this
coding of characters stuff, I can just pick up
- in fact select characters or combination
of characters - which I supspect to be problematic
and I see the results.

Not only this, I can select characters, I know
a user is supposed to use or will use eg. a specific
scrit/language, a typographical work, ...
(Do not ask how and why, I know this).

I'm not interesting in the other languages or in
unicode therory (also I not bad on this level).

I just see the results and the facts. For an end
user, this is the only thing that counts.

jmf

[wxjm...@gmail.com]

[Chris Angelico]

On Thu, Sep 27, 2012 at 12:50 AM, <wxjm...@gmail.com> wrote:
> I just see the results and the facts. For an end
> user, this is the only thing that counts.

Then what counts is that Python 3.2 (like Javascript) exhibits
incorrect behaviour, and Python (like Pike) performs correctly.

I think this tee applies to you. http://www.thinkgeek.com/product/f147/

ChrisA
wouldn't have bothered to respond except that that link was asking to be shared

[Mark Lawrence]

On 26/09/2012 15:50, wxjm...@gmail.com wrote:
> I should add that I have not the knowledge to dive
> in the Python code. But I "see" what has been done.

How?

> As I have a very good understanding of all this
> coding of characters stuff, I can just pick up
> - in fact select characters or combination
> of characters - which I supspect to be problematic
> and I see the results.

Have you run the Python benchmarks yet, as people have more trust in
something tangible than a claim that "I see the results"? You were
asked to do this one month ago. If yes please publish your results. If
no why not, if your claims were correct running the benchmarks would
obviously support you?

>
> Not only this, I can select characters, I know
> a user is supposed to use or will use eg. a specific
> scrit/language, a typographical work, ...
> (Do not ask how and why, I know this).

Please state how and why.

>
> I'm not interesting in the other languages or in
> unicode therory (also I not bad on this level).

Please prove your statement in brackets, nothing less is acceptable if
you're making claims, you need to substantiate them.

>
> I just see the results and the facts. For an end
> user, this is the only thing that counts.

The modern day Pinball Wizard? Or a physic? Or what?

>
> jmf
>

#pseudo code
for _ in range(-inf, +inf, 1): print(FUD)

--
Cheers.

Mark Lawrence.

[wxjm...@gmail.com]

"You" have gained a broader range of unicode code points
and the same time you "broke" a correct BMP behaviour.

There is a simple solution to solve this. "You" do not wish
to use it.
Luckily for me, the tools I'm using use that one.

jmf

[wxjm...@gmail.com]

[Chris Angelico]

On Thu, Sep 27, 2012 at 1:08 AM, Mark Lawrence <bream...@yahoo.co.uk> wrote:
> for _ in range(-inf, +inf, 1): print(FUD)

That'll never work. Try this:

import itertools
list(map(print,itertools.cycle(('FUD',))))

ChrisA

[wxjm...@gmail.com]

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

>>> timeit.repeat("('你'*10000).replace('你', 'a')")
[31.44532887821319, 31.409585124813844, 31.40705548932476]

>>> timeit.repeat("('你'*10000).replace('你', 'a')")
[323.56687741054805, 323.1660997337247, 325.52611455786905]

>>> timeit.repeat("('\u2207'*10000).replace('\u2207', 'a')")
[31.48614883771855, 31.472262820580987, 31.467803762040184]

>>> timeit.repeat("('\u2207'*10000).replace('\u2207', 'a')")
[320.55378064913526, 321.6890182785167, 321.4132045160866]

(Will wait for the final)

jmf

[wxjm...@gmail.com]

[Ian Kelly]

On Wed, Sep 26, 2012 at 1:23 AM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:

> On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote:
>
>> Py 3.3 succeeded to somehow kill unicode and it has been transformed
>> into an "American" product for "American" users.
>

> For the first time in Python's history, Python on 32-bit systems handles
> strings containing Supplementary Multilingual Plane characters correctly,
> and it does so without doubling or quadrupling the amount of memory every
> single string takes up.

Indeed. Here's an interesting article about Unicode handling that
identifies Python 3.3 as one of only four programming languages that
handle Unicode correctly (the other three being Bash, Haskell 98, and
Scheme R6RS).

http://unspecified.wordpress.com/2012/04/19/the-importance-of-language-level-abstract-unicode-strings/

[Ethan Furman]

Mark Lawrence wrote:
> On 26/09/2012 14:31, Littlefield, Tyler wrote:
>
>>
>> PS: Anyone know if rantingrik had relatives? ;)
>>
>
> I say steady on old chap that's just not cricket. I've been known to
> have a go at rr in the past for good reasons, but when he gets stuck
> into Tkinter he is an extremely useful contributor. I certainly prefer
> him to Xah Lee, who's attempts at improving Python documentation were
> beautifully torn to pieces here, IIRC by Ethan Furman, apologies to him
> and the actual author if I'm incorrect.

I don't think it was me -- my troll tolerance is extremely low;
currently there are sixteen in my troll trap.

I could easily see it being D'Aprano, though -- he's excellent at
shredding ridiculous arguments and even seems to enjoy it. Least ways,
I enjoy reading his responses. :)

~Ethan~

[Ethan Furman]

Chris Angelico wrote:
> On Wed, Sep 26, 2012 at 10:19 PM, <wxjm...@gmail.com> wrote:

>> After all, if replacing a Nabla operator in a string take

>> 10 times more times in Py33 than in Python32 [. . .]

>
> But I'll give you the benefit
> of the doubt; maybe your number is in binary.

+1 QOTW

[wxjm...@gmail.com]

May I suggest, you dive in the TeX documentation (sometimes,
no so easy to find quickly).

In my mind much better than all these web pages around. The big
plus, you will also understand "characters" as whole.

jmf

[wxjm...@gmail.com]

Le mercredi 26 septembre 2012 17:54:04 UTC+2, Ian a écrit :

[Paul Rubin]

Chris Angelico <ros...@gmail.com> writes:
> When you compare against a wide build, semantics of 3.2 and 3.3 are
> identical, and then - and ONLY then - can you sanely compare
> performance. And 3.3 stacks up much better.

I like to have seen real world benchmarks against a pure UTF-8
implementation. That means O(n) access to the n'th character of a
string which could theoretically slow some programs down terribly, but I
wonder how often that actually matters in ways that can't easily be
worked around.

[Chris Angelico]

That's pretty much what we have with the PHP parts of our web site.
We've decreed that everything should be UTF-8 byte streams (actually,
it took some major campaigning from me to get rid of the underlying
thinking that "binary-safe" and "UTF-8" and "characters" and so on
were all equivalent), but there are very few places where we actually
index strings in PHP. There's a small amount of parsing, but it's all
done by splitting on particular strings - if you search for 0x0A in a
UTF-8 bytestream and split at that index, it's the same as searching
for U+000A in a Unicode string and splitting there - and all of our
structural elements fit inside ASCII. The few times we actually care
about character length (eg limiting user-specified rule names to N
characters), we don't much care about performance, because they're
unusual checks.

So, I don't actually have any stats for you, because it's really easy
to just not index strings at all.

ChrisA

[Paul Rubin]

Chris Angelico <ros...@gmail.com> writes:
> So, I don't actually have any stats for you, because it's really easy
> to just not index strings at all.

Right, that's why I think the O(n) indexing issue of UTF-8 may be
overblown. Haskell 98 was mentioned earlier as a language that did
Unicode "correctly", but its strings are linked lists of code points.
They are a performance pig to be sure but the O(n) indexing is usually
not the bottleneck. These days there is a "Text" module that I think is
basically UTF-16 arrays. I have been meaning to find out what happens
with non-BMP characters.

[wxjm...@gmail.com]

The selection of a coding scheme is a problem per
se. In Py33 there is a mixin of coding schemes, an
artificial construction supposed to be a new coding
scheme.

As an exercise, pickup characters of each individual
coding, toy with them and see what happen.
This poor Python has not only the task to handle
the bytes of a coding scheme, now it has the
task to select the coding scheme it will use with
probably plenty of side effects.

Completely absurd. I am penalized simply because I add
a French character to a French word. A character which
does not belong to the same "category" of the characters
composing this word.

jmf

[Terry Reedy]

On 9/26/2012 4:45 AM, Dwight Hutto wrote:
>>
>> Why do you keep repeating this rubbish when you've already been shot to
>> pieces?
>
> I still feel intact, so whatever little shards of pain you intended to
> emit were lost on my ego.

Uh, Dwight, he was not talking to you.


--
Terry Jan Reedy

[Matej Cepl]

On 26/09/12 15:30, Kevin Walzer wrote:
> Apart from IronPython, what constituency do these alternative
and Jython ... that is widely used in the Java server world
> implementations of Python have that would raise them above the level of
> interesting experiments?

Matěj

[Terry Reedy]

On 9/26/2012 8:19 AM, wxjm...@gmail.com wrote:

> You are always selling the same argument.

Because you keep repeating the same insane argument against 3.3.

> Py3.3 is the only computer language I'm aware of which
> is maltreating Unicode in such a way.

You have it backwards. 3.3 fixes maltreatment of unicode, such as also
exists in other languages. re will also run better with 3.3. You have
not shown any new bugs. Many other languages do not handle extended
plane characters properly.

> After all, if replacing a Nabla operator in a string take

> 10 times more times in Py33 than in Python32, it takes 10
> times more . There is nothing more to say.

On the contrary, there is lots more to say. You have picked out the one
thing that 3.3 does not do as well and ignored all the things 3.3 does
better. I and others have already explained many of them. Included is
that fact that 3.3 does one operation 10, 100, 1000,... times faster
than 3.2.

--
Terry Jan Reedy

[Terry Reedy]

On 9/26/2012 2:58 PM, Ian Kelly wrote:

> You know, usually when I see software decried as America-centric, it's
> because it doesn't support Unicode. This must be the first time I've
> seen that label applied to software that dares to *fully* support Unicode.

What is truly bizarre is the idea came from and much or most of the
implementation was done by Europeans, not Americans.

--
Terry Jan Reedy

[Chris Angelico]

I suppose that a system that supports only Latin-1 is therefore Italy-centric?

ChrisA

[alex23]

On Sep 26, 10:17 pm, wxjmfa...@gmail.com wrote:
> Notice, I'm not a Unicode illiterate

Any chance you could work on your usenet literacy and fix your double
posts?

[Steven D'Aprano]

On Wed, 26 Sep 2012 07:19:56 -0700, wxjmfauth wrote:

> No, I'm comparing Py33 with Py32 narrow build [*]. And I am not a Python
> newbie. Others in a previous discussion have pointed "bad" numbers and
> even TR wrote something like "I'm baffled (?) by these numbers".

jmf, some time ago I said to you that if you want your claims to be taken
seriously, you should come up with a test suite that exercises the FULL
range of string operations and still demonstrates a significant slowdown.

Have you do this? I would be interested to run your test suite.

We know that if the only thing you do is repeatedly create strings, then
throw them away, then create more strings, then throw them away, Python
3.3 will be a little slower than Python 3.2. You say "ten times" slower,
but nobody else has been able to confirm this. Others are reporting that,
at worst, string handling is twice as slow and sometimes twice as fast,
depending on what operations you do, and what operating system you have.

(Since creating strings depends on allocating, and moving, blocks of
memory, the speed of creating strings is highly dependent on the
operating system's memory management.)

If all you want to do is complain and whinge and feel morally superior
that you are the only one that cares that "Python is slower" (allegedly),
please take it to your blog because we don't care.

But if you genuinely want to determine whether or not this slowdown is
meaningful in practice, and if so help optimise it so that it is faster,
then stop with the propaganda about Python destroying Unicode and start
writing a test suite.



--
Steven

[Steven D'Aprano]

On Wed, 26 Sep 2012 10:01:11 +0100, Mark Lawrence wrote:

> You remind me of the opening to the song Plaistow Patricia by Ian Dury
> and the Blockheads.

While I always appreciate a good reference to Ian Dury, please stop
feeding D.H.'s ego by responding to his taunts.


--
Steven

[Steven D'Aprano]

On Wed, 26 Sep 2012 09:30:19 -0400, Kevin Walzer wrote:

> On 9/25/12 11:35 AM, Steven D'Aprano wrote:
>> IronPython in C#. Jython is written in Java. CLPython is written in
>> Lisp. Berp and HoPe are written in Haskell. Nuitka is written in C++.
>> Skulpt is written in Javascript. Vyper is written in Ocaml. PyPy is
>> written in RPython.
>>
>> Some of those Python compilers are obsolete, unmaintained or
>> experimental. Others are not. But either way, it is certainly not true
>> that Python is written in C. One specific Python compiler happens to be
>> written in C, that is all.

>
> Apart from IronPython, what constituency do these alternative

> implementations of Python have that would raise them above the level of
> interesting experiments?

The "Big Four" are CPython, Jython, IronPython and PyPy. Possibly "Big
Five" if you include Stackless, although I'm not quite sure just how big
(popular) Stackless actually is. It's certainly old and venerable, and
actively maintained. If you've played EVE Online, you've seen Stackless
in action.

Jython has a big constituency in Java shops. I can't tell you much about
that because I don't use Java.

PyPy is, well, PyPy is amazing, if you have the hardware to run it. It is
an optimizing Python JIT compiler, and it can consistently demonstrate
speeds of about 10 times the speed of CPython, which puts it in the same
ballpark as native code generated by Java compilers. For some (admittedly
artificially narrow) tasks it can beat optimized C code. It's fast enough
for real time video processing, depending on the algorithm used.

While PyPy is still a work in progress, and is not anywhere near as
mature as (say) gcc or clang, it should be considered production-ready.

I expect that, within the decade, PyPy will become "the" standard Python
compiler and CPython will be relegated to "merely" the reference
implementation.



--
Steven

[Mark Lawrence]

Good point as he's had so much rope that he's hung himself several times
over. Thanks for helping me get my feet back on the ground.

--
Cheers.

Mark Lawrence.

[Walter Hurry]

I have a better idea: Consign him to the same bin as Dwight Hutto and
Dihedral.

[alex23]

On Sep 27, 6:27 am, Terry Reedy <tjre...@udel.edu> wrote:
> On 9/26/2012 4:45 AM, Dwight Hutto wrote:

> > my ego

> Uh, Dwight, he was not talking to you.

The irony, it is so rich :)

[Chris Angelico]

On Thu, Sep 27, 2012 at 10:44 AM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> PyPy is, well, PyPy is amazing, if you have the hardware to run it. It is
> an optimizing Python JIT compiler, and it can consistently demonstrate
> speeds of about 10 times the speed of CPython, which puts it in the same
> ballpark as native code generated by Java compilers. For some (admittedly
> artificially narrow) tasks it can beat optimized C code. It's fast enough
> for real time video processing, depending on the algorithm used.
>
> While PyPy is still a work in progress, and is not anywhere near as
> mature as (say) gcc or clang, it should be considered production-ready.

That's all very well, but unless I have my facts badly wrong, PyPy is
only compatible with Python 2 - right? I'd much rather have full
Unicode support etc etc etc than the coolness of
Python-implemented-in-Python, even with a significant performance
boost.

> I expect that, within the decade, PyPy will become "the" standard Python
> compiler and CPython will be relegated to "merely" the reference
> implementation.

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.

ChrisA

[Steven D'Aprano]

On Thu, 27 Sep 2012 15:37:35 +1000, Chris Angelico wrote:

> On Thu, Sep 27, 2012 at 10:44 AM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:

>> While PyPy is still a work in progress, and is not anywhere near as
>> mature as (say) gcc or clang, it should be considered production-ready.
>
> 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



--
Steven

[Chris Angelico]

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

ChrisA

[Steven D'Aprano]

On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote:

> Hi all,
>
> I though this might be of interest.
>
> http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-
python


And a response:

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



--
Steven

[Serhiy Storchaka]

On 27.09.12 09:08, Chris Angelico wrote:
> LAMP usually means PHP these days. There's a lot of that around.

And Cyrillic Р means Ruby. :-P

[Steven D'Aprano]

On Wed, 26 Sep 2012 08:45:30 -0700, wxjmfauth wrote:

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



--
Steven

[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

--
Regards
Alex

[Devin Jeanpierre]

Summary of that article:

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

-- Devin

[Serhiy Storchaka]

On 27.09.12 12:33, Steven D'Aprano wrote:
> 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.

[Grant Edwards]

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!"

--
Grant Edwards grant.b.edwards Yow! Did something bad
at happen or am I in a
gmail.com drive-in movie??

[Steven D'Aprano]

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.



--
Steven

[Chris Angelico]

On Thu, Sep 27, 2012 at 11:59 PM, Grant Edwards <inv...@invalid.invalid> wrote:
> On 2012-09-27, Chris Angelico <ros...@gmail.com> wrote:
>> On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano <steve+comp....@pearwood.info> wrote:
>>
>>> 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.
>
> 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

[Ian Kelly]

On Thu, Sep 27, 2012 at 4:43 AM, Alex Strickland <ss...@mweb.co.za> wrote:
> 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.

[Mark Lawrence]

On 27/09/2012 13:46, Serhiy Storchaka wrote:
> On 27.09.12 12:33, Steven D'Aprano wrote:

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

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

--
Cheers.

Mark Lawrence.

[Devin Jeanpierre]

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

<steve+comp....@pearwood.info> wrote:
> On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote:
>
>> On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano
>> <steve+comp....@pearwood.info> 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!"
>
> 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

[Mark Lawrence]

On 27/09/2012 17:16, Devin Jeanpierre wrote:
> On Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano

> <steve+comp....@pearwood.info> wrote:
>> On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote:
>>
>>> On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano
>>> <steve+comp....@pearwood.info> 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!"
>>
>> 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?

--
Cheers.

Mark Lawrence.