[ python-Bugs-1467619 ] Header.decode_header eats up spaces
Bugs item #1467619, was opened at 2006-04-10 12:33
Message generated for change (Comment added) made by mgoutell
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mathieu Goutelle (mgoutell)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces
Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.
See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('éè', 'iso-8859-1')
print h
print decode_header(h)
This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]
This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
^ This space disappears
This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.
This patch (not extensively tested though) seems to
solve this problem:
--- /usr/lib/python2.3/email/Header.py 2005-09-05
00:20:03.0 +0200
+++ Header.py 2006-04-10 12:27:27.0 +0200
@@ -90,7 +90,7 @@
continue
parts = ecre.split(line)
while parts:
-unenc = parts.pop(0).strip()
+unenc = parts.pop(0).rstrip()
if unenc:
# Should we continue a long line?
if decoded and decoded[-1][1] is None:
--
>Comment By: Mathieu Goutelle (mgoutell)
Date: 2007-05-16 11:25
Message:
Logged In: YES
user_id=719862
Originator: YES
Hello,
Any news about this bug. It seems still there in 2.5 after a one year
notice...
Regards,
--
Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-13 00:28
Message:
Logged In: YES
user_id=254738
I can confirm this bug and have been bitten by it as well.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1719898 ] tarfile stops expanding with long filenames
Bugs item #1719898, was opened at 2007-05-16 09:32
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=1719898&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
Private: No
Submitted By: Christian Zagrodnick (zagy)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile stops expanding with long filenames
Initial Comment:
The tarfile module fixes an issue with "Some old tar programs represent a
directory as a regular file with a trailing slash.":
if tarinfo.isreg() and tarinfo.name.endswith("/"):
tarinfo.type = DIRTYPE
*After* that the full filename is composed. The chars >100 are stored in
"prefix":
if tarinfo.type != GNUTYPE_SPARSE:
tarinfo.name normpath(os.path.join(nts(tarinfo.prefix), tarinfo.name))
So guess what happens if you filename has a / at the 100th character. Right,
its considered a directory. Since directories have no data, the next metadata
block is read from your file data which fails in various ways.
Patch attached.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1719933 ] No docs for PyEval_EvalCode and related functions
Bugs item #1719933, was opened at 2007-05-16 10:55 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=1719933&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joseph Eagar (joeedh) Assigned to: Nobody/Anonymous (nobody) Summary: No docs for PyEval_EvalCode and related functions Initial Comment: Hi. There's no documentation for PyEval_EvalCode and related functions. Joe -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719933&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1717900 ] Destructor behavior faulty
Bugs item #1717900, was opened at 2007-05-12 17:41
Message generated for change (Comment added) made by gagenellina
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&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 Interpreter Core
Group: None
Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty
Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.
Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute
'population'" in > ignored
added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person',
'wolf', '__name__', '__doc__']
changed wolf to aaa:
print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop',
'Person', '__name__', '__doc__']
Please note the position of 'aaa' at the beginning of the list, before
'Person'. With 'wolf' being after 'Person'.
If the destructing code removes items in this order, no wonder I get an error.
Person should not get deleted if refcount is still > 0.
Wolf Rogner
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 08:19
Message:
Logged In: YES
user_id=479790
Originator: NO
FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.
To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 15:44
Message:
Logged In: YES
user_id=479790
Originator: NO
FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.
To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 12:38
Message:
Logged In: YES
user_id=1115903
Originator: NO
I took the example mentioned from here:
http://www.python.org/doc/essays/cleanup/
and added this line to the end:
wolf = Person('wolf')
and it gives the reported error. Here is a minimal snippet that produces
the same error when executed as the top-level module:
class Person:
population = 0
def __del__(self):
Person.population -= 1
wolf = Person()
This appears to be consistent with the behavior described here:
http://www.python.org/doc/essays/cleanup/
While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me. It seems like it's not all that hard to get bitten by
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.
For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to do.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 20:36
Message:
Logged In: YES
user_id=1115903
Originator: NO
Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1719898 ] tarfile stops expanding with long filenames
Bugs item #1719898, was opened at 2007-05-16 11:32
Message generated for change (Settings changed) made by gustaebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&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
Private: No
Submitted By: Christian Zagrodnick (zagy)
>Assigned to: Lars Gustäbel (gustaebel)
Summary: tarfile stops expanding with long filenames
Initial Comment:
The tarfile module fixes an issue with "Some old tar programs represent a
directory as a regular file with a trailing slash.":
if tarinfo.isreg() and tarinfo.name.endswith("/"):
tarinfo.type = DIRTYPE
*After* that the full filename is composed. The chars >100 are stored in
"prefix":
if tarinfo.type != GNUTYPE_SPARSE:
tarinfo.name normpath(os.path.join(nts(tarinfo.prefix), tarinfo.name))
So guess what happens if you filename has a / at the 100th character. Right,
its considered a directory. Since directories have no data, the next metadata
block is read from your file data which fails in various ways.
Patch attached.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467619 ] Header.decode_header eats up spaces
Bugs item #1467619, was opened at 2006-04-10 10:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&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.3
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: Mathieu Goutelle (mgoutell)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces
Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.
See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('éè', 'iso-8859-1')
print h
print decode_header(h)
This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]
This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
^ This space disappears
This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.
This patch (not extensively tested though) seems to
solve this problem:
--- /usr/lib/python2.3/email/Header.py 2005-09-05
00:20:03.0 +0200
+++ Header.py 2006-04-10 12:27:27.0 +0200
@@ -90,7 +90,7 @@
continue
parts = ecre.split(line)
while parts:
-unenc = parts.pop(0).strip()
+unenc = parts.pop(0).rstrip()
if unenc:
# Should we continue a long line?
if decoded and decoded[-1][1] is None:
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-16 12:51
Message:
Logged In: YES
user_id=849994
Originator: NO
I propose the attached patch. RFC 2047 specifies to ignore whitespace
between encoded-words, but IMHO not between ordinary text and
encoded-words.
File Added: emailheader.diff
--
Comment By: Mathieu Goutelle (mgoutell)
Date: 2007-05-16 09:25
Message:
Logged In: YES
user_id=719862
Originator: YES
Hello,
Any news about this bug. It seems still there in 2.5 after a one year
notice...
Regards,
--
Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-12 22:28
Message:
Logged In: YES
user_id=254738
I can confirm this bug and have been bitten by it as well.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467619 ] Header.decode_header eats up spaces
Bugs item #1467619, was opened at 2006-04-10 06:33
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&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.3
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Mathieu Goutelle (mgoutell)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces
Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.
See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('éè', 'iso-8859-1')
print h
print decode_header(h)
This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]
This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
^ This space disappears
This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.
This patch (not extensively tested though) seems to
solve this problem:
--- /usr/lib/python2.3/email/Header.py 2005-09-05
00:20:03.0 +0200
+++ Header.py 2006-04-10 12:27:27.0 +0200
@@ -90,7 +90,7 @@
continue
parts = ecre.split(line)
while parts:
-unenc = parts.pop(0).strip()
+unenc = parts.pop(0).rstrip()
if unenc:
# Should we continue a long line?
if decoded and decoded[-1][1] is None:
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-05-16 09:08
Message:
Logged In: YES
user_id=12800
Originator: NO
IIRC, I tried the OP's patch and it broke too many of the email package's
test suite. I made an attempt at fixing the problem to be much more RFC
compliant, but couldn't get the test suite to pass completely. This points
to a much deeper problem with email package header management. I don't
think the problem is a bug, I think it's a design flaw.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-16 08:51
Message:
Logged In: YES
user_id=849994
Originator: NO
I propose the attached patch. RFC 2047 specifies to ignore whitespace
between encoded-words, but IMHO not between ordinary text and
encoded-words.
File Added: emailheader.diff
--
Comment By: Mathieu Goutelle (mgoutell)
Date: 2007-05-16 05:25
Message:
Logged In: YES
user_id=719862
Originator: YES
Hello,
Any news about this bug. It seems still there in 2.5 after a one year
notice...
Regards,
--
Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-12 18:28
Message:
Logged In: YES
user_id=254738
I can confirm this bug and have been bitten by it as well.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1719995 ] sets module documentation: example uses deprecated method
Bugs item #1719995, was opened at 2007-05-16 15:12 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=1719995&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jens Quade (snejsource) Assigned to: Nobody/Anonymous (nobody) Summary: sets module documentation: example uses deprecated method Initial Comment: In 5.7.1 the text deprecates the use of .union_update in favour of .update (Last sentence) http://docs.python.org/lib/set-objects.html The example in 5.7.2 still uses union_update. http://docs.python.org/lib/set-example.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719995&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1719898 ] tarfile stops expanding with long filenames
Bugs item #1719898, was opened at 2007-05-16 11:32
Message generated for change (Comment added) made by gustaebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&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
Private: No
Submitted By: Christian Zagrodnick (zagy)
Assigned to: Lars Gustäbel (gustaebel)
Summary: tarfile stops expanding with long filenames
Initial Comment:
The tarfile module fixes an issue with "Some old tar programs represent a
directory as a regular file with a trailing slash.":
if tarinfo.isreg() and tarinfo.name.endswith("/"):
tarinfo.type = DIRTYPE
*After* that the full filename is composed. The chars >100 are stored in
"prefix":
if tarinfo.type != GNUTYPE_SPARSE:
tarinfo.name normpath(os.path.join(nts(tarinfo.prefix), tarinfo.name))
So guess what happens if you filename has a / at the 100th character. Right,
its considered a directory. Since directories have no data, the next metadata
block is read from your file data which fails in various ways.
Patch attached.
--
>Comment By: Lars Gustäbel (gustaebel)
Date: 2007-05-16 15:32
Message:
Logged In: YES
user_id=642936
Originator: NO
Did you also test Python 2.5? If this error occurs with that version too
(which it should not), please attach a small test tar archive to this
tracker item.
Python 2.4 is no longer maintained, sorry.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719898&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1719995 ] sets module documentation: example uses deprecated method
Bugs item #1719995, was opened at 2007-05-16 13:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719995&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: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jens Quade (snejsource) Assigned to: Nobody/Anonymous (nobody) Summary: sets module documentation: example uses deprecated method Initial Comment: In 5.7.1 the text deprecates the use of .union_update in favour of .update (Last sentence) http://docs.python.org/lib/set-objects.html The example in 5.7.2 still uses union_update. http://docs.python.org/lib/set-example.html -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-16 13:44 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed in rev. 55383, 55384 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719995&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668596 ] distutils chops the first character of filenames
Bugs item #1668596, was opened at 2007-02-25 17:15 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Pointon (freecondiments) Assigned to: Nobody/Anonymous (nobody) Summary: distutils chops the first character of filenames Initial Comment: Python 2.5c1, Windows XP SP2. distutils chops the first character from some filenames if the package_data key is ''. Minimal example: The setup.py attached, and a directory named 'doc' in the same directory as setup.py with files in it. Running "python setup.py bdist" triggers the error. On my box, this fails with: running bdist running bdist_dumb running build running build_py error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html describes the same problem, and http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a commentary on the code in distutils/commands/build_py.py which causes the error. On lines 117-122, it tries to chop the directory path from the files it has found, using len() and slicing. This job is better done by os.path.split (and is probably more portable, too). -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-16 11:47 Message: Logged In: YES user_id=984087 Originator: NO After reading the distutils example section today, I did find one example using null string as package_dir value. So there may be something to this bug after all. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-27 12:19 Message: Logged In: YES user_id=984087 Originator: NO Hi, I reproduced the problem with the latest build on linux. The "fix" may be trivial but I am not entirely sure if there is a problem in the first place. The distutils document does not mention about having null value for package_dir as is the case in your setup.py. I may be missing something here but can you please explain the conclusion that "" is a perfectly valid value for package_dir (as mentioned in one of the threads in mailing list)? I am assuming that you mean "distribution root" directory by "". If this is found to be valid usage, the document should be updated along with the code fix. Otherwise, a check can be put in to disallow null values. Raghu. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1720241 ] Compiler is not thread safe?
Bugs item #1720241, was opened at 2007-05-16 22:38 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=1720241&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ‹‹PC›› (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler is not thread safe? Initial Comment: r = ''' a(b(c[d])) ''' from threading import Thread from compiler import parse Thread(target = parse, args = (r,)).start() leads to Bus error (core dumped) When runs not in thread everything is OK. OS FreeBSD 5.4. Python 2.5.1 (seems that 2.5 also has this error) (Runs perfectly on Linux, and on FreeBSD with Python 2.4) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1720250 ] PyGILState_Ensure does not acquires GIL
Bugs item #1720250, was opened at 2007-05-16 19:46
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=1720250&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kuno Ospald (kunoospald)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyGILState_Ensure does not acquires GIL
Initial Comment:
The function PyGILState_Ensure doesn't acquire the GIL if current thread state
is valid. In contrast to that PyGILState_Release deletes the thread state
(PyThreadState_DeleteCurrent) which releases the GIL which got not acquired
before (=> mutex->owned = -2).
Here is an example which locks at PyRun_SimpleString:
// initialize the Python interpreter
Py_Initialize();
PyEval_InitThreads();
// release the GIL as PyEval_InitThreads
// implicitly acquires the GIL
PyEval_ReleaseLock();
PyGILState_STATE gstate;
gstate = PyGILState_Ensure();
PyRun_SimpleString("import random\n");
PyGILState_Release(gstate);
In that simple example the problem can be fixed by removing the call to
PyEval_ReleaseLock. But that is needed for applications that call into the
interpreter from multiple threads.
The only solution I could found up to that point is the following:
// initialize the Python interpreter
Py_Initialize();
PyEval_InitThreads();
PyThreadState* tcur = PyThreadState_Get() ;
PyThreadState_Swap(NULL);
PyThreadState_Clear(tcur);
PyThreadState_Delete(tcur);
// release the GIL as PyEval_InitThreads
// implicitly acquires the GIL
PyEval_ReleaseLock();
PyGILState_STATE gstate;
gstate = PyGILState_Ensure();
PyRun_SimpleString("import random\n");
PyGILState_Release(gstate);
Which seems to works fine. But I think that this behavior of PyGILState_Ensure
should be either documented or fixed.
Thanks,
Kuno
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720250&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1717900 ] Destructor behavior faulty
Bugs item #1717900, was opened at 2007-05-12 17:41
Message generated for change (Comment added) made by gagenellina
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&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 Interpreter Core
Group: None
Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty
Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.
Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute
'population'" in > ignored
added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person',
'wolf', '__name__', '__doc__']
changed wolf to aaa:
print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop',
'Person', '__name__', '__doc__']
Please note the position of 'aaa' at the beginning of the list, before
'Person'. With 'wolf' being after 'Person'.
If the destructing code removes items in this order, no wonder I get an error.
Person should not get deleted if refcount is still > 0.
Wolf Rogner
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 19:06
Message:
Logged In: YES
user_id=479790
Originator: NO
FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.
To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 08:19
Message:
Logged In: YES
user_id=479790
Originator: NO
FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.
To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 15:44
Message:
Logged In: YES
user_id=479790
Originator: NO
FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.
To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 12:38
Message:
Logged In: YES
user_id=1115903
Originator: NO
I took the example mentioned from here:
http://www.python.org/doc/essays/cleanup/
and added this line to the end:
wolf = Person('wolf')
and it gives the reported error. Here is a minimal snippet that produces
the same error when executed as the top-level module:
class Person:
population = 0
def __del__(self):
Person.population -= 1
wolf = Person()
This appears to be consistent with the behavior described here:
http://www.python.org/doc/essays/cleanup/
While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me. It seems like it's not all that hard to get bitten by
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.
For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to d
[ python-Bugs-1717900 ] Destructor behavior faulty
Bugs item #1717900, was opened at 2007-05-12 15:41
Message generated for change (Comment added) made by alanmcintyre
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&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 Interpreter Core
Group: None
Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty
Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.
Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute
'population'" in > ignored
added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person',
'wolf', '__name__', '__doc__']
changed wolf to aaa:
print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop',
'Person', '__name__', '__doc__']
Please note the position of 'aaa' at the beginning of the list, before
'Person'. With 'wolf' being after 'Person'.
If the destructing code removes items in this order, no wonder I get an error.
Person should not get deleted if refcount is still > 0.
Wolf Rogner
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-16 17:58
Message:
Logged In: YES
user_id=1115903
Originator: NO
I tried out a simple change (to the trunk) in _PyModule_Clear to prevent
this particular problem. Between the "remove everything beginning with an
underscore" and the "remove everything except __builtins__" steps, I added
a step to remove all instance objects in the module's dictionary. It
appears to stop this problem and passes the regression test suite. I can
post it as a patch if this seems like a reasonable change to make.
Also, I noticed that earlier I posted the wrong link for the location of
the example code; it should have been:
http://www.dpawson.co.uk/bop/byteofpython_120.txt
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 17:06
Message:
Logged In: YES
user_id=479790
Originator: NO
FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.
To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 06:19
Message:
Logged In: YES
user_id=479790
Originator: NO
FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.
To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 13:44
Message:
Logged In: YES
user_id=479790
Originator: NO
FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.
To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 10:38
Message:
Logged In: YES
user_id=1115903
Originator: NO
I took the example mentioned from here:
http://www.python.org/doc/essays/cleanup/
and added this line to the end:
wolf = Person('wolf')
and it gives the reported error. Here is a minimal snipp
[ python-Bugs-1720241 ] Compiler is not thread safe?
Bugs item #1720241, was opened at 2007-05-16 16:38 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ‹‹PC›› (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler is not thread safe? Initial Comment: r = ''' a(b(c[d])) ''' from threading import Thread from compiler import parse Thread(target = parse, args = (r,)).start() leads to Bus error (core dumped) When runs not in thread everything is OK. OS FreeBSD 5.4. Python 2.5.1 (seems that 2.5 also has this error) (Runs perfectly on Linux, and on FreeBSD with Python 2.4) -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 20:30 Message: Logged In: YES user_id=479790 Originator: NO No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
