Here's something interesting: sympy crashes in Python 2.6 (Windows)

[Mensanator]

Beacuse in 2.6, Python apparently has fixed a discrepency that existed
in previous versions.

In the IDLE that comes with 2.5, typing "as", to wit "import random as
ran",
the words "import" and "as" highlight in red, so you can't use them as
variable
names or you'll get a syntax error.

Ah, but you CAN use "as" for a variable: "for as in xrange(10): print
as"
works just fine, although it shouldn't.

Python 2.6 fixes this discrepency and now gives you a syntax error if
you
use "as" for a variable name.

The upshot is code (such as sympy) written prior to 2.6 can crash now
due
to this fix if said code inadverntently used what should have been a
reserved
word.

I was able to fix the code for this "as" problem, but not the one that
came after. I've reported this and interested parties can visit the
sympy
page and check Issue 1115.

 

[Guilherme Polo]

Beacuse in 2.6, Python apparently has fixed a discrepency that existed
in previous versions.

In the IDLE that comes with 2.5, typing "as", to wit "import random as
ran",
the words "import" and "as" highlight in red, so you can't use them as
variable
names or you'll get a syntax error.

Ah, but you CAN use "as" for a variable: "for as in xrange(10): print
as"
works just fine, although it shouldn't.

Python 2.6 fixes this discrepency and now gives you a syntax error if
you
use "as" for a variable name.

You should have noticed the warning you received in python 2.5 when
using "as" as a name.

 

[Mensanator]

You should have noticed the warning you received in python 2.5 when
using "as" as a name.

I'm not the one who wrote sympy, so I guess I'm not
the only one who didn't notice it.

If it's a well known problem, then sorry I wasted
your time.

The sympy people thought it was important and,
as not everyone uses sympy, I thought I was
performing a service to the community mentioning
it here.

Sheesh.

 

[Fredrik Lundh]

I'm not the one who wrote sympy, so I guess I'm not
the only one who didn't notice it.

If it's a well known problem, then sorry I wasted
your time.

Given that 2.5 explicitly warns about this specific change:
<stdin>:1: Warning: 'as' will become a reserved keyword in Python 2.6

it's an unknown issue only for people who has 1) never used their code
under 2.5, or 2) never looks at the output produced by their programs.

The PEP-5 process guarantees that "users will have at least a year to
test their programs and migrate them from use of the deprecated
construct to the alternative one," and Python 2.5 was released *two*
years ago.

So it sure looks like the SimPy folks ignored the established process.
Why they've done that is probably a more interesting issue than the
change itself.

</F>

 

[Mensanator]

Given that 2.5 explicitly warns about this specific change:

<stdin>:1: Warning: 'as' will become a reserved keyword in Python 2.6

Uh...how come _I_ don't see that?

In IDLE, I get:

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32

IDLE 1.2SyntaxError: invalid syntax


When inside a script, I get:

as = 1
print as

1



it's an unknown issue only for people who has 1) never used their code
under 2.5, or 2) never looks at the output produced by their programs.

The PEP-5 process guarantees that "users will have at least a year to
test their programs and migrate them from use of the deprecated
construct to the alternative one," and Python 2.5 was released *two*
years ago.

So it sure looks like the SimPy folks ignored the established process.
Why they've done that is probably a more interesting issue than the
change itself.

Is there something wrong with my (and Sympy's) version
of Python that we don't see these warnings?

 

[Robert Kern]

Given that 2.5 explicitly warns about this specific change:

<stdin>:1: Warning: 'as' will become a reserved keyword in Python 2.6

it's an unknown issue only for people who has 1) never used their code
under 2.5, or 2) never looks at the output produced by their programs.

The PEP-5 process guarantees that "users will have at least a year to
test their programs and migrate them from use of the deprecated
construct to the alternative one," and Python 2.5 was released *two*
years ago.

So it sure looks like the SimPy folks ignored the established process.
Why they've done that is probably a more interesting issue than the
change itself.

No warnings show up when importing the offending module:

Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
So what could be suppressing the warning?

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Fredrik Lundh]

No warnings show up when importing the offending module:

Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
So what could be suppressing the warning?

a bug in Python 2.5, it seems:

> more f1.py

as = 1
as = 2
as = 3

> python f1.py

f1.py:1: Warning: 'as' will become a reserved keyword in Python 2.6
f1.py:2: Warning: 'as' will become a reserved keyword in Python 2.6
f1.py:3: Warning: 'as' will become a reserved keyword in Python 2.6

> more f2.py

as = 1
import os
as = 3

> python f2.py

f2.py:1: Warning: 'as' will become a reserved keyword in Python 2.6

A quick look in parsetok.c reveals that it sets a "handling_import" flag
when it stumbles upon an "import" statement, a flag that's later used to
suppress the warning message. The bug is that the flag isn't reset
until the parser sees an ENDMARKER token (end of file), instead of when
it sees the next NEWLINE token.

(if someone wants to submit this to bugs.python.org, be my guest)

</F>

 

[Terry Reedy]

Robert Kern wrote:

(if someone wants to submit this to bugs.python.org, be my guest)

http://bugs.python.org/issue3936