myths about python 3

[Terry Reedy]

Carl Banks wrote:
But if it were sanctioned ... ? We *are* pretty magnanimous ;-)

I think it foolish to speculate in the absence of specifics. If some
people wanted to coninue bug-fix maintainance of 2.7 after the main
group of developers is done with it, in 5 years, then no new name is
needed. If some people wanted to backport additional 3.x features, while
still keeping the old, obsolete stuff around, then '2.8' would be
appropriate. If some people wanted to add a collection of incompatible
new features, perhaps some that Guido has rejected for 'Python', so that
they were producing a real fork, then a new name should be used.

I consider the first option possible, assuming that significant bugs
still remain in 5 years. The second seems more dubious, as the
developers have already backported most of what they thought sensible.
The third has always been possible, and has been done, and there would
be nothing really special about using 2.7 as a base.

Terry Jan Reedy

 

[Mensanator]

What?!?  Drat!!!  Guess I'll have to learn Lisp...  

Irresisible? Ha! The chicks will think you have a harelip.

 

[Gib Bogle]

What?!? Drat!!! Guess I'll have to learn Lisp...

~Ethan~

Learn to say this fast, you'll impress the hell out of them:

Chaps with chapped lips lisp.

 

[Steven D'Aprano]

Perhaps Steven could tell you about a lovely Australian meaning for the
word “dateâ€.

This is a family list, so perhaps I shouldn't.

In Australia slang, "date" is short for "date hole", which is the part of
the anatomy which is also known as "the [one] brown eye". In parts of the
US, it is also known as the "corn hole", and in Cockney rhyming slang it
is a jam role.

I trust I don't need to be any more explicit...

 

[Steve Holden]

Perhaps Steven could tell you about a lovely Australian meaning for the
word “dateâ€.

This is a family list, so perhaps I shouldn't.

In Australia slang, "date" is short for "date hole", which is the part of
the anatomy which is also known as "the [one] brown eye". In parts of the
US, it is also known as the "corn hole", and in Cockney rhyming slang it
is a jam role.

I trust I don't need to be any more explicit...

My God, and I just nominated you for membership of the PSF.

Trust an Australian to descend to normally unplumbed depths (pun
intended) the very second you stake your reputation on them. I guess
that means I know my place ...

there-goes-my-american-citizenship-ly y'rs - steve

 

[alex23]

This statement was to counter the 'myth' that US was only targeted at
2.x when the current situation is quite the opposite.

Not so much 'myth' as 'outdated information', they were very clear
that 2.x was the initial target.

In particular, several people said that the speed/space traceoff
should be optional, and that compilation 'without llvm' should really
be without, not just with llvm present but disabled. Instead of arguing,
Colin went ahead and patched the build process to make it be this way.

Ah, that's excellent. The impression being given off is that it's a
total replacement.

I have no idea. It will have to improve its speedup more before
adoption. I will not be surprised if that happens.

It's not so much about being surprised or not, it's wanting actual
evidence and not just claims, and moreso _extensive real world usage_
before it's integrated. This seems far more intimate a change than
adding a module to the stdlib, I expect it to have at _least_ the
evaluation time & vague consensus of approval expected of those.

US is not a new or separate interpreter. It will be an optional jit
replacement for one component of CPython, the eval loop. All the code
for builting functions, types, and modules will be untouched, as will
their big O performance characteristics.

As long as there aren't any related decreases in performance in other
areas, I'll be happy.

If you can still have a binary free of the traceoff, why would you care?

Well, I didn't know I could, so now I don't quite as much

They claim they have pretty well fixed that. They know that complete
Windows support, including 64 bit versions, is a necessity.

Maybe I'll be a lot more convinced after the Q4 report.

The 'incomplete' Windows support may not be as big an issue as I
thought, it seems to refer to a lack of support for older Windows
versions rather than an incomplete implementation on the supported
ones.

Cheers, Terry, this addressed a lot of my concerns, although I'm still
keen to see more facts & real-world usage over custom-crafted
benchmarks and enthusiastic claims.

 

[Steven D'Aprano]

Perl 6, on the other hand, is still fantasyware a decade after its
announcement. It is, for the most part, THE canonical example of the
wrong way to conduct a development effort.

Out of curiosity, and completely off-topic, why has Perl 6 gone so badly?

 

[geremy condra]

Out of curiosity, and completely off-topic, why has Perl 6 gone so badly?

Too much like Perl.

Geremy Condra

 

[alex23]

Too much like Perl.

I was going to suggest that it's probably due to the multitude of ways
to it could be done

 

[Neil Hodgson]

Looks to me like the problem with Perl 6 was that it was too
ambitious, wanting to fix all perceived problems with the language.
Python 3 is much more limited in scope: at its core its Python with
Unicode fixed and old junk removed.

Neil

 

[Martin v. Loewis]

Python has had

previous major changes in the past (e.g. 1.5 to 2.0 and 2.1 to 2.2) and
hardly anyone made a complaint.

I think this is actually false for the switch from 1.5 to 2.0. People
complained a lot, and announced that they won't switch to Python 2 in
any foreseeable future, and indeed, they stayed with Python 1.5.2 for
several years after Python 2 was released.

Of course, the Python user base was much smaller then than it is now,
so the absolute number of complainers surely was never as high is it
is now. Only when Python 4 gets released, even more people will complain
and announce that Python 4 has failed and that they stay with Python
3.8 forever.

Regards,
Martin

 

[Martin v. Loewis]

Well, I'd consider that an official release. Note that I didn't claim

there was no hope PSF wouldn't change it's mind on 2.8.

I'd like to point out that the PSF formally doesn't have any say in
this.

Instead, releases are created by the release manager, who gets appointed
by Guido van Rossum. Those two listen primarily to the opinions of the
fellow committers (which may or may not happen to be PSF members as
well).

Regardless of how magnaminous the people of PSF are, the unfortunate
reality is that trademark owners are forced by the law to be
"particularly petty". PSF's IP lawyer will advise not to allow
unsanctioned fork of Python 2.7 to call itself Python 2.8.

However, calling it "Passive Python", or "John Smith Python", for
example, would certainly be fine. Calling something "Python 2.8"
may not be unreasonable, also "Python 2.9", but surely "Python 2.10"
will hit strong objections (GvR always announced that there will
never be a two-digit minor release number).

Regards,
Martin

 

[Martin v. Loewis]

Why do I feel like there's less of an onus on Unladen Swallow to

_actually prove itself in substantial real world usage_ before
integration into CPython than there is on even the smallest of modules
for inclusion in the standard library?

Because it's a VM change, not an end-user change. VM changes can be
reviewed and evaluated by core developers, without requiring necessarily
feedback from end users (although end users can and do certainly
evaluate VM changes themselves also and provide feedback).

For library changes, it's more difficult to evaluate them, because
you not only need to find out whether the change is correct, but also
whether it is useful.

Are we really expected to just ditch everything we know about
CPython's performance characteristics just for some questionable and
possibly uneven gains?

That's the point of writing a PEP. Provide feedback to the PEP authors,
and ask them to incorporate your objections into the PEP in case they
forget. Then, when the PEP is about to be approved, that feedback
gets taken into consideration.

Posting in the 665th message on a Usenet thread is unlikely to have any
effect on the PEP process, though.

I've been a big supporter of Py3 from the beginning, but this repeated
claim of US becoming the mainline interpreter for 3.x pretty much
kills dead a lot of my interest.

It's not a claim, it's a PEP. Not being interested in the PEP process
is your choice, of course, but you shouldn't complain afterwards that
your opinion wasn't considered if you didn't actually voice it
appropriately.

Regards,
Martin

 

[Grant Edwards]

Looks to me like the problem with Perl 6 was that it was too
ambitious, wanting to fix all perceived problems with the
language.

I thought Python was Perl with all the perceived problems fixed.

 

[Antoine Pitrou]

Le Fri, 29 Jan 2010 13:16:11 +1100, Ben Finney a écrit :

I think the reason “date†was initially used is because dates are most
familiar to us as fleshy, dark brown, wrinkled, compressed points.

My interests in etymology and scatology unite here.

Ah, I suppose it explains the strange ASCII art drawing in your signature
then?

(Here)
|
|
v

 

[Anssi Saari]

'Stable Debian' has a long tradition of being late and outdated on arrival.
That doesn't mean you can't use existing Debian packages on it.

Yes, but that's beside the point. No released version of Debian ships
with Python3 or even 2.6.

Oh, and RHEL5 and CentOS5 ship with 2.4.

 

[Anssi Saari]

This latter statement is false, Fedora 11 and 12 come with python 2.6.

How does your mention of one distro counter that claim? Personally,
I'd like to see a study of what version of Python ships with what
Linux distribution. Say, include the top 100 distros from
distrowatch.com? I think there may a surprising number of distros that
ship with no version of Python what so ever.

 

[Benjamin Kaplan]

How does your mention of one distro counter that claim? Personally,
I'd like to see a study of what version of Python ships with what
Linux distribution. Say, include the top 100 distros from
distrowatch.com? I think there may a surprising number of distros that
ship with no version of Python what so ever.
--

Just from a quick look, 6 of the top 10 distros on distrowatch have
Python 2.6 including all of the top 4.

 

[Eric_Dexter]

Myths about Python 3:

1.  Python 3 is supported by major Linux distributions.

        FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

2.  Python 3 is supported by multiple Python implementations.

        FALSE - Only CPython supports 3.x.  Iron Python, Unladen Swallow,
        PyPy, and Jython have all stayed with 2.x versions of Python.

3.  Python 3 is supported by most 3rd party Python packages.

        FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

Arguably, Python 3 has been rejected by the market.  Instead, there's
now Python 2.6, Python 2.7, and Python 2.8.  Python 3 has turned into
a debacle like Perl 6, now 10 years old.

That's the reality, Python 3 fanboys.

                                John Nagle

I am seeing alot of bleeding edge linux distro's with 2.5 and 2.6 I
would perfer they stayed with 2.4 or 2.5 ..
or if there is a version that I can come up with a convincing cross-
platform os.startfile I would want to use
a vmware version of that linux.
_______________________________________
http://dextracker.blogspot.com/

 

[Carl Banks]

I'd like to point out that the PSF formally doesn't have any say in
this.

Doesn't PSF own the Python trademark? Then it has to have a say, not
over whether someone can fork the project or make another official
release, but over whether they can do so and still call it Python.


Carl Banks