f



Why Python 4.0 won't be like Python 3.0

A blog from Nick Coghlan 
http://www.curiousefficiency.org/posts/2014/08/python-4000.html that 
should help put a few minds to rest.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

0
Mark
8/17/2014 12:37:02 PM
comp.lang.python 77058 articles. 6 followers. Post Follow

20 Replies
679 Views

Similar Articles

[PageSpeed] 33

On 2014-08-17, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> A blog from Nick Coghlan 
> http://www.curiousefficiency.org/posts/2014/08/python-4000.html that 
> should help put a few minds to rest.

I agree with the comments that the appellation for "simply the next
version after 3.9" should be 3.10 and not 4.0.  Everybody I know
considers SW versions numbers to be dot-separated tuples, not 
floating point numbers.  

To all of us out here in user-land a change in the first value in the
version tuple means breakage and incompatibilities. And when the
second value is "0", you avoid it until some other sucker has found
the bugs and a few more minor releases have come out.

I don't think one (or several) blog posts is going to change the
perceptions and expectations that have been coditioned into us by
decades of experience with x.0 versions of countless software
packages. If it's just another in a a series of incremental "bug fix
and minor enhancements without breaking backwards incompatibility"
releases, you simply do not call it vers x.0.

-- 
Grant Edwards               grant.b.edwards        Yow! Bo Derek ruined
                                  at               my life!
                              gmail.com            
0
Grant
8/18/2014 1:01:01 AM
On Tue, Aug 19, 2014 at 12:51 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> I agree with the comments that the appellation for "simply the next
> version after 3.9" should be 3.10 and not 4.0.  Everybody I know
> considers SW versions numbers to be dot-separated tuples, not
> floating point numbers.
>

Agreed. However, by the time 3.9 comes out, there'll have been all
those years of changes. "The version after 3.9" would be a good time
to remove stuff that's been deprecated since 3.3 or 3.6 or whatever;
technically, that's breaking backward compat (hence 4.0 rather than
3.10), but in effect, it's no more breakage than a minor release would
give you (since you should have stopped using deprecated APIs several
versions ago). So there's still value in going to 4.0 around about ten
versions after 3.0; but it doesn't necessarily have to happen exactly
then.

ChrisA
0
Chris
8/18/2014 3:03:13 PM
"Grant Edwards" <invalid@invalid.invalid> wrote:

> To all of us out here in user-land a change in the first value in the
> version tuple means breakage and incompatibilities. And when the
> second value is "0", you avoid it until some other sucker has found
> the bugs and a few more minor releases have come out.

"Three shall be the number thou shalt count, and the number of the 
counting shall be three, no more, no less. .."
  https://www.youtube.com/watch?v=xOrgLj9lOwk   (1:30)

Or lets make the version asymptotically grow towards 4.
Any sensible function for that?

--gv
0
ElChino
8/18/2014 5:00:19 PM
On 08/18/2014 07:51 AM, Grant Edwards wrote:
>
> To all of us out here in user-land a change in the first value in the
> version tuple means breakage and incompatibilities. And when the
> second value is "0", you avoid it until some other sucker has found
> the bugs and a few more minor releases have come out.

Even our own 3.0 was like that.


> I don't think one (or several) blog posts is going to change the
> perceptions and expectations that have been coditioned into us by
> decades of experience with x.0 versions of countless software
> packages. If it's just another in a a series of incremental "bug fix
> and minor enhancements without breaking backwards incompatibility"
> releases, you simply do not call it vers x.0.

Yup.

--
~Ethan~
0
Ethan
8/18/2014 5:14:34 PM
On 08/18/2014 10:00 AM, ElChino wrote:
> "Grant Edwards" <invalid@invalid.invalid> wrote:
>
>> To all of us out here in user-land a change in the first value in the
>> version tuple means breakage and incompatibilities. And when the
>> second value is "0", you avoid it until some other sucker has found
>> the bugs and a few more minor releases have come out.
>
> "Three shall be the number thou shalt count, and the number of the counting shall be three, no more, no less. .."
>   https://www.youtube.com/watch?v=xOrgLj9lOwk   (1:30)

Right.  5.0 it is, then.

--
~Ethan~
0
Ethan
8/18/2014 5:15:48 PM
On 2014-08-18, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 08/18/2014 07:51 AM, Grant Edwards wrote:
>>
>> To all of us out here in user-land a change in the first value in the
>> version tuple means breakage and incompatibilities. And when the
>> second value is "0", you avoid it until some other sucker has found
>> the bugs and a few more minor releases have come out.
>
> Even our own 3.0 was like that.

So was 2.0, only it wasn't quite as distruptive as 3.0.

Don't get me started on the RedHat [5678].0 OS releases from back in
the day...

-- 
Grant 
0
Grant
8/18/2014 9:09:49 PM
On 8/18/2014 2:09 PM, Grant Edwards wrote:
> On 2014-08-18, Ethan Furman <ethan@stoneleaf.us> wrote:
>> On 08/18/2014 07:51 AM, Grant Edwards wrote:
>>>
>>> To all of us out here in user-land a change in the first value in the
>>> version tuple means breakage and incompatibilities. And when the
>>> second value is "0", you avoid it until some other sucker has found
>>> the bugs and a few more minor releases have come out.
>>
>> Even our own 3.0 was like that.
>
> So was 2.0, only it wasn't quite as distruptive as 3.0.

As I recall, 2.0 _was_ 1.6.

Emile

0
Emile
8/18/2014 9:45:11 PM
Grant Edwards <invalid@invalid.invalid> writes:

> I agree with the comments that the appellation for "simply the next
> version after 3.9" should be 3.10 and not 4.0. Everybody I know
> considers SW versions numbers to be dot-separated tuples, not floating
> point numbers.

This consensus is sometimes termed “semantic versioning”, that is,
giving semantic meaning to the structural elements of a version string
<URL:http://semver.org/>.

I'm glad someone has taken the time to codify that sensible and useful
de-facto standard for version strings.

> I don't think one (or several) blog posts is going to change the
> perceptions and expectations that have been coditioned into us by
> decades of experience with x.0 versions of countless software
> packages. If it's just another in a a series of incremental "bug fix
> and minor enhancements without breaking backwards incompatibility"
> releases, you simply do not call it vers x.0.

Agreed. The convention is well established and rogues deviate from it at
the peril of unnecessary confusion.

-- 
 \     “Guaranteed to work throughout its useful life.” —packaging for |
  `\                                          clockwork toy, Hong Kong |
_o__)                                                                  |
Ben Finney

0
Ben
8/18/2014 10:27:48 PM
On Tue, Aug 19, 2014 at 3:00 AM, ElChino <elchino@cnn.cn> wrote:
> Or lets make the version asymptotically grow towards 4.
> Any sensible function for that?

Easy! We just keep on adding parts.

3.7, 3.8, 3.9, 3.9.9, 3.9.9.9, 3.9.9.9.9, 3.9.9.9.9.9...

ChrisA
0
Chris
8/18/2014 11:46:42 PM
On Tue, Aug 19, 2014 at 10:05 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I consider versions to be *strings*. They include non-numeric components
> such as "a", "b", "rc", so they aren't numbers. They're certainly not
> floating point numbers, since they have a variable number of decimal
> points. Although there is at least one unofficial standard for interpreting
> version numbers (semantic versioning), the most popular by far is "whatever
> I mean by it today" and the only reasonable interpretation of an arbitrary
> software package's version "number" is as free-form text.
>
> Given two version numbers for the same arbitrary package, X and Y, just
> about the only thing you can be sure of is that if X < Y, Y is *probably*
> newer.

Let's say "version identifiers". The point of schemes like semver.org
is to make it possible to define the "X < Y" inequality between two
such identifiers. (There are similar schemes, such as that used by
Debian's package management. They're often broadly compatible.)

> Or Java 5, 6, 7, 8.
>
> http://en.wikipedia.org/wiki/Java_version_history

Are they major versions, or 1.5, 1.6, 1.7, 1.8? Or both?

> Or Firefox.
>
> https://support.mozilla.org/en-US/questions/956361
>
> (I believe that Firefox is now up to version 31, with version 32 due at
> 3:00pm and 33 due at 5:30pm.)

So true.

> And not a Mac user either, I imagine, since Mac OS introduces major backward
> incompatible changes to point releases. Mac OS version X tends to prefer
> version *names* rather than numbers:
>
> http://en.wikipedia.org/wiki/History_of_OS_X
>
> which Debian-based Linux distros also tend to follow.

With Debian distros, there is a version number as well as the name -
Wheezy (current stable) is Debian 7, currently showing 7.5, and the
previous version (Squeeze) is Debian 6. This more-or-less follows the
standard concept of major versions, as it's at the point of a new
release that breaking changes will be made.

There's a broad expectation in a lot of communities that the basic
"major.minor.rev" scheme will be followed. It's definitely not
universal, but it's the most popular convention by far (unless you
count "version numbers don't mean anything" as a convention).

ChrisA
0
Chris
8/19/2014 12:30:20 AM
--001a11c1c2de6e20940500f0d65a
Content-Type: text/plain; charset=UTF-8

On 19 August 2014 00:51, Grant Edwards <invalid@invalid.invalid> wrote:

> On 2014-08-17, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> > A blog from Nick Coghlan
> > http://www.curiousefficiency.org/posts/2014/08/python-4000.html that
> > should help put a few minds to rest.
>
> I agree with the comments that the appellation for "simply the next
> version after 3.9" should be 3.10 and not 4.0.  Everybody I know
> considers SW versions numbers to be dot-separated tuples, not
> floating point numbers.
>
> To all of us out here in user-land a change in the first value in the
> version tuple means breakage and incompatibilities. And when the
> second value is "0", you avoid it until some other sucker has found
> the bugs and a few more minor releases have come out.
>

 No. A major version increase *may* introduce breakage and
incompatibilities. It does not mean that it *has* to introduce breakage and
incompatibilities. If the major version increase is documented as "just
being the next version" then there's no reason to avoid it - unless your
policy is "wait for the first patch release" i.e. never take major.minor.0
but always wait for major.minor.1.

What is more important is that minor and patch version increases should
avoid introducing breakage and incompatibilities wherever possible
(security fixes are one reason to allow incompatibility in a minor release).

BTW I agree with the idea that 4.0 would be an appropriate time to remove
anything that has been deprecated for the requisite number of versions.

Tim Delaney

--001a11c1c2de6e20940500f0d65a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
9 August 2014 00:51, Grant Edwards <span dir=3D"ltr">&lt;<a href=3D"mailto:=
invalid@invalid.invalid" target=3D"_blank">invalid@invalid.invalid</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"">On 2014-08-17, Mark Lawrence &lt;<a href=
=3D"mailto:breamoreboy@yahoo.co.uk">breamoreboy@yahoo.co.uk</a>&gt; wrote:<=
br>

&gt; A blog from Nick Coghlan<br>
&gt; <a href=3D"http://www.curiousefficiency.org/posts/2014/08/python-4000.=
html" target=3D"_blank">http://www.curiousefficiency.org/posts/2014/08/pyth=
on-4000.html</a> that<br>
&gt; should help put a few minds to rest.<br>
<br>
</div>I agree with the comments that the appellation for &quot;simply the n=
ext<br>
version after 3.9&quot; should be 3.10 and not 4.0.=C2=A0 Everybody I know<=
br>
considers SW versions numbers to be dot-separated tuples, not<br>
floating point numbers.<br>
<br>
To all of us out here in user-land a change in the first value in the<br>
version tuple means breakage and incompatibilities. And when the<br>
second value is &quot;0&quot;, you avoid it until some other sucker has fou=
nd<br>
the bugs and a few more minor releases have come out.<br></blockquote><div>=
<br></div><div>=C2=A0No. A major version increase *may* introduce breakage =
and incompatibilities. It does not mean that it *has* to introduce breakage=
 and incompatibilities. If the major version increase is documented as &quo=
t;just being the next version&quot; then there&#39;s no reason to avoid it =
- unless your policy is &quot;wait for the first patch release&quot; i.e. n=
ever take major.minor.0 but always wait for major.minor.1.</div>
<div><br></div><div>What is more important is that minor and patch version =
increases should avoid introducing breakage and incompatibilities wherever =
possible (security fixes are one reason to allow incompatibility in a minor=
 release).</div>
<div><br></div><div>BTW I agree with the idea that 4.0 would be an appropri=
ate time to remove anything that has been deprecated for the requisite numb=
er of versions.<br></div><div><br></div><div>Tim Delaney</div></div></div>
</div>

--001a11c1c2de6e20940500f0d65a--
0
Tim
8/19/2014 12:47:53 AM
Ben Finney wrote:

> Grant Edwards <invalid@invalid.invalid> writes:
> 
>> I agree with the comments that the appellation for "simply the next
>> version after 3.9" should be 3.10 and not 4.0. Everybody I know
>> considers SW versions numbers to be dot-separated tuples, not floating
>> point numbers.
> 
> This consensus is sometimes termed “semantic versioning”, that is,
> giving semantic meaning to the structural elements of a version string
> <URL:http://semver.org/>.
> 
> I'm glad someone has taken the time to codify that sensible and useful
> de-facto standard for version strings.
> 
>> I don't think one (or several) blog posts is going to change the
>> perceptions and expectations that have been coditioned into us by
>> decades of experience with x.0 versions of countless software
>> packages. If it's just another in a a series of incremental "bug fix
>> and minor enhancements without breaking backwards incompatibility"
>> releases, you simply do not call it vers x.0.
> 
> Agreed. The convention is well established 

Only if you ignore the vast majority of software which does not follow that
convention. Having *any* semantics to version numbers at all, apart
from "bump the version number when you feel like it", is the exception
rather than the rule. Probably the most common version numbering system
is "the date I last remembered to update the version number", or a simple
incrementing counter. (It's a version *number*, not a version tuple.)

It is amazing how well-established a convention can appear if you ignore the
exceptions to it and consider only a sufficiently narrow niche, like "some
of the FOSS software I'm familiar with".


> and rogues deviate from it at the peril of unnecessary confusion.

Rogues like Python, the Linux kernel, Oracle, Mozilla, Haskell, ...

Well, okay, Oracle are rogues. But not because of their version numbering.


I find it amusing that Haskell uses a versioning number scheme that uses two
dot-separated major versions specifically to combat the emotional reaction
to major-version changes exhibited in this thread by Grant. With Haskell,
changing from (say) 0.6.3.2 -> 0.7.0.0 is a major API-breaking upgrade, but
it avoids the emotional reaction of having to go from 6.3.2 -> 7.0.0.

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

Haskell also explicitly prohibits the useful practice of including version
tags like "a", "b", "rc" *because some tools couldn't sort them correctly*.
(This reminds me of those who advocate spaces over tabs, because some tools
can't deal with tabs correctly.) Rather than fix the tools, the Haskell
community removed non-numeric tags from the specification.

On the other hand, Oracle and Sun before them take the attitude that a jump
in Java's version number from 5 to 6 to 7 are only minor release changes,
and the Java community is quite happy to agree.



-- 
Steven

0
Steven
8/19/2014 1:00:16 AM
Grant Edwards wrote:

> On 2014-08-17, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> A blog from Nick Coghlan
>> http://www.curiousefficiency.org/posts/2014/08/python-4000.html that
>> should help put a few minds to rest.
> 
> I agree with the comments that the appellation for "simply the next
> version after 3.9" should be 3.10 and not 4.0.  Everybody I know
> considers SW versions numbers to be dot-separated tuples, not
> floating point numbers.

I consider versions to be *strings*. They include non-numeric components
such as "a", "b", "rc", so they aren't numbers. They're certainly not
floating point numbers, since they have a variable number of decimal
points. Although there is at least one unofficial standard for interpreting
version numbers (semantic versioning), the most popular by far is "whatever
I mean by it today" and the only reasonable interpretation of an arbitrary
software package's version "number" is as free-form text.

Given two version numbers for the same arbitrary package, X and Y, just
about the only thing you can be sure of is that if X < Y, Y is *probably*
newer.

 
> To all of us out here in user-land a change in the first value in the
> version tuple means breakage and incompatibilities.

*All* of us?

So... you're not a user of the Linux kernel?

http://www.linuxplanet.com/news/goodbye-linux-2.6-hello-linux-3.0.html

Or Java 5, 6, 7, 8.

http://en.wikipedia.org/wiki/Java_version_history

Or Firefox.

https://support.mozilla.org/en-US/questions/956361

(I believe that Firefox is now up to version 31, with version 32 due at
3:00pm and 33 due at 5:30pm.)

And not a Mac user either, I imagine, since Mac OS introduces major backward
incompatible changes to point releases. Mac OS version X tends to prefer
version *names* rather than numbers:

http://en.wikipedia.org/wiki/History_of_OS_X

which Debian-based Linux distros also tend to follow.

Or for that matter, not a Python user either:

https://docs.python.org/dev/whatsnew/2.0.html

Version 4.0, when it comes out, will merely be a return to past practices in
Python-land, which are quite similar to practices in many major software
packages. Version 3.0 was the anomaly.



-- 
Steven

0
Steven
8/19/2014 1:01:01 AM
Grant Edwards wrote:

> On 2014-08-18, Ethan Furman <ethan@stoneleaf.us> wrote:
>> On 08/18/2014 07:51 AM, Grant Edwards wrote:
>>>
>>> To all of us out here in user-land a change in the first value in the
>>> version tuple means breakage and incompatibilities. And when the
>>> second value is "0", you avoid it until some other sucker has found
>>> the bugs and a few more minor releases have come out.
>>
>> Even our own 3.0 was like that.
> 
> So was 2.0, only it wasn't quite as distruptive as 3.0.

How was it disruptive? It was as backward compatible to 1.5 as any point
release can be expected to be. There were syntax changes, but they added
new syntax, and didn't take anything away.

In my opinion, 2.6 was a bigger change than 2.0 from the perspective of
backwards compatibility. 2.6 finally made raising from strings an error.

# 2.4
py> raise "hello"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
hello

# 2.6
py> raise "hello"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: exceptions must be old-style classes or derived from
BaseException, not str

(I make no comment about the quality of 2.0 versus 2.0.1 :-)



-- 
Steven

0
Steven
8/19/2014 1:01:01 AM
On 2014-08-19, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Grant Edwards wrote:
>
>> On 2014-08-18, Ethan Furman <ethan@stoneleaf.us> wrote:
>>> On 08/18/2014 07:51 AM, Grant Edwards wrote:
>>>>
>>>> To all of us out here in user-land a change in the first value in the
>>>> version tuple means breakage and incompatibilities. And when the
>>>> second value is "0", you avoid it until some other sucker has found
>>>> the bugs and a few more minor releases have come out.
>>>
>>> Even our own 3.0 was like that.
>> 
>> So was 2.0, only it wasn't quite as distruptive as 3.0.
>
> How was it disruptive? It was as backward compatible to 1.5 as any point
> release can be expected to be. There were syntax changes, but they added
> new syntax, and didn't take anything away.
>
> In my opinion, 2.6 was a bigger change than 2.0 from the perspective of
> backwards compatibility. 2.6 finally made raising from strings an error.

I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff.  I do
remember delaying moving from 1.5.2 -> 2.0 until I really had to, but 
I don't remember why.

-- 
Grant Edwards               grant.b.edwards        Yow! Oh, I get it!!
                                  at               "The BEACH goes on", huh,
                              gmail.com            SONNY??
0
Grant
8/19/2014 2:27:35 PM
On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff.  I do
> remember delaying moving from 1.5.2 -> 2.0 until I really had to, but
> I don't remember why.

If you were a RedHat user during that timeframe, that might have
contributed to your decision to delay. I no longer remember the
details, but it was rather painful.

Skip

P.S. Grant, why is your email listed as invalid@invalid.invalid? Seems
kind of unfriendly.
0
Skip
8/19/2014 2:37:41 PM
On 2014-08-19, Skip Montanaro <skip@pobox.com> wrote:
> On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff.  I do
>> remember delaying moving from 1.5.2 -> 2.0 until I really had to, but
>> I don't remember why.
>
> If you were a RedHat user during that timeframe, that might have
> contributed to your decision to delay. I no longer remember the
> details, but it was rather painful.
>
> Skip
>
> P.S. Grant, why is your email listed as invalid@invalid.invalid? Seems
>      kind of unfriendly.

Many, many years ago it was an attept to reduce spam and to avoid
receiving copies of followups.  There used to be a fair number of
Usenet and mailing-list users who seemed to think that their followups
were so important that they would not only post it to the group (or
mail it to the mailing list), they would also send you a copy
directly.  I got tired of messing with procmail filters to try to
eliminate those, so I finally removed my e-mail address from the
headers.  If people want to e-mail me, my address is below.

-- 
Grant Edwards               grant.b.edwards        Yow! Vote for ME -- I'm
                                  at               well-tapered, half-cocked,
                              gmail.com            ill-conceived and
                                                   TAX-DEFERRED!
0
Grant
8/19/2014 2:51:12 PM
Skip Montanaro <skip@pobox.com> writes:

> On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff.  I do
>> remember delaying moving from 1.5.2 -> 2.0 until I really had to, but
>> I don't remember why.
>
> If you were a RedHat user during that timeframe, that might have
> contributed to your decision to delay. I no longer remember the
> details, but it was rather painful.

I vaguely remember holding off for a while until SWIG had 2.0 support,
or maybe Numeric lagged, or something, but that's getting pretty fuzzy.
There was definitely more there than, say, for 1.4 to 1.5.  It's hard to
believe that the Dubois/Hinsen/Hugunin article in Computers in Physics
(which was where I got my start with python) was a full 18 years ago.

Cheers,
Johann
0
Johann
8/19/2014 2:56:25 PM
Grant Edwards wrote:

> I do
> remember delaying moving from 1.5.2 -> 2.0 until I really had to, but
> I don't remember why.

I remember delaying moving from 1.5 until 2.3, but I remember why. Three
reasons:

(1) People are often like cats, and like cats, they are either curious and
inquisitive about anything new ("ooh, shiny! is it good to play with???")
or suspicious and fearful of anything new ("it's different, I don't like
it"). I happened to be going through a stage of my life closer to the
second than the first at the time.

(2) I was reluctant to install software by hand if it wasn't handled by my
system's package manager. I still am, but not as reluctant as I was back
then.

(3) I was still learning the language, and all the books I had on Python
covered 1.5.


-- 
Steven

0
Steven
8/19/2014 5:44:20 PM
Le dimanche 17 ao=FBt 2014 14:37:02 UTC+2, Mark Lawrence a =E9crit=A0:
> A blog from Nick Coghlan=20
>=20

At least one py dev, who has a correct understanding
and vision of what is Unicode or as it is supposed to
be.

My position: I'm on the side of the TeX unicode
engines and luckily it does match the platform
I'm using.

jmf
0
wxjmfauth
8/19/2014 7:04:58 PM
Reply:

Similar Artilces:

Movable Python 1.0.0 for Python 2.3 & 2.4
It's finally happened, `Movable Python <http://www.voidspace.org.uk/python/movpy/>`_ is finally released. Versions for Python 2.3 & 2.4 are available from `The Movable Python Shop <http://voidspace.tradebit.com/groups.php>`_. The cost is =A35 per distribution, payment by PayPal. =A31 from every distribution goes to support the development of `SPE <http://pythonide.stani.be/>`_, the Python IDE. This gives you free support (via the `Movable Python Mailing List <http://groups.google.com/group/movpy>`_), and access to updates, for a year. There is ...

Movable Python 1.0.0 for Python 2.3 & 2.4
It's finally happened, `Movable Python <http://www.voidspace.org.uk/python/movpy/>`_ is finally released. Versions for Python 2.3 & 2.4 are available from `The Movable Python Shop <http://voidspace.tradebit.com/groups.php>`_. The cost is =A35 per distribution, payment by PayPal. =A31 from every distribution goes to support the development of `SPE <http://pythonide.stani.be/>`_, the Python IDE. This gives you free support (via the `Movable Python Mailing List <http://groups.google.com/group/movpy>`_), and access to updates, for a year. There is a minor issue ...

[ANN] bento 0.0.4, a pythonic packaging solution for python softwares
Hi, I am pleased to announce the release 0.0.4 for Bento, a pythonic packaging solution for python softwares. Bento is an alternative to distutils/setuptools/distutils2 geared toward simplicity and hackability: http://cournape.github.com/Bento/ Download: http://github.com/cournape/Bento/archives/master Documentation: http://cournape.github.com/Bento/html This release is a significant milestone, as it is able to build two complex packages (numpy and scipy). The main new features are: - New hooks to modify, override compilation options on a per extension basis (e.g. buil...

3*x''+(10^-3)*x'+123*x=2*cos(3*t); x=x(t);initial conditions x(0)=0 and x'(0)=0
Hi everybody, I need to solve the Cauchy problem written in the title box ( I paste it here again ): 3*x''+(10^-3)*x'+123*x=2*cos(3*t); x=x(t);initial conditions x(0)=0 and x'(0)=0. I tried with Runge-Kutta method and it seems to work as the solution x(t) is the same that I can get solving the equation by myself. I need to know if it would be better another method (eventually multistep one) and why it would be better (please don't just tell me 'cause it's faster or so...I need to know the why too). As last thing I need to estimate the error committed with Runge...

[Python 3.3.0] Getting tkinter to work on Python 3
--047d7bf0d52ef12d7304d836299a Content-Type: text/plain; charset=ISO-8859-1 Hi. I'm having a problem trying to get this to work well. Basically, whenever I try to import tkinter, this is the issue that I have: >>> import tkinter Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python3.3/tkinter/__init__.py", line 40, in <module> import _tkinter # If this fails your Python may not be configured for Tk ImportError: No module named '_tkinter' I'm running Ubuntu. If...

Python 3.5 versus Python 3.0
Python 3.5 is still suffering from the same issues one can find in Python 3.0 . The problem? Unicode and the coding of characters. The problem #2? This willingness to not work correctly and properly. ...

Python 3.0 or Python 3000?
Is 'Python 3000' just a code name for version 3.0, or will it really be called that when it's released? [John Salerno] > Is 'Python 3000' just a code name for version 3.0, or will it really be > called that when it's released? The smart money is on changing the name to Ecstasy, to leverage marketing publicity from the hallucinogenic club drug of the same name. "class" will be renamed to "rave", and the license will be changed to prohibit use by people with bipolar disorder. Either that, or the name will be Python 3.0. On Sun, 9 Apr 2006 2...

ANN: Python cgkit v2.0.0alpha7 & Maya/Python 0.9.3
The seventh alpha release of cgkit2 and v0.9.3 of the Maya/Python package is available at http://cgkit.sourceforge.net What is it? ----------- The Python Computer Graphics Kit is an Open Source software package containing a collection of Python modules, plugins and utilities that are meant to be useful for any domain where you have to deal with 3D data of any kind, be it for visualization, creating photorealistic images, Virtual Reality or even games. Currently, the entire kit consists of the following parts: - The Python package "cgkit" that extends Python with 3...

ANN: Python cgkit v2.0.0alpha7 & Maya/Python 0.9.3
The seventh alpha release of cgkit2 and v0.9.3 of the Maya/Python package is available at http://cgkit.sourceforge.net What is it? ----------- The Python Computer Graphics Kit is an Open Source software package containing a collection of Python modules, plugins and utilities that are meant to be useful for any domain where you have to deal with 3D data of any kind, be it for visualization, creating photorealistic images, Virtual Reality or even games. Currently, the entire kit consists of the following parts: - The Python package "cgkit" that extends Python with 3...

python 3.4 use python-gcm can't import
i just from gcm import GCM then.... Traceback (most recent call last): File "C:/Users/frank/Desktop/SinyiAPI/SinyiAPI.py", line 7, in <module> from Model.Order import Order File "C:\Users\frank\Desktop\SinyiAPI\Model\Order.py", line 7, in <module> from gcm.gcm import GCM File "<frozen importlib._bootstrap>", line 2237, in _find_and_load File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 1191, in _load_unlocked File "<fro...

Pies v 2.0.0 released
Pies is a Python2 & 3 Compatibility layer with the philosophy that all code= should be Python3 code. Starting from this viewpoint means that when runni= ng on Python3 pies adds virtually no overhead. Instead of providing a bunch of custom methods (leading to Python code that= looks out of place on any version) pies aims to back port as many of the P= ython3 API calls, imports, and objects to Python2 - Relying on special synt= ax only when absolutely necessary. ...

Why does python break IEEE 754 for 1.0/0.0 and 0.0/0.0?
I've read over and over that Python leaves floating point issues up to the underlying platform. This seems to be largely true, but not always. My underlying platform (IA32 Linux) correctly handles 1.0/0.0 and 0.0/0.0 according to the IEEE 754 standard, but Python goes out of its way to do the wrong thing. 1/0 is defined by the standard as +Inf and 0/0 is NaN. That's what my platform does for programs written in C. Python apparently checks for division by zero and throws and exception rather than returning the correct value calculated by the underlying platform. Is there any way...

[ace-users] ACE 5.4.0 won't compile after GCC upgrade (3.3.3 -> 3.4.3)
[Apologies if this shows up twice, there was a mailer error with my first attempt to post] Hi, I found the same problem reported recently on the mailing list ("compiling ACE under Fedora core 3", March 1st) but no resolution was reported there, so I thought I'd post a full description here. ACE VERSION: 5.4 HOST MACHINE and OPERATING SYSTEM: AIX 5.1 ...

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?
Does anynone have these available? I'd like to upgrade (hoping it doesn't break my Redhat install). If I upgrade, all my site-packages have to be reinstalled to the new site-packages directory right? Scott ...

Web resources about - Why Python 4.0 won't be like Python 3.0 - comp.lang.python

Resources last updated: 1/26/2016 2:49:16 PM