[ python-Bugs-1661603 ] Misleading behavior for [] and {} default arguments
Bugs item #1661603, was opened at 2007-02-16 16: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=1661603&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
Private: No
Submitted By: Matthijs (matthijsd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading behavior for [] and {} default arguments
Initial Comment:
Hello
On python 2.3.4 and 2.4.3,
>>> def a(x=[]):
... return x
...
>>> y=a()
>>> y.append(1)
>>> a()
[1]
Hence, the default argument is not recomputed. The same behavior occurs with
x={} instead of x=[].
This looks like a bug because it is not coherent with
>>> def f():
... return []
...
>>> y=f()
>>> y.append(5)
>>> f()
[]
So, is it a feature?
Thanks
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661603&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1661603 ] Misleading behavior for [] and {} default arguments
Bugs item #1661603, was opened at 2007-02-16 15:32
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661603&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: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Matthijs (matthijsd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misleading behavior for [] and {} default arguments
Initial Comment:
Hello
On python 2.3.4 and 2.4.3,
>>> def a(x=[]):
... return x
...
>>> y=a()
>>> y.append(1)
>>> a()
[1]
Hence, the default argument is not recomputed. The same behavior occurs with
x={} instead of x=[].
This looks like a bug because it is not coherent with
>>> def f():
... return []
...
>>> y=f()
>>> y.append(5)
>>> f()
[]
So, is it a feature?
Thanks
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-16 15:40
Message:
Logged In: YES
user_id=849994
Originator: NO
Yes, it is. (Please post questions about Python semantics to the
comp.lang.python newsgroup, they'll explain them in detail...)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661603&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648268 ] Parameter list mismatches (portation problem)
Bugs item #1648268, was opened at 2007-01-30 22:15
Message generated for change (Comment added) made by ked-tao
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648268&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: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parameter list mismatches (portation problem)
Initial Comment:
On the system I'm porting to(*), an application will trap if the caller does
not pass the exact parameter list that the callee requires. This is causing
problems running Python.
One common instance where this appears to be causing problems is where
functions are registered as METH_NOARGS methods. For example, in
Obejcts/dictobject.c, dict_popitem() is declared:
static PyObject *dict_popitem(dictobject *mp);
However, as it is declared in the method array as METH_NOARGS, it will be
called by Objects/methodobject.c:PyCFunction_Call() as "(*meth)(self, NULL)"
(i.e., an extra NULL parameter is passed for some reason). This will fail on my
target system.
I've no problem submitting a patch for this (dictobject.c is by no means the
only place this is happening - it's just the first one encountered because it's
used so much - though some places _do_ correctly declare a second, ignored
parameter). However, I'd like to get agreement on the correct form it should be
changed to before I put the effort in to produce a patch (it's going to be a
fairly tedious process to identify and fix all these).
In various modules, the functions are called internally as well as being
registered as METH_NOARGS methods.
Therefore, the change can either be:
static PyObject *foo(PyObject *self)
{
...
}
static PyObject *foo_noargs(PyObject *self, void *noargs_null)
{
return foo(self);
}
... where 'foo' is called internally and 'foo_noargs' is registered as a
METH_NOARGS method.
or:
static PyObject *foo(PyObject *self, void *noargs_null)
{
...
}
... and any internal calls in the module have to pass a second, NULL, argument
in each call.
The former favours internal module calls over METH_NOARGS calls, the latter
penalises them. Which is preferred? Should this be raised on a different forum?
Does anyone care? ;)
Thanks, Kev.
(*) Details on request.
--
>Comment By: ked-tao (ked-tao)
Date: 2007-02-16 16:42
Message:
Logged In: YES
user_id=1703158
Originator: YES
File Added: tested.diff
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-06 19:49
Message:
Logged In: YES
user_id=21627
Originator: NO
The current specification says that these should be PyCFunction pointers,
see
http://docs.python.org/api/common-structs.html
My initial implementation of METH_NOARGS had it differently, and nobody
ever bothered fixing them all when this was changed. Please do submit a
patch to correct all such errors, both in code and documentation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648268&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648268 ] Parameter list mismatches (portation problem)
Bugs item #1648268, was opened at 2007-01-30 22:15
Message generated for change (Comment added) made by ked-tao
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648268&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: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parameter list mismatches (portation problem)
Initial Comment:
On the system I'm porting to(*), an application will trap if the caller does
not pass the exact parameter list that the callee requires. This is causing
problems running Python.
One common instance where this appears to be causing problems is where
functions are registered as METH_NOARGS methods. For example, in
Obejcts/dictobject.c, dict_popitem() is declared:
static PyObject *dict_popitem(dictobject *mp);
However, as it is declared in the method array as METH_NOARGS, it will be
called by Objects/methodobject.c:PyCFunction_Call() as "(*meth)(self, NULL)"
(i.e., an extra NULL parameter is passed for some reason). This will fail on my
target system.
I've no problem submitting a patch for this (dictobject.c is by no means the
only place this is happening - it's just the first one encountered because it's
used so much - though some places _do_ correctly declare a second, ignored
parameter). However, I'd like to get agreement on the correct form it should be
changed to before I put the effort in to produce a patch (it's going to be a
fairly tedious process to identify and fix all these).
In various modules, the functions are called internally as well as being
registered as METH_NOARGS methods.
Therefore, the change can either be:
static PyObject *foo(PyObject *self)
{
...
}
static PyObject *foo_noargs(PyObject *self, void *noargs_null)
{
return foo(self);
}
... where 'foo' is called internally and 'foo_noargs' is registered as a
METH_NOARGS method.
or:
static PyObject *foo(PyObject *self, void *noargs_null)
{
...
}
... and any internal calls in the module have to pass a second, NULL, argument
in each call.
The former favours internal module calls over METH_NOARGS calls, the latter
penalises them. Which is preferred? Should this be raised on a different forum?
Does anyone care? ;)
Thanks, Kev.
(*) Details on request.
--
>Comment By: ked-tao (ked-tao)
Date: 2007-02-16 16:46
Message:
Logged In: YES
user_id=1703158
Originator: YES
Hi,
I am submitting two patches (both against the 2.5 release sources). One
contains a set of changes which have subsequently been compiled by me and
used to run lib/python/test/regrtest.py. If the format of the changes
themselves is acceptable, then I believe this patch can be applied
relatively
confidently. I haven't paid too much attention to conditional compilation
in
those files, but there appears to be little in the areas I've touched.
The second contains a set of changes to source files that are not being
used
at present on my system. Therefore, they _may_ not compile. I have
visually
checked that all functions whose signature I have changed are not called
directly (across all source files) with the old signature and have also
checked
header file prototypes. However, that doesn't mean I didn't miss
something, so
this patch should be applied with a little more care.
The nature of the fixes themselves are discussed below.
---
Fixes to common problems across several files:
* Failure to declare second (always NULL) parameter on functions
registered as
METH_NOARGS methods.
- These all now have a second parameter declared as "PyObject
*NOARGS_NULL".
- I have also changed ones that already declared the parameter as
"void *ignored" etc, as I think the name makes it clear why it's
there.
If the upper-case name is bad style, feel free to change it to
something
else - as they are all now consistent, that should be a trivial
process
to change in the patch file before applying it.
* PyGetSetDef 'getter' and 'setter' functions not declaring the final
'closure'
parameter.
- These all now have a final parameter declared as "void *closure".
- I have also changed ones that already declared the parameter as
"void *context" or "void *ignored" etc, for consistency.
* The tp_clear type slot is defined as type 'inquiry' but the return value
is
ignored and in some instances, not returned at all. This is related to
the
following thread:
http://mail.python.org/pipermail/python-dev/2003-April/034433.html
frameobject.c and traceback.c were either missed when those changes
were
made, or the problems were re-introduced since.
- I have changed the functions in those files to return
[ python-Bugs-1661108 ] base64.urlsafe_b64encode() shouldn't use the = character
Bugs item #1661108, was opened at 2007-02-16 03:11 Message generated for change (Comment added) made by ryanbarrett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Barrett (ryanbarrett) Assigned to: Nobody/Anonymous (nobody) Summary: base64.urlsafe_b64encode() shouldn't use the = character Initial Comment: base64.urlsafe_b64encode() almost always returns strings that include the = character. this may be ok before the ? in a URL, but it's not OK after. it would be nice if it substituted another character for =, like it does for + and /. if this is intentional, though, and you don't want to substitute for =, the documentation should probably be changed to note that it's only safe for use before the ?. (it doesn't include that caveat now.) http://docs.python.org/lib/module-base64.html#l2h-1592 -- >Comment By: Ryan Barrett (ryanbarrett) Date: 2007-02-16 18:10 Message: Logged In: YES user_id=751286 Originator: YES after more investigation, RFC3548 does say to use the = character for padding even in the URL-safe alphabet. weird. so, it looks like the base64 module is just following the spec, and it's the spec that (seems) broken. sigh. i'm off to try to figure out why RFC3548 says = is ok in URLs... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1614460 ] python-logging compatability with Zope.
Bugs item #1614460, was opened at 2006-12-13 03:02 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&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: None Priority: 5 Private: No Submitted By: Simon Hookway (shookway) Assigned to: Vinay Sajip (vsajip) Summary: python-logging compatability with Zope. Initial Comment: I'm using Zope2.8.x and python2.4. On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it. This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification. See the included patch. -- >Comment By: Vinay Sajip (vsajip) Date: 2007-02-16 18:27 Message: Logged In: YES user_id=308438 Originator: NO The change was backported to the release24-maint branch some time ago - sorry for not making it clear. -- Comment By: Simon Hookway (shookway) Date: 2007-02-11 23:57 Message: Logged In: YES user_id=1667120 Originator: YES "fixed in 2.5" -- that is the problem, why was this fix not rolled back to python2.4? I submit this patch for those of us out there still using 2.4 and likely to be using it for a while to come. Can we have it fixed in 2.4 please. -- Comment By: SourceForge Robot (sf-robot) Date: 2006-12-30 03:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 17:13 Message: Logged In: YES user_id=308438 Originator: NO Yes, a fix was applied a while ago. -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 08:06 Message: Logged In: YES user_id=849994 Originator: NO I believe this was fixed in 2.5, but I could be mistaken. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1661745 ] finditer stuck in infinite loop
Bugs item #1661745, was opened at 2007-02-16 20:11 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=1661745&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Milan (migues) Assigned to: Gustavo Niemeyer (niemeyer) Summary: finditer stuck in infinite loop Initial Comment: Using iterator on Match Object results in infinite unbreakable loop. Attached is sample script and sample file. My OS: Win XP Pro. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661745&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1652788 ] logging formatter %(lineno)d does not work
Bugs item #1652788, was opened at 2007-02-05 23:42 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652788&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: lx_jakal (alex_petry) Assigned to: Nobody/Anonymous (nobody) Summary: logging formatter %(lineno)d does not work Initial Comment: The current line number produced by the module is "1072" which is static over all logging calls. It refers to a the denoted line in logging/__init__.py A possible patch is attached. -- >Comment By: Vinay Sajip (vsajip) Date: 2007-02-16 22:45 Message: Logged In: YES user_id=308438 Originator: NO Change checked into trunk, and will be shortly checked into release25-maint and release24-maint. -- Comment By: lx_jakal (alex_petry) Date: 2007-02-06 01:07 Message: Logged In: YES user_id=1033478 Originator: YES File Added: python-logging-2.5-fixed.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1652788&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519638 ] Unmatched Group issue
Bugs item #1519638, was opened at 2006-07-09 18:34
Message generated for change (Settings changed) made by nneonneo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bobby Xiao (nneonneo)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Unmatched Group issue
Initial Comment:
Using sre.sub[n], an "unmatched group" error can occur.
The test I used is this pattern:
sre.sub("foo(?:b(ar)|baz)","\\1","foobaz")
This will cause the following backtrace to occur:
Traceback (most recent call last):
File "", line 1, in ?
File "lib/python2.4/sre.py", line 142, in sub
return _compile(pattern, 0).sub(repl, string, count)
File "lib/python2.4/sre.py", line 260, in filter
return sre_parse.expand_template(template, match)
File "lib/python2.4/sre_parse.py", line 782, in expand_template
raise error, "unmatched group"
sre_constants.error: unmatched group
Python Version 2.4.3, Mac OS X (behaviour has been verified on
Windows 2.4.3 as well).
This behaviour, while by design, is unwanted because this type of
matching usually requests that a blank match be returned (i.e. the
example should return '')
The example that I was trying resembles the following:
sre.sub("User: (?:Registered User #(\d+)|Guest)","%USERID|\1%",data)
The intended behaviour is that the function returns "" when the user is
a guest and the user number if the user is a registered member.
However, when this function encounters a Guest, it raises an exception
and terminates, which is not what is wanted.
Perl and other regex engines behave as I have described, substituting
empty strings for unmatched groups. The code fix is relatively simple,
and would really help out for these types of things.
--
Comment By: Matt Chaput (mchaput)
Date: 2007-02-15 18:35
Message:
Logged In: YES
user_id=1249840
Originator: NO
The current behavior also makes the "sub" function useless when you need
to backreference a group that might not capture, since you have no chance
to deal with the exception.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519638 ] Unmatched Group issue
Bugs item #1519638, was opened at 2006-07-09 18:34
Message generated for change (Comment added) made by nneonneo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bobby Xiao (nneonneo)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Unmatched Group issue
Initial Comment:
Using sre.sub[n], an "unmatched group" error can occur.
The test I used is this pattern:
sre.sub("foo(?:b(ar)|baz)","\\1","foobaz")
This will cause the following backtrace to occur:
Traceback (most recent call last):
File "", line 1, in ?
File "lib/python2.4/sre.py", line 142, in sub
return _compile(pattern, 0).sub(repl, string, count)
File "lib/python2.4/sre.py", line 260, in filter
return sre_parse.expand_template(template, match)
File "lib/python2.4/sre_parse.py", line 782, in expand_template
raise error, "unmatched group"
sre_constants.error: unmatched group
Python Version 2.4.3, Mac OS X (behaviour has been verified on
Windows 2.4.3 as well).
This behaviour, while by design, is unwanted because this type of
matching usually requests that a blank match be returned (i.e. the
example should return '')
The example that I was trying resembles the following:
sre.sub("User: (?:Registered User #(\d+)|Guest)","%USERID|\1%",data)
The intended behaviour is that the function returns "" when the user is
a guest and the user number if the user is a registered member.
However, when this function encounters a Guest, it raises an exception
and terminates, which is not what is wanted.
Perl and other regex engines behave as I have described, substituting
empty strings for unmatched groups. The code fix is relatively simple,
and would really help out for these types of things.
--
>Comment By: Bobby Xiao (nneonneo)
Date: 2007-02-17 02:56
Message:
Logged In: YES
user_id=393491
Originator: YES
AFAIK the findall function works as desired in this respect: empty matches
will return empty strings.
--
Comment By: Matt Chaput (mchaput)
Date: 2007-02-15 18:35
Message:
Logged In: YES
user_id=1249840
Originator: NO
The current behavior also makes the "sub" function useless when you need
to backreference a group that might not capture, since you have no chance
to deal with the exception.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519638&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1661108 ] base64.urlsafe_b64encode() shouldn't use the = character
Bugs item #1661108, was opened at 2007-02-16 03:11 Message generated for change (Comment added) made by ryanbarrett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Barrett (ryanbarrett) Assigned to: Nobody/Anonymous (nobody) Summary: base64.urlsafe_b64encode() shouldn't use the = character Initial Comment: base64.urlsafe_b64encode() almost always returns strings that include the = character. this may be ok before the ? in a URL, but it's not OK after. it would be nice if it substituted another character for =, like it does for + and /. if this is intentional, though, and you don't want to substitute for =, the documentation should probably be changed to note that it's only safe for use before the ?. (it doesn't include that caveat now.) http://docs.python.org/lib/module-base64.html#l2h-1592 -- >Comment By: Ryan Barrett (ryanbarrett) Date: 2007-02-17 07:32 Message: Logged In: YES user_id=751286 Originator: YES i talked to harald alvestrand, and he made the good point that the = character is only problematic in URL parameter names. it's ok, if unusual, in parameter values, since the & character is used at the end the value. apart from that, though, he didn't sound like this would be a priority for the IETF to address. unfortunate, but understandable. :P so, the resolution here might just be to update the base64 documentation to say that urlsafe_b64encode's output may include the = character. another option would be to change the code to use different character for padding, which would be nicer, but wouldn't follow the spec. up to you. -- Comment By: Ryan Barrett (ryanbarrett) Date: 2007-02-16 18:10 Message: Logged In: YES user_id=751286 Originator: YES after more investigation, RFC3548 does say to use the = character for padding even in the URL-safe alphabet. weird. so, it looks like the base64 module is just following the spec, and it's the spec that (seems) broken. sigh. i'm off to try to figure out why RFC3548 says = is ok in URLs... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1661108&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
