[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 16:43
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-23 00:41
Message:
Logged In: YES
user_id=341410
I personally think that the CPython runtime should make a
best-effort to not crash when running code that makes sense.
But when CPython is running on input that is nonsensical
(in each of the examples that Armin provides, no return
value could make sense), I think that as long as the
behavior is stated clearly, it is sufficient.
Certainly it would be nice if CPython did not crash in such
cases, but I don't know if the performance penalty and code
maintenance outweigh the cases where users write bad code.
Perhaps a compile-time option, enabled by default based on
whether or not we want a safer or faster CPython. Of course
maintenance is still a chore, and it is one additional set
of calls that C extension writers may need to be aware of
(if their code can be recursively called, and they want to
participate in the infinite recursion detection).
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-20 14:46
Message:
Logged In: YES
user_id=4771
Yes, but I'm concerned that we would need to add it really really many places,
and probably forget some even then. E.g. I just thought about:
lst = [apply]
lst.append(lst)
apply(*lst)
It seems a bit hopeless, honestly...
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-20 14:22
Message:
Logged In: YES
user_id=21627
Wouldn't adding Py_EnterRecursiveCall into many places solve
the problem?
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-19 08:05
Message:
Logged In: YES
user_id=4771
This is not about the new module. The same example can be written as:
import types
class A: pass
A.__mul__ = types.MethodType(operator.mul, None, A)
If this still looks essentially like an indirect way of using the new module,
here is another example:
class A(str): __get__ = getattr
a = A('a')
A.a = a
a.a
Or, as I just found out, new-style classes are again vulnerable to the older
example based __call__, which was fixed for old-style classes:
class A(object): pass
A.__call__ = A()
A()()
I'm not denying that these examples look convoluted :-)
My point here is that we can basically build a lot of examples based only on
core (if not necessarily widely understood) language features. It appears to
go against the basic hope that CPython cannot be crashed as long as you don't
use features explicitely marked as dangerous.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-18 19:02
Message:
Logged In: YES
user_id=593130
On Windows, this caused the interactive window to just
disappear.so I suspect something similar occurred.
New is a known dangerous, use at your own risk, implementation
specific module whose use, like byte code hacking, is outside
the language proper. Both bypass normal object creation syntax
and its checks and both can create invalid objects. A hold-your-
hand inplementation would not give such access to internals.
Lib Ref 3.28 says "This module provides a low-level interface to
the interpreter, so care must be exercised when using this
module. It is possible to supply non-sensical arguments which
crash the interpreter when the object is used." Should more or
different be said?
If not, I suspect this should be closed as 'won't fix', as in 'won't
remove the inherently dangerous new module'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470
___
Python-bugs-list mailing l
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-16 01:43
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-05-23 15:06
Message:
Logged In: YES
user_id=21627
It has been a long-time policy that you should not be able
to crash the Python interpreter even with malicious code. I
think this is a good policy, because it provides people
always with a back-trace, which is much easier to analyse
than a core dump.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-23 09:41
Message:
Logged In: YES
user_id=341410
I personally think that the CPython runtime should make a
best-effort to not crash when running code that makes sense.
But when CPython is running on input that is nonsensical
(in each of the examples that Armin provides, no return
value could make sense), I think that as long as the
behavior is stated clearly, it is sufficient.
Certainly it would be nice if CPython did not crash in such
cases, but I don't know if the performance penalty and code
maintenance outweigh the cases where users write bad code.
Perhaps a compile-time option, enabled by default based on
whether or not we want a safer or faster CPython. Of course
maintenance is still a chore, and it is one additional set
of calls that C extension writers may need to be aware of
(if their code can be recursively called, and they want to
participate in the infinite recursion detection).
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-20 23:46
Message:
Logged In: YES
user_id=4771
Yes, but I'm concerned that we would need to add it really really many places,
and probably forget some even then. E.g. I just thought about:
lst = [apply]
lst.append(lst)
apply(*lst)
It seems a bit hopeless, honestly...
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-20 23:22
Message:
Logged In: YES
user_id=21627
Wouldn't adding Py_EnterRecursiveCall into many places solve
the problem?
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-19 17:05
Message:
Logged In: YES
user_id=4771
This is not about the new module. The same example can be written as:
import types
class A: pass
A.__mul__ = types.MethodType(operator.mul, None, A)
If this still looks essentially like an indirect way of using the new module,
here is another example:
class A(str): __get__ = getattr
a = A('a')
A.a = a
a.a
Or, as I just found out, new-style classes are again vulnerable to the older
example based __call__, which was fixed for old-style classes:
class A(object): pass
A.__call__ = A()
A()()
I'm not denying that these examples look convoluted :-)
My point here is that we can basically build a lot of examples based only on
core (if not necessarily widely understood) language features. It appears to
go against the basic hope that CPython cannot be crashed as long as you don't
use features explicitely marked as dangerous.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-19 04:02
Message:
Logged In: YES
user_id=593130
On Windows, this caused the interactive window to just
disappear.so I suspect something similar occurred.
New is a known dangerous, use at your own risk, implementation
specific module whose use, like byte code hacking, is outside
the language proper. Both bypass normal object creation syntax
and its checks and both can create invalid objects. A hold-your-
hand inplementation would not give such access to internals.
Lib Ref 3.28 says "This module provides a low-level interface to
the interpreter, so care must be exercised when using this
module. It is possible to supply non-sensical arguments which
crash the interpreter when the object is used.
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-16 00:43
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Michael Hudson (mwh)
Date: 2005-05-23 14:16
Message:
Logged In: YES
user_id=6656
I agree with Armin that this could easily be a never ending story. Perhaps
it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes.
It might have to, because I can't really think of a better way of doing this.
The only other approach I know is that of SBCL (a Common Lisp
implementation): it mprotects a page at the end of the stack and installs a
SIGSEGV handler (and uses sigaltstack) that knows how to abort the
current lisp operation. Somehow, I don't think we want to go down this
line.
Anybody have any other ideas?
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-23 14:06
Message:
Logged In: YES
user_id=21627
It has been a long-time policy that you should not be able
to crash the Python interpreter even with malicious code. I
think this is a good policy, because it provides people
always with a back-trace, which is much easier to analyse
than a core dump.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-23 08:41
Message:
Logged In: YES
user_id=341410
I personally think that the CPython runtime should make a
best-effort to not crash when running code that makes sense.
But when CPython is running on input that is nonsensical
(in each of the examples that Armin provides, no return
value could make sense), I think that as long as the
behavior is stated clearly, it is sufficient.
Certainly it would be nice if CPython did not crash in such
cases, but I don't know if the performance penalty and code
maintenance outweigh the cases where users write bad code.
Perhaps a compile-time option, enabled by default based on
whether or not we want a safer or faster CPython. Of course
maintenance is still a chore, and it is one additional set
of calls that C extension writers may need to be aware of
(if their code can be recursively called, and they want to
participate in the infinite recursion detection).
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-20 22:46
Message:
Logged In: YES
user_id=4771
Yes, but I'm concerned that we would need to add it really really many places,
and probably forget some even then. E.g. I just thought about:
lst = [apply]
lst.append(lst)
apply(*lst)
It seems a bit hopeless, honestly...
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-20 22:22
Message:
Logged In: YES
user_id=21627
Wouldn't adding Py_EnterRecursiveCall into many places solve
the problem?
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-19 16:05
Message:
Logged In: YES
user_id=4771
This is not about the new module. The same example can be written as:
import types
class A: pass
A.__mul__ = types.MethodType(operator.mul, None, A)
If this still looks essentially like an indirect way of using the new module,
here is another example:
class A(str): __get__ = getattr
a = A('a')
A.a = a
a.a
Or, as I just found out, new-style classes are again vulnerable to the older
example based __call__, which was fixed for old-style classes:
class A(object): pass
A.__call__ = A()
A()()
I'm not denying that these examples look convoluted :-)
My point here is that we can basically build a lot of examples based only on
core (if not necessarily widely understood) language features. It appears to
go against the basic hope that CPython cannot be crashed as long as you don't
use features explicitely marked as dangerous.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 23:43
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Armin Rigo (arigo)
Date: 2005-05-23 13:52
Message:
Logged In: YES
user_id=4771
When I thought about the same problem for PyPy, I imagined
that it would be easy to use the call graph computed by
the type inferencer ("annotator"). We would find an
algorithm that figures out the minimal number of places
that need a Py_EnterRecursiveCall so that every cycle goes
through at least one of them. For CPython it might be
possible to go down the same path if someone can find a C
code analyzer smart enough to provide the required
information -- a call graph including indirect calls through
function pointers. Not sure it's sane, though.
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-23 13:16
Message:
Logged In: YES
user_id=6656
I agree with Armin that this could easily be a never ending story. Perhaps
it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes.
It might have to, because I can't really think of a better way of doing this.
The only other approach I know is that of SBCL (a Common Lisp
implementation): it mprotects a page at the end of the stack and installs a
SIGSEGV handler (and uses sigaltstack) that knows how to abort the
current lisp operation. Somehow, I don't think we want to go down this
line.
Anybody have any other ideas?
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-23 13:06
Message:
Logged In: YES
user_id=21627
It has been a long-time policy that you should not be able
to crash the Python interpreter even with malicious code. I
think this is a good policy, because it provides people
always with a back-trace, which is much easier to analyse
than a core dump.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-23 07:41
Message:
Logged In: YES
user_id=341410
I personally think that the CPython runtime should make a
best-effort to not crash when running code that makes sense.
But when CPython is running on input that is nonsensical
(in each of the examples that Armin provides, no return
value could make sense), I think that as long as the
behavior is stated clearly, it is sufficient.
Certainly it would be nice if CPython did not crash in such
cases, but I don't know if the performance penalty and code
maintenance outweigh the cases where users write bad code.
Perhaps a compile-time option, enabled by default based on
whether or not we want a safer or faster CPython. Of course
maintenance is still a chore, and it is one additional set
of calls that C extension writers may need to be aware of
(if their code can be recursively called, and they want to
participate in the infinite recursion detection).
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-20 21:46
Message:
Logged In: YES
user_id=4771
Yes, but I'm concerned that we would need to add it really really many places,
and probably forget some even then. E.g. I just thought about:
lst = [apply]
lst.append(lst)
apply(*lst)
It seems a bit hopeless, honestly...
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-20 21:22
Message:
Logged In: YES
user_id=21627
Wouldn't adding Py_EnterRecursiveCall into many places solve
the problem?
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-19 15:05
Message:
Logged In: YES
user_id=4771
This is not about the new module. The same example can be written as:
import types
class A: pass
A.__mul__ = types.MethodType(operator.mul, None, A)
If this still looks essentially like an indirect way of using the new module,
here is another e
[ python-Bugs-1206537 ] weakref cannot handle bound methods (in contrast to docu)
Bugs item #1206537, was opened at 2005-05-22 14:37 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&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: None Priority: 5 Submitted By: Raik Gruenberg (graik) Assigned to: Raymond Hettinger (rhettinger) Summary: weakref cannot handle bound methods (in contrast to docu) Initial Comment: According to the documentation of the weakref module, weakreferences can be applied to "...class instances, functions written in Python (but not in C), methods (both bound and unbound)..." In reality, bound methods cannot be referenced (see bug 813299): import weakref ## this works: def testF( event ):pass r = weakref.ref( testF ) ## this doesnt: class EventListener: def handleEventA( self, event ): pass t = EventListener() ## gives a "dead" ref r = weakref.ref( t.handleEventA ) This behaviour is unexpected for anyone not aquainted to the inner clockwork of python and unfortunate because it, for example, prevents to keep weak references to callback methods in event handling patterns. A workaround is proposed at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253 Discussion: (minimal) Solution 1: Change the weakref documentation (preferred) Solution 2: Adapt weakref to allow references to bound methods Perhaps this bug should be converted into a documentation bug and a feature request. Python version 2.3 and 2.4 OS: Linux 2.6 -- >Comment By: Armin Rigo (arigo) Date: 2005-05-23 14:08 Message: Logged In: YES user_id=4771 Of course, the weakref documentation is ultimately right, and the problem, unrelated to bound methods, is that you always get a dead weakref if you do weakref.ref() But I'm not being particularly helpful here. A trick simpler than the cookbook proposals is to force the method object to be alive as long as the instance itself by storing it on the instance: obj = MyClass() obj.m = obj.m ref = weakref.ref(obj.m) This works because the last "obj.m" returns an existing object, as opposed to one created just-in-time. This might be mentioned in the weakref documentation with the comment that it's a general rule to be careful not to take weakrefs to short-lived object; the same problem would occur e.g. when taking a weakref to "obj.a" where "a" is a computed property. Storing the result back on "obj" -- under the same or another name -- is a workaround. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1204734 ] Documentation error?
Bugs item #1204734, was opened at 2005-05-19 05:21 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. -- >Comment By: Armin Rigo (arigo) Date: 2005-05-23 14:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202395 ] Description of string.lstrip() needs improvement
Bugs item #1202395, was opened at 2005-05-15 12:50 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&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: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. -- Comment By: liturgist (liturgist) Date: 2005-05-23 11:03 Message: Logged In: YES user_id=197677 It would also be helpful to note the definition of "whitespace" in each of the strip() methods. It appears to be defined in strip() as being identical to string.whitespace. However, I do not see a built-in whitespace for strings. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 20:18 Message: Logged In: YES user_id=593130 Over the years, several people have tripped over this and posted to c.l.p., so I think the existing text is unclear enough to arguably qualify as a buglet. In response to the same posting, I had the same thought of clarifying that the 'string' defines a set, so I support this suggestion or something similar ;-) and thank you for submitting it. -- Comment By: Roy Smith (roysmith) Date: 2005-05-15 12:55 Message: Logged In: YES user_id=390499 I notice bug #1196824 (recently submitted and closed as "not a bug") relates to the same issue. It seems more than one person has gotten confused by this :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1204734 ] Documentation error?
Bugs item #1204734, was opened at 2005-05-18 22:21 Message generated for change (Comment added) made by zhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. -- >Comment By: John Eikenberry (zhar) Date: 2005-05-23 11:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. -- Comment By: Armin Rigo (arigo) Date: 2005-05-23 07:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1207379 ] class property fset not working
Bugs item #1207379, was opened at 2005-05-24 00:02 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=1207379&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: Master_Jaf (master_jaf) Assigned to: Nobody/Anonymous (nobody) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1207466 ] installer ignores changed installation directory
Bugs item #1207466, was opened at 2005-05-24 04:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207466&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Blubb Fallo (blubbfallo) Assigned to: Nobody/Anonymous (nobody) Summary: installer ignores changed installation directory Initial Comment: concerning python-2.4.1.msi at win2000 sp4 After having spent quite some time at python.org to find out if I had to remove 2.4 before installing 2.4.1 (without any success, btw) I dared to start overinstalling. 1. Unfortunately, I didn't recognize that the suggested directory was different from where I wanted Python to stay in. Now, there seems to be no way back except completele un- and reinstalling: 2. I run the installer again and selected "change Python 2.4.1", then clicked "back", choosing the right directory, then went on to "next" and on, but my directory choice was ignored. 3. Finally, I run the installer at commandline, specifying TARGETDIR, chose the "change Python 2.4.1" radiobutton ... and again, Python was reinstalled as if TARGETDIR wasn't given. Paths containing spaces are not involved. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207466&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1207501 ] Issue in grammar
Bugs item #1207501, was opened at 2005-05-24 09:59
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=1207501&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: venkat manian (annacoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Issue in grammar
Initial Comment:
decorator ::=
"@" dotted_name ["(" [argument_list [","]]
")"] NEWLINE
--
the above line appears in the grammar for function
definition and dotted_name seems to be a non-terminal.
But, i was not able to find any instance of it again in
the grammer. It does not appear on the left-hand side.
Even in the documentation, the "dotted_name" link does
not take me anywhere.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1207509 ] Issue in grammar
Bugs item #1207509, was opened at 2005-05-24 10:36
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=1207509&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: venkat manian (annacoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Issue in grammar
Initial Comment:
decorator ::=
"@" dotted_name ["(" [argument_list [","]]
")"] NEWLINE
--
the above line appears in the grammar for function
definition and dotted_name seems to be a non-terminal.
But, i was not able to find any instance of it again in
the grammer. It does not appear on the left-hand side.
Even in the documentation, the "dotted_name" link does
not take me anywhere.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207509&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
