Changes by Jesús Cea Avión [EMAIL PROTECTED]:
--
nosy: +jcea
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
___
___
Python-bugs-list mailing list
Guido van Rossum [EMAIL PROTECTED] added the comment:
I like Armin's latest proposal: have Py_TPFLAGS_DEFAULT include
Py_TPFLAGS_HAVE_VERSION_TAG when compiling the core only. ISTR there's
a way to do this, but I can't find it right now.
___
Python tracker
Guido van Rossum [EMAIL PROTECTED] added the comment:
Please review the patch here: http://codereview.appspot.com/3005
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
___
Guido van Rossum [EMAIL PROTECTED] added the comment:
Submitted as r65874.
I will block this for 3.0; 3.0 extensions that want to mess with tp_dict
must explicitly disable this flag.
--
resolution: - fixed
status: open - closed
___
Python tracker
Benjamin Peterson [EMAIL PROTECTED] added the comment:
Do we want a test?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
___
___
Python-bugs-list mailing
Guido van Rossum [EMAIL PROTECTED] added the comment:
Sure, go right ahead.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
___
___
Python-bugs-list mailing
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Guido, what say you, live with it, revert it, or apply
Py_TPFLAGS_HAVE_VERSION_TAG to all core types?
--
assignee: arigo - gvanrossum
nosy: +gvanrossum, rhettinger
___
Python tracker [EMAIL
Armin Rigo [EMAIL PROTECTED] added the comment:
Maybe there is a better solution along the following line: conditionally
define Py_TPFLAGS_DEFAULT so that when compiling the Python core it
includes the Py_TPFLAGS_HAVE_VERSION_TAG, but when compiling extension
modules it does not. This should
Benjamin Peterson [EMAIL PROTECTED] added the comment:
Ping
--
nosy: +benjamin.peterson
priority: critical - release blocker
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
___
Armin Rigo added the comment:
I don't see in general how the patch can be kept compatible with
extension modules that change the tp_dict of arbitrary types. All I can
think of is a way to be safe against extension modules that only change
the tp_dict of their own non-heap types (i.e. types
Changes by Georg Brandl:
--
priority: - urgent
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
__
___
Python-bugs-list mailing list
Unsubscribe:
Georg Brandl added the comment:
We can of course add something like in #1229239, which allows type
attributes to be set with PyObject_SetAttr, thereby updating the cache.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
Paul Pogonyshev added the comment:
I personally think that this bug is a showstopper for the caching patch
in 2.6. Well, the problem can be deemed insignificant, but it is sure a
break of backward compatibility and, worse yet, it results in _very_
obscure fails. Even if type dictionary changes
New submission from Paul Pogonyshev:
I have a regression from Python 2.5 to Python SVN (would-be-2.6). I
believe this because of class attribute caching. The problem shown
below happens because AbstractGCProtector is an extension class. So,
Python interpreter doesn't have a chance to notice
Paul Pogonyshev added the comment:
Eh, disregard that, I missed one line with set_default() call. Still,
the unit test fails...
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
__
Paul Pogonyshev added the comment:
OK, here it is:
from notify.all import *
original_protector = AbstractGCProtector.default
new_protector = FastGCProtector ()
AbstractGCProtector.set_default (new_protector)
AbstractGCProtector.default is new_protector
False
AbstractGCProtector.default is
Paul Pogonyshev added the comment:
set_default() is a static method to set 'default'. Because of this:
AbstractGCProtector.default = 42
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: can't set attributes of built-in/extension type
'notify.gc.AbstractGCProtector'
Georg Brandl added the comment:
It would be very interesting to know what set_default() actually does.
IOW, without the source code of the extension module we can't do
anything about this.
--
nosy: +georg.brandl
__
Tracker [EMAIL PROTECTED]
Georg Brandl added the comment:
I'm sorry, but I can't get this to run. With a clean 0.1.14 tarball, I get
Building extension...
running build_ext
building 'notify.gc' extension
creating build
creating build/temp.linux-i686-2.5
creating build/temp.linux-i686-2.5/notify
i686-pc-linux-gnu-gcc
Paul Pogonyshev added the comment:
Weird. Does it even run with a stable Python (not trunk)?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
__
___
Python-bugs-list mailing
Paul Pogonyshev added the comment:
Can you run the pasted script (from the third comment) manually then?
The crash might be related to the bug in question.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
__
Georg Brandl added the comment:
Yes, runs fine with 2.5.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
__
___
Python-bugs-list mailing list
Unsubscribe:
Georg Brandl added the comment:
I've now built my trunk python without debugging enabled, and can
reproduce your problem.
Armin: the extension module directly modifies an extension type's
tp_dict -- what should it do instead to make the cache happy?
--
assignee: - arigo
nosy: +arigo
Paul Pogonyshev added the comment:
Even if there is an easy workaround for the extension (or even a fix, if
modifying 'tp_dict' is not legal), I don't think it would be acceptable
to make a backward-incompatible change in 2.6. I mean, sure Py-notify
is by no means a widely-used library, but can
Amaury Forgeot d'Arc added the comment:
The issue seems similar to the one we had in ctypes when the method
attribute cache was implemented.
Ctypes was corrected in r59943. Maybe similar changes are needed for
this extension.
For example,
PyDict_SetItemString
Paul Pogonyshev added the comment:
It doesn't help:
ERROR: test_default_property (test._gc.AbstractGCProtectorTestCase)
--
Traceback (most recent call last):
File /home/paul/notify/test/_gc.py, line 59, in
26 matches
Mail list logo
