[ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files
Bugs item #1200686, was opened at 2005-05-12 16:19
Message generated for change (Comment added) made by julien_sagnard
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: SyntaxError raised on win32 for correct files
Initial Comment:
Try to import the attached file (dt.py) on Windows with
Python 2.4 or 2.4.1 and you'll get a SyntaxError (the
file was written a long time ago, and worked perfectly
well on Python 2.1, 2.2 and 2.3.) The same does not
happen when importing the same module on Linux (tested
with 2.4 and 2.4.1). When the module imports fine
you'll get an ImportError (don't want to attach all
dependencies here) but the SyntaxError comes before that.
Also note that compiling the file with
compiler.compileFile("dt.py") generates a perfectly
good .pyc file that can be later imported just fine
(tested with 2.4 and 2.4.1 on Windows).
--
Comment By: Julien Sagnard (julien_sagnard)
Date: 2005-07-19 18:05
Message:
Logged In: YES
user_id=1181710
I have a similar problem with an other file (log.py).
On my computer ( Windows 2000 ) this 2 files ( log.py and
dt.py ) works with python 2.4 but raise a syntax error on
python 2.4.1 :
D:\dvt\tmp\bug2_4_1>python -c "import log"
Traceback (most recent call last):
File "", line 1, in ?
File "D:\dvt\tmp\bug2_4_1\log.py", line 356
w = 72
^
SyntaxError: invalid syntax
--
Comment By: Greg Chapman (glchapman)
Date: 2005-05-18 16:15
Message:
Logged In: YES
user_id=86307
I'm fairly sure this is caused by the bug described here:
www.python.org/sf/1175396
The module imports without syntax error on my Windows system
(with a patched codecs.py to work around the above bug).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files
Bugs item #1200686, was opened at 2005-05-12 16:19
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: SyntaxError raised on win32 for correct files
Initial Comment:
Try to import the attached file (dt.py) on Windows with
Python 2.4 or 2.4.1 and you'll get a SyntaxError (the
file was written a long time ago, and worked perfectly
well on Python 2.1, 2.2 and 2.3.) The same does not
happen when importing the same module on Linux (tested
with 2.4 and 2.4.1). When the module imports fine
you'll get an ImportError (don't want to attach all
dependencies here) but the SyntaxError comes before that.
Also note that compiling the file with
compiler.compileFile("dt.py") generates a perfectly
good .pyc file that can be later imported just fine
(tested with 2.4 and 2.4.1 on Windows).
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-07-19 18:19
Message:
Logged In: YES
user_id=89016
This bug should be fixed in the current CVS version. So, can
you retry with current CVS? As a workaround you might also
want to remove the PEP 263 coding declaration if you don't
have any special character in your file.
--
Comment By: Julien Sagnard (julien_sagnard)
Date: 2005-07-19 18:05
Message:
Logged In: YES
user_id=1181710
I have a similar problem with an other file (log.py).
On my computer ( Windows 2000 ) this 2 files ( log.py and
dt.py ) works with python 2.4 but raise a syntax error on
python 2.4.1 :
D:\dvt\tmp\bug2_4_1>python -c "import log"
Traceback (most recent call last):
File "", line 1, in ?
File "D:\dvt\tmp\bug2_4_1\log.py", line 356
w = 72
^
SyntaxError: invalid syntax
--
Comment By: Greg Chapman (glchapman)
Date: 2005-05-18 16:15
Message:
Logged In: YES
user_id=86307
I'm fairly sure this is caused by the bug described here:
www.python.org/sf/1175396
The module imports without syntax error on my Windows system
(with a patched codecs.py to work around the above bug).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 06:13
Message generated for change (Comment added) made by sjuranic
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
Comment By: Steve Juranich (sjuranic)
Date: 2005-07-19 10:22
Message:
Logged In: YES
user_id=1315245
FWIW, this same problem crops up when using Python & VTK
together (which also ships with its own version of expat).
bos's workaround will make things work, though.
--
Comment By: Bernhard Herzog (bernhard)
Date: 2005-03-29 11:11
Message:
Logged In: YES
user_id=2369
I ran into this problem as well on a debian GNU/Linux system
on x86 hardware. It occurs both with pygtk 2.4 and wxPython
2.5 both built against gtk 2.4.
bos' patch at least solves the immediate problem of the
segmentation fault. It may be a good idea to print a
warning message if some of the error codes cannot be
translated to strings, though.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-04 16:16
Message:
Logged In: YES
user_id=28380
With the GNU linker, you can pass in -Bstatic to force it to resolve the
symbols in the local shared library, instead of globally. This also works on
Irix. I don't know about other Unixes.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-02 03:35
Message:
Logged In: YES
user_id=6656
It's a nasty one, I'll give you that.
Fred, what do you think of bos's patch? It solves the immediate issue,
but I'm not sure it's a complete fix.
It seems to me that it would be better to resolve the expat symbols at
builf time, but I don't know how to arrange for that.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-01 23:09
Message:
Logged In: YES
user_id=28380
By the way, this is not an SGI-specific bug. This will bite any Unix system
with a modern sysv-style dynamic linker. The priority of this bug should be
higher, IMO.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-01 00:53
Message:
Logged In: YES
user_id=28380
I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.
It's not actually necessary to check the expat version; just see if
XML_ErrorString actually returns anything.
Here's the patch I use for this problem:
--- python/Modules/pyexpat.c2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
}
#endif
-#define MYCONST(name) -PyModule_AddStringConstant(errors_module, #name, -
(char*)XML_ErrorString(name))
+#define MYCONST(name) +{ +char *_v =
(char*)XML_ErrorString(name); +if (_v) +
PyModule_AddStringConstant(errors_module, #name, _v); +}
MYCONST(XML_ERROR_NO_MEMORY);
MYCONST(XML_ERROR_SYNTAX);
--
Comment By: Stephen Watson (kerofin)
Date: 20
[ python-Bugs-665336 ] win32 os.path.normpath not correct for leading slash cases
Bugs item #665336, was opened at 2003-01-09 22:42
Message generated for change (Comment added) made by gergan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan R.A. Deibel (sdeibel)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32 os.path.normpath not correct for leading slash cases
Initial Comment:
os.path.normpath on win32 misses two cases in its
duplicate slash
removal code that I believe should be dealt with:
c:\x\y\z
\\x\y\z
Both of these are returned unchanged.
I've attached an implementation that fixes these to
return the following, respectively:
c:\x\y\z
\x\y\z
I did see the other normpath bugs that were reported
and rejected
and think that the above isn't also a case of "garbage
in garbage out" but of course there's room for
interpretation.
I am a bit unsure about the UNC case since Posix
collapses only 3+ leading slashes to a single slash and
otherwise leaves up to two slashes. But in the context
of win32 the above seems to make more sense to me.
Thanks,
Stephan Deibel
Wing IDE Developer
Archaeopteryx Software
def normpath(path):
"""Normalize path, eliminating double slashes,
etc."""
path = path.replace("/", "\")
prefix, path = os.path.splitdrive(path)
if prefix == '':
max_leading = 2
else:
max_leading = 1
i = 0
while path[:1] == "\":
if i < max_leading:
prefix = prefix + "\"
i += 1
path = path[1:]
comps = path.split("\")
i = 0
while i < len(comps):
if comps[i] in ('.', ''):
del comps[i]
elif comps[i] == '..':
if i > 0 and comps[i-1] != '..':
del comps[i-1:i+1]
i -= 1
elif i == 0 and prefix.endswith("\"):
del comps[i]
else:
i += 1
else:
i += 1
# If the path is now empty, substitute '.'
if not prefix and not comps:
comps.append('.')
return prefix + "\".join(comps)
--
Comment By: gergan (gergan)
Date: 2005-07-19 18:50
Message:
Logged In: YES
user_id=1301159
I'm experiencing the same bug on linux with
Python 2.4.1 (#1, Jun 28 2005, 21:03:32)
[GCC 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)]
all the paths beginning with double slash are left unchanged
from os.path.normpath.
so expected behaviour would be (as stated in the documentation)
>>>os.path.normpath ("//usr/lib")
'/usr/lib'
the actual result is:
>>>os.path.normpath ("//usr/lib")
'//usr/lib'
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-19 21:25
Message:
Logged In: YES
user_id=752496
I've the following behaviour in 2.4b1:
>>> os.path.normpath(r"\x\y\z")
'\x\y\z'
>>> os.path.normpath(r"\x\y\z")
'\x\y\z'
>>> os.path.normpath(r"\x\y\z")
'\x\y\z'
which is ok to me, and
>>> os.path.normpath(r"\x\y\z")
'\\x\y\z'
which seems bad.
I'm setting this bug to the 2.4 group.
--
Comment By: Stephan R.A. Deibel (sdeibel)
Date: 2004-11-17 05:04
Message:
Logged In: YES
user_id=12608
Good god, notification email is munging the number of
backslashes inconsistently depending on quoting -- see the
sf bug entry in a browser to see the right thing. Sorry
about that!
--
Comment By: Stephan R.A. Deibel (sdeibel)
Date: 2004-11-17 05:00
Message:
Logged In: YES
user_id=12608
The c:\x\y\z case was broken up to 2.3.4 but appears fixed
in 2.4b2, as you noticed (it used to return "c:\\x\y\z"
and now returns "c:\x\y\z" as it
should).
However in 2.4b4 the \x\y\z case still returns
"\\x\y\z" (it
returns any number of leading backslashes unchanged, no
matter how
many are passed in):
>>> os.path.normpath(r"\x\y\z")
'\\x\y\z'
>>> os.path.normpath(r"\\x\y\z")
'\\\x\y\z'
I'm still fairly sure it should return "\x\y\z" instead
as the more appropriate
normalization of this kind of path on win32.
Hope that helps! Thanks for your work on clearing the bug list!
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-17 00:17
Message:
Logged In: YES
user_id=752496
Don't understand what you're proposing: in Py2.4b2 (Win2K
SP4) I got:
>>> os.path.normpath("c:\x\y\z")
'c:\x\y\z'
and that seems ok to me.
.Facundo
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-17 00:17
Message:
L
[ python-Bugs-665336 ] win32 os.path.normpath not correct for leading slash cases
Bugs item #665336, was opened at 2003-01-09 22:42
Message generated for change (Comment added) made by gergan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan R.A. Deibel (sdeibel)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32 os.path.normpath not correct for leading slash cases
Initial Comment:
os.path.normpath on win32 misses two cases in its
duplicate slash
removal code that I believe should be dealt with:
c:\x\y\z
\\x\y\z
Both of these are returned unchanged.
I've attached an implementation that fixes these to
return the following, respectively:
c:\x\y\z
\x\y\z
I did see the other normpath bugs that were reported
and rejected
and think that the above isn't also a case of "garbage
in garbage out" but of course there's room for
interpretation.
I am a bit unsure about the UNC case since Posix
collapses only 3+ leading slashes to a single slash and
otherwise leaves up to two slashes. But in the context
of win32 the above seems to make more sense to me.
Thanks,
Stephan Deibel
Wing IDE Developer
Archaeopteryx Software
def normpath(path):
"""Normalize path, eliminating double slashes,
etc."""
path = path.replace("/", "\")
prefix, path = os.path.splitdrive(path)
if prefix == '':
max_leading = 2
else:
max_leading = 1
i = 0
while path[:1] == "\":
if i < max_leading:
prefix = prefix + "\"
i += 1
path = path[1:]
comps = path.split("\")
i = 0
while i < len(comps):
if comps[i] in ('.', ''):
del comps[i]
elif comps[i] == '..':
if i > 0 and comps[i-1] != '..':
del comps[i-1:i+1]
i -= 1
elif i == 0 and prefix.endswith("\"):
del comps[i]
else:
i += 1
else:
i += 1
# If the path is now empty, substitute '.'
if not prefix and not comps:
comps.append('.')
return prefix + "\".join(comps)
--
Comment By: gergan (gergan)
Date: 2005-07-19 18:59
Message:
Logged In: YES
user_id=1301159
nevermind, it actually is not a bug as the comment says it all
# POSIX allows one or two initial slashes, but treats three
or more
# as single slash.
I didn't know this. Excuse me and forget my posting ::))
--
Comment By: gergan (gergan)
Date: 2005-07-19 18:50
Message:
Logged In: YES
user_id=1301159
I'm experiencing the same bug on linux with
Python 2.4.1 (#1, Jun 28 2005, 21:03:32)
[GCC 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)]
all the paths beginning with double slash are left unchanged
from os.path.normpath.
so expected behaviour would be (as stated in the documentation)
>>>os.path.normpath ("//usr/lib")
'/usr/lib'
the actual result is:
>>>os.path.normpath ("//usr/lib")
'//usr/lib'
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-19 21:25
Message:
Logged In: YES
user_id=752496
I've the following behaviour in 2.4b1:
>>> os.path.normpath(r"\x\y\z")
'\x\y\z'
>>> os.path.normpath(r"\x\y\z")
'\x\y\z'
>>> os.path.normpath(r"\x\y\z")
'\x\y\z'
which is ok to me, and
>>> os.path.normpath(r"\x\y\z")
'\\x\y\z'
which seems bad.
I'm setting this bug to the 2.4 group.
--
Comment By: Stephan R.A. Deibel (sdeibel)
Date: 2004-11-17 05:04
Message:
Logged In: YES
user_id=12608
Good god, notification email is munging the number of
backslashes inconsistently depending on quoting -- see the
sf bug entry in a browser to see the right thing. Sorry
about that!
--
Comment By: Stephan R.A. Deibel (sdeibel)
Date: 2004-11-17 05:00
Message:
Logged In: YES
user_id=12608
The c:\x\y\z case was broken up to 2.3.4 but appears fixed
in 2.4b2, as you noticed (it used to return "c:\\x\y\z"
and now returns "c:\x\y\z" as it
should).
However in 2.4b4 the \x\y\z case still returns
"\\x\y\z" (it
returns any number of leading backslashes unchanged, no
matter how
many are passed in):
>>> os.path.normpath(r"\x\y\z")
'\\x\y\z'
>>> os.path.normpath(r"\\x\y\z")
'\\\x\y\z'
I'm still fairly sure it should return "\x\y\z" instead
as the more appropriate
normalization of this kind of path on win32.
Hope that helps! Thanks for your work on clearing the bug list!
--
Comment By: Facundo Batista (facundobatis
[ python-Bugs-1241006 ] Distutils does not use logging
Bugs item #1241006, was opened at 2005-07-19 17:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils does not use logging
Initial Comment:
distutils.log creates its own PEP 282-like logger
class, which is fine from the distutils point of view,
but not exactly brilliant if you want to intercept the
calls using the logging facilities that have been in
python since 2.3.
Recommended fix:
If, in fact, distutils.log has to be kept compatible
with 2.1 as is claimed in the source file then
something along the lines of:
try:
import logging
_global_log = logging.getLogger('distutils')
except ImportError:
#insert current Log class definition here
_global_log = Log()
Also, changing the values for DEBUG, INFO, WARN, ERROR and
FATAL to be the same as the ones in logging.py is
probably a good idea.
The distutils logger should have its own formatter that
prints out lines as the thing currently does, but this
formatter should be set within the code for setup()
rather than in the log module.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
