[ python-Bugs-1498638 ] tp_alloc for subtypes of PyComplex_Type is not called
Bugs item #1498638, was opened at 2006-06-01 04:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498638&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.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Travis Oliphant (teoliphant)
Assigned to: Nobody/Anonymous (nobody)
Summary: tp_alloc for subtypes of PyComplex_Type is not called
Initial Comment:
In the function complex_subtype_from_c_complex in the
file complexobject.c, the allocation routine for the
subtype is not called. This causes memory management
problems if the sub-type does not use the Python memory
manager.
The fix is to make the following change:
{
PyObject *op;
- op = PyType_GenericAlloc(type, 0);
+ op = type->tp_alloc(type, 0);
if (op != NULL)
((PyComplexObject *)op)->cval = cval;
return op;
Attched is an example module and script illustrating
what can go wrong along with a patch.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-01 08:27
Message:
Logged In: YES
user_id=849994
Fixed in rev. 46586.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498638&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability
Bugs item #1456209, was opened at 2006-03-22 15:47 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: dictobject.c:dictresize() vulnerability Initial Comment: We thought we squashed the last of the modify-the-dict-from-a-custom-eq kind of bugs long ago. Too bad. -- >Comment By: Armin Rigo (arigo) Date: 2006-06-01 13:20 Message: Logged In: YES user_id=4771 Fixed by patch #1497053. -- Comment By: Armin Rigo (arigo) Date: 2006-03-22 16:32 Message: Logged In: YES user_id=4771 The cause of the bug is that if oldtable == mp->ma_smalltable then pure Python code can mangle with mp->ma_smalltable while it is being walked on. A simple fix would be to always make a copy of the oldtable if it is mp->ma_smalltable (not only if oldtable == newtable). Attached a more efficient fix, which should also make dict resizing somehow faster. It requires yet another version of the lookup algorithm, though. It's a very simple version that assumes that all items are different and the dict contains no dummy entries. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1275608 ] dict key comparison swallows exceptions
Bugs item #1275608, was opened at 2005-08-29 10:30 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Michael Hudson (mwh) Summary: dict key comparison swallows exceptions Initial Comment: This is an old one that has just biten again and cost a lot of debugging time again: the dict lookup function swallows all errors during key comparison. This is bad in itself, but if the current stack depth is just wrong then *any* comparison will raise a RuntimeError and lookup will pretend that the dictionary is essentially empty. The attached sample program shows this and crashes with a KeyError instead of a RuntimeError. While at the C level there is a basic compatibility problem involved (PyDict_GetItem() not allowed to raise any exception -- see http://thread.gmane.org/gmane.comp.python.devel/62427), I think it should be possible to improve the situation on the Python interface. Unless someone points me to something I missed, I plan to come up with a patch that changes the internal dict functions (including lookdict()) to let exceptions pass through, and have the exceptions swallowed only by the PyDict_*() API functions that require it. The possible (remote) incompatibility here is existing code relying on the exceptions being swallowed -- either Python code, or C code using PyObject_GetItem() or PyMapping_GetItemString(). Such code deserves to be shot down in my opinion. Assigned to mwh for his feedback (not because I want him to write the patch!). -- Comment By: Armin Rigo (arigo) Date: 2006-05-29 16:55 Message: Logged In: YES user_id=4771 Proposed patch #1497053. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-214033 ] re incompatibility in sre
Bugs item #214033, was opened at 2000-09-11 08:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&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: Extension Modules Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: re incompatibility in sre Initial Comment: [submitted by Adam Sampson] Under Python 1.5.2, I had a script containing the following line: m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url) Under 1.6, this fails with: [...] File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat I can narrow it down to: >>> m = re.match(r"(x?)?", url) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat whereas: >>> m = re.match(r"(x?.)?", url) works fine. Is this correct behaviour for SRE, or am I just being stupid? "(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl too)... -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 13:45 Message: Logged In: YES user_id=849994 #1456280 is a duplicate of this. -- Comment By: Trent Mick (tmick) Date: 2006-04-10 23:11 Message: Logged In: YES user_id=34892 I've run into another incarnation of this (it breaks in Python 2.3.5 and Python 2.4.3): >>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Now granted that the '?' here is redundant for the '*' quantifier on 'a', but compiling this regex works with Python 2.3's "pre" and it works in Perl. The actual use case I've hit here is trying to compile all the regex's in Fedora Core 5's SELinux config files (/etc/selinux/targeted/contexts/files/file_contexts*). The first such regex that broke was: '/usr/share/selinux-policy([^/]*)?/html(/.*)?' -- Comment By: Martin v. Löwis (loewis) Date: 2000-10-01 18:13 Message: Yes, it is still broken in 2.0b2. -- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-01 04:33 Message: Martin, is this still broken in 2.0? Fredrik, any idea? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456280 ] Traceback error when compiling Regex
Bugs item #1456280, was opened at 2006-03-22 17:34
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456280&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: Regular Expressions
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Wolfgang Grafen (grafen)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Traceback error when compiling Regex
Initial Comment:
Traceback error when compiling the following regular
expression. Error discovered with Python 2.4.2.
Used pre from python2.3 to check the validity of
re_fmt. With pre it works fine.
Question:
I submitted a sre error report before and I warned
to take off pre from the library. It is of advantage
to be able to check a failing re with pre. Personally
I feel sre has still too many bugs to completely
substitute pre.
Regards
Wolfgang Grafen
==
chios scalar 582 % ./fmtscalar.py
Traceback (most recent call last):
File "./fmtscalar.py", line 21, in ?
re_fmt = re.compile(
File "/user/freepool/local/lib/python2.3/sre.py",
line 179, in compile
return _compile(pattern, flags)
File "/user/freepool/local/lib/python2.3/sre.py",
line 230, in _compile
raise error, v # invalid expression
sre_constants.error: nothing to repeat
cut here
#!/usr/bin/env python2.3
# -*- coding: Latin-1 -*-
import sre as re
re_fmt = re.compile(
"("
"%"
"(?P"
"\d+"
"(?:"
"[.]"
"\d+"
")"
")?"
"(?:"
"[(]"
"(?P"
"[^)]*"
")?"
"[)]"
")?"
"(?P[a-z])"
")"
)
a="%s"
b="aber%sxyz"
c="aber%3.1i"
c="aber%(quengel)s"
for i in a,b,c:
m = re_fmt.findall(i)
print i,m
cut here ---
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-01 13:46
Message:
Logged In: YES
user_id=849994
Duplicate of #214033.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456280&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability
Bugs item #1456209, was opened at 2006-03-22 10:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&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: Closed Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: dictobject.c:dictresize() vulnerability Initial Comment: We thought we squashed the last of the modify-the-dict-from-a-custom-eq kind of bugs long ago. Too bad. -- >Comment By: Tim Peters (tim_one) Date: 2006-06-01 11:54 Message: Logged In: YES user_id=31435 Patch 1497053 was checked in as revision 46589 of the trunk for Python 2.5, so closing this. I doubt it's worth the effort to backport to 2.4. -- Comment By: Armin Rigo (arigo) Date: 2006-06-01 09:20 Message: Logged In: YES user_id=4771 Fixed by patch #1497053. -- Comment By: Armin Rigo (arigo) Date: 2006-03-22 11:32 Message: Logged In: YES user_id=4771 The cause of the bug is that if oldtable == mp->ma_smalltable then pure Python code can mangle with mp->ma_smalltable while it is being walked on. A simple fix would be to always make a copy of the oldtable if it is mp->ma_smalltable (not only if oldtable == newtable). Attached a more efficient fix, which should also make dict resizing somehow faster. It requires yet another version of the lookup algorithm, though. It's a very simple version that assumes that all items are different and the dict contains no dummy entries. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1275608 ] dict key comparison swallows exceptions
Bugs item #1275608, was opened at 2005-08-29 06:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&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: Closed Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Nobody/Anonymous (nobody) Summary: dict key comparison swallows exceptions Initial Comment: This is an old one that has just biten again and cost a lot of debugging time again: the dict lookup function swallows all errors during key comparison. This is bad in itself, but if the current stack depth is just wrong then *any* comparison will raise a RuntimeError and lookup will pretend that the dictionary is essentially empty. The attached sample program shows this and crashes with a KeyError instead of a RuntimeError. While at the C level there is a basic compatibility problem involved (PyDict_GetItem() not allowed to raise any exception -- see http://thread.gmane.org/gmane.comp.python.devel/62427), I think it should be possible to improve the situation on the Python interface. Unless someone points me to something I missed, I plan to come up with a patch that changes the internal dict functions (including lookdict()) to let exceptions pass through, and have the exceptions swallowed only by the PyDict_*() API functions that require it. The possible (remote) incompatibility here is existing code relying on the exceptions being swallowed -- either Python code, or C code using PyObject_GetItem() or PyMapping_GetItemString(). Such code deserves to be shot down in my opinion. Assigned to mwh for his feedback (not because I want him to write the patch!). -- >Comment By: Tim Peters (tim_one) Date: 2006-06-01 11:56 Message: Logged In: YES user_id=31435 Patch 1497053 was checked in as revision 46589 of the trunk for Python 2.5, so closing this. Because it changes semantics, it should not be backported to 2.4. -- Comment By: Armin Rigo (arigo) Date: 2006-05-29 12:55 Message: Logged In: YES user_id=4771 Proposed patch #1497053. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1499049 ] lstrip does not work properly
Bugs item #1499049, was opened at 2006-06-01 18:57
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=1499049&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: rpache (rpache)
Assigned to: Nobody/Anonymous (nobody)
Summary: lstrip does not work properly
Initial Comment:
#!/usr/bin/python
line1='DOMAIN=Alpha'
line2='DOMAIN=Beta'
error=line1.lstrip('DOMAIN=')
ok=line2.lstrip('DOMAIN=')
print error
print ok
The code above prints only "lpha" instead of "Alpha"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499049&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1497962 ] Leak in tarfile.py
Bugs item #1497962, was opened at 2006-05-31 08:42
Message generated for change (Comment added) made by jensj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jens Jørgen Mortensen (jensj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Leak in tarfile.py
Initial Comment:
There is a leak when using the tarfile module and the
extractfile method. Here is a simple example:
$ echo "grrr" > x.txt
$ tar cf x.tar x.txt
$ python
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import gc
>>> import tarfile
>>> tar = tarfile.open('x.tar', 'r')
>>> f = tar.extractfile('x.txt')
>>> f.read()
'grrr\n'
>>> del f
>>> gc.set_debug(gc.DEBUG_LEAK)
>>> print gc.collect()
gc: collectable
gc: collectable
gc: collectable
3
>>> print gc.garbage
[, {'name':
'x.txt', 'read': >, 'pos':
0L, 'fileobj': , 'mode': 'r', 'closed': False, 'offset':
512L, 'linebuffer': '', 'size': 5L}, >]
>>>
--
>Comment By: Jens Jørgen Mortensen (jensj)
Date: 2006-06-01 22:08
Message:
Logged In: YES
user_id=716463
Problem is that the ExfileObject hat an attribute
(self.read) that is a method bound to itself
(self._readsparse or self._readnormal). One solution is to
add "del self.read" to the close method, but someone might
forget to close the object and still get the leak. Another
solution is to change the end of __init__ to:
if tarinfo.issparse():
self.sparse = tarinfo.sparse
else:
self.sparse = None
and add a read method:
def read(self, size=None):
if self.sparse is None:
return self._readnormal(size)
else:
return self._readsparse(size)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1499049 ] lstrip does not work properly
Bugs item #1499049, was opened at 2006-06-01 18:57
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499049&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: rpache (rpache)
Assigned to: Nobody/Anonymous (nobody)
Summary: lstrip does not work properly
Initial Comment:
#!/usr/bin/python
line1='DOMAIN=Alpha'
line2='DOMAIN=Beta'
error=line1.lstrip('DOMAIN=')
ok=line2.lstrip('DOMAIN=')
print error
print ok
The code above prints only "lpha" instead of "Alpha"
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-01 20:28
Message:
Logged In: YES
user_id=849994
Please read the docs to (l|r|)strip -- then you'll see that
this is not a bug.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499049&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1497962 ] Leak in tarfile.py
Bugs item #1497962, was opened at 2006-05-31 02:42
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jens Jørgen Mortensen (jensj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Leak in tarfile.py
Initial Comment:
There is a leak when using the tarfile module and the
extractfile method. Here is a simple example:
$ echo "grrr" > x.txt
$ tar cf x.tar x.txt
$ python
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import gc
>>> import tarfile
>>> tar = tarfile.open('x.tar', 'r')
>>> f = tar.extractfile('x.txt')
>>> f.read()
'grrr\n'
>>> del f
>>> gc.set_debug(gc.DEBUG_LEAK)
>>> print gc.collect()
gc: collectable
gc: collectable
gc: collectable
3
>>> print gc.garbage
[, {'name':
'x.txt', 'read': >, 'pos':
0L, 'fileobj': , 'mode': 'r', 'closed': False, 'offset':
512L, 'linebuffer': '', 'size': 5L}, >]
>>>
--
>Comment By: Tim Peters (tim_one)
Date: 2006-06-01 19:09
Message:
Logged In: YES
user_id=31435
There's no evidence of a leak here -- quite the contrary.
As the docs say, DEBUG_LEAK implies DEBUG_SAVEALL, and
DEBUG_SAVEALL results in _all_ cyclic trash getting
appended to gc.garbage. If you don't mess with
gc.set_debug(), you'll discover that gc.garbage is empty at
the end.
In addition, note that the DEBUG_LEAK output plainly says:
gc: collectable ...
That's also telling you that it found collectable cyclic
trash (which it would have reclaimed had you not forced it
to get appended to gc.garbage instead). If gc had found
uncollectable cycles, these msgs would have started with
gc: uncollectable ...
instead.
Most directly, if I run your tarfile open() and file
extraction in an infinite loop (without messing with
gc.set_debug()), the process memory use does not grow over time.
Unless you have other evidence of an actual leak, this
report should be closed without action. Yes, there are
reference cycles here, but they're of kinds cyclic gc reclaims.
--
Comment By: Jens Jørgen Mortensen (jensj)
Date: 2006-06-01 16:08
Message:
Logged In: YES
user_id=716463
Problem is that the ExfileObject hat an attribute
(self.read) that is a method bound to itself
(self._readsparse or self._readnormal). One solution is to
add "del self.read" to the close method, but someone might
forget to close the object and still get the leak. Another
solution is to change the end of __init__ to:
if tarinfo.issparse():
self.sparse = tarinfo.sparse
else:
self.sparse = None
and add a read method:
def read(self, size=None):
if self.sparse is None:
return self._readnormal(size)
else:
return self._readsparse(size)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459159 ] inspect.getargspec() is wrong for def foo((x)):
Bugs item #1459159, was opened at 2006-03-27 11:05 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&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: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() is wrong for def foo((x)): Initial Comment: See my recent checkin on HEAD for fixing def foo((x)): in the AST compiler. I had to modify test_inspect because the above signature should not do tuple unpacking. inspect thinkgs it does though. -- Comment By: iga Seilnacht (zseil) Date: 2006-06-02 04:02 Message: Logged In: YES user_id=1326842 Can this bug be closed? It seems that the only problem was test_inspect relying on the old behavior. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 13:39 Message: Logged In: YES user_id=849994 This at least explains why test_inspect didn't fail for 2.5 after you had fixed the bug and modified the test. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 13:38 Message: Logged In: YES user_id=849994 That's a bit odd. Following defs: def bar((x)): pass def foo(x): pass In 2.4: >>> dis.dis(bar) 1 0 LOAD_FAST0 (.0) 3 STORE_FAST 1 (x) 6 LOAD_CONST 0 (None) 9 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE In 2.5: >>> dis.dis(bar) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1499316 ] lstrip does not work properly
Bugs item #1499316, was opened at 2006-06-02 06:51
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=1499316&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: rpache (rpache)
Assigned to: Nobody/Anonymous (nobody)
Summary: lstrip does not work properly
Initial Comment:
#!/usr/bin/python
line1='DOMAIN=Alpha'
line2='DOMAIN=Beta'
error=line1.lstrip('DOMAIN=')
ok=line2.lstrip('DOMAIN=')
print error
print ok
The code above prints only "lpha" instead of "Alpha"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499316&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
