[issue3219] repeated keyword arguments
New submission from ganges master <[EMAIL PROTECTED]>:
under python 2.5 (and possibly 2.6 beta), the following code runs
successfully:
>>> def f(**kwargs):
... print kwargs
...
>>> f(a=5,b=7,a=8)
{'a': 8, 'b': 7}
while in python 2.4, it fails as expected (complaining that "a" is given
twice")
http://mail.python.org/pipermail/python-dev/2008-June/080782.html
--
components: Interpreter Core
messages: 68847
nosy: gangesmaster
severity: normal
status: open
title: repeated keyword arguments
type: behavior
versions: Python 2.5, Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3219>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7902] relative import broken
New submission from ganges master : the relative-import mechanism is broken... at least on python2.6 but i'd guess on later versions as well. consider this package layout: /tmp/foo/ /tmp/foo/__init__.py /tmp/foo/bar.py where bar.py is: # note this is a relative import and should fail! from .os import walk print walk # and this should also fail from . import os print os running it yields a bug: $ PYTHONPATH="/tmp" python Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import foo.bar # <<<< ?!?! Traceback (most recent call last): File "", line 1, in File "/tmp/foo/bar.py", line 4, in from . import os ImportError: cannot import name os "from . import os" fails as expected, but "from .os import walk" works -- although it should obviously fail too. -tomer -- components: Interpreter Core files: bar.py messages: 99176 nosy: gangesmaster severity: normal status: open title: relative import broken versions: Python 2.6 Added file: http://bugs.python.org/file16201/bar.py ___ Python tracker <http://bugs.python.org/issue7902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7902] relative import broken
ganges master added the comment: i believe brett is in charge of this, adding him to the noisy. sorry if it's not you :) -- nosy: +brett.cannon ___ Python tracker <http://bugs.python.org/issue7902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1615] descriptor protocol bug
New submission from ganges master:
it seems the code of PyObject_GenericGetAttr, which invokes the
descriptor protocol, silences any AttributeErrors raised by the
descriptor, for classes that also define __getattr__. it should
propagate up rather than being silently ignored.
the attached example is quite artificial, but it's a simplification of
real world code i had hard time debugging. turned out i misspelled an
attribute name inside the property getter function, which raised an
AttributeError as expected -- but the exception i got was quite
misleading, saying the instance has no attribute named so.
this bug only happens when the class defines a custom __getattr__. see
attached demo file for details.
--
components: Interpreter Core
files: demo.txt
messages: 58581
nosy: gangesmaster
severity: normal
status: open
title: descriptor protocol bug
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8943/demo.txt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1615>
__only happens when the class defines a custom __getattr__:
>>> class Foo(object):
... def __getattr__(self, name):
... if name == "spam":
... return 17
... else:
... raise AttributeError("%s object has no attribute %r" %
... (self.__class__.__name__, name))
... @property
... def bacon(self):
... return int.lalala
...
>>>
>>> f = Foo()
>>> f.spam
17
>>> f.bacon
Traceback (most recent call last):
File "", line 1, in
File "", line 7, in __getattr__
AttributeError: Foo object has no attribute 'bacon' <<-- expected 'int object
has no attribute lalala'
>>>
without a custom __getattr__ works as expected
>>> class Bar(object):
... def __init__(self):
... self.x = 17
...
... @property
... def bacon(self):
... return int.lalala
...
>>> b = Bar()
>>> b.x
17
>>> b.bacon
Traceback (most recent call last):
File "", line 1, in
File "", line 7, in bacon
AttributeError: type object 'int' has no attribute 'lalala'
>>>___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1615] descriptor protocol bug
ganges master <[EMAIL PROTECTED]> added the comment: here's a short example of the bug >>> class Foo(object): ... def __getattr__(self, name): ... return 42 ... @property ... def bacon(self): ... return int.lalala ... @property ... def eggs(self): ... return 17 ... >>> f = Foo() >>> f.bacon # raises an AttributeError, and silently ignores it 42 >>> f.eggs 17 >>> are there any news in this front? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1615> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14737] subprocess.Popen pipes not working
New submission from ganges master : Attempting to read from stdout of a running process seems broken on Python3.2. I've been able to reproduce this on Ubuntu 11.4 and Windows 7 (with /bin/sh installed as part of git for windows) Python 3.2 (r32:88445, Dec 8 2011, 15:26:51) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from subprocess import Popen, PIPE >>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE) >>> p.stdin.write(b"echo hello\n") 11 >>> p.stdout.readline() >>> from subprocess import Popen, PIPE >>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE) >>> p.stdin.write(b"echo hello\n") 11 >>> p.stdout.read(2) For comparison, on python 2.7 (again, linux and windows: Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from subprocess import Popen, PIPE >>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE) >>> p.stdin.write(b"echo hello\n") >>> p.stdout.readline() 'hello\n' >>> -- components: Library (Lib) messages: 160075 nosy: gangesmaster priority: normal severity: normal status: open title: subprocess.Popen pipes not working versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14737> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14737] subprocess.Popen pipes not working
ganges master added the comment: hmm, it does work when i call flush, but it works perfectly fine without flushing on python2.x... i guess this has to do with str/bytes again. maybe this should be documented somewhere? thanks for the tip though. -- ___ Python tracker <http://bugs.python.org/issue14737> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16741] `int()`, `float()`, etc think python strings are null-terminated
New submission from ganges master:
I'm not sure if it's a bug or just an inconvenience, but when a string
containing \x00 is passed to int/float/etc, they return a misleading exception:
>>> int("abc")
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: 'abc'
>>> int("\x00abc")
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: ''
>>> float("\x00abc")
Traceback (most recent call last):
File "", line 1, in
ValueError: could not convert string to float:
I noticed the code does actually try to handle it:
http://hg.python.org/cpython/file/39803c20c9bf/Objects/intobject.c#l1066
but still, the reported error is very misleading.
--
components: Interpreter Core
messages: 177863
nosy: gangesmaster
priority: normal
severity: normal
status: open
title: `int()`, `float()`, etc think python strings are null-terminated
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue16741>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5508] maximum recursion depth exceeded in __subclasscheck__
New submission from ganges master : this is similar to bug #5370, but this for is a different reason. also, i have seen several sites on google that mention it, so it has happened to quite a few people. the bug is that when calling dir() on a object, it looks for __members__ and __methods__, which might not exist, thus invoking __getattr__ (if it exists). if __getattr__ fails, say, due to a never ending recusion, the exception is silently swallowed. this was the behavior in py2.5. since 2.6, it emits a warning (that looks like PyErr_WriteUnraisable) with the strangest message: Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in ignored this is very confusing. either dir() raises this exception, or silently ignore it, but displaying this message is only confusing. i haven't been able to detect why this happens: * the source of this exception, merge_list_attr, calls PyErr_Clear * nobody seems to call PyErr_WriteUnraisable here's a snippet: class Foo(object): def __getattr__(self, name): return self.x # which will recursively call __getattr__ >>> f = Foo() >>> print dir(f) Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in ignored Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in ignored ['__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattr__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__'] -- components: Interpreter Core messages: 83752 nosy: gangesmaster, georg.brandl severity: normal status: open title: maximum recursion depth exceeded in __subclasscheck__ type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5508> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
