[issue3740] PEP 3121 --- module state is not nul-initalized as claimed in the PEP

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment: Ping. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3740> ___ ___ Python-bugs

[issue3760] PEP 3121 --- PyType_Copy is missing

New submission from Paul Pogonyshev <[EMAIL PROTECTED]>: PEP 3121 at python.org mentions PyType_Copy(). However, it doesn't seem to be present in SVN version and there is no apparent replacement. Please clarify how types should be created for different module instances --- if just

[issue2723] Truncate __len__() at sys.maxsize

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment: I'm also absolutely against having len() lying to me. This would be a welcome to bump into some other hideous error later, e.g. discarding part of data as I'd think it wasn't there. Better raise an exception

[issue3740] PEP 3121 --- module state is not nul-initalized as claimed in the PEP

New submission from Paul Pogonyshev <[EMAIL PROTECTED]>: PEP 3121 states that: "The module state will be null-initialized". This is not the case as it seems. -- components: Interpreter Core messages: 72197 nosy: _doublep severity: normal status: open title: PEP 3121 ---

[issue3081] Py_(X)SETREF macros

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment: Just to note, I proposed similar macro on the mailing list under the name Py_ASSIGN. -- nosy: +_doublep ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2474] fset not working

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment: This is caused by EWAssayParam being an old-style class. Dunno if it is a bug in Python or not. -- nosy: +_doublep __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2260] conditional jump to a POP_TOP optimization

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment: Also, this is the reason for while() in the patch. Consider this function: def bar(a, b, c): if a: if b: if c: return 'true' Before the patch: 11 0 LOAD_FAST

[issue2260] conditional jump to a POP_TOP optimization

New submission from Paul Pogonyshev <[EMAIL PROTECTED]>: This optimization targets a common case of functions like this: def foo(a, b): if a: if b: return 'true' Before the optimization: 6 0 LOAD_FAST0 (a)

[issue1617161] Instance methods compare equal when their self's are equal

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment: Since I'm not on python-dev, I'll mention here that the new behavior makes no sense to me at all. Which is best highlighted by Frank in msg63414. -- nosy: +_doublep _ Tracker &

[issue2196] Fix hasattr's exception problems

Paul Pogonyshev added the comment: I think it would be better not to hardcode specific 2 exceptional cases and indeed follow that second way of instanceof(..., Exception). I think it was introduced exactly to separate "things that can be caught by default" from "things that may

[issue2246] itertools.groupby() leaks memory with circular reference

Paul Pogonyshev added the comment: Damn, I wrote a patch too ;) -- nosy: +_doublep __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2246> __ ___ Pyth

[issue2198] code_hash() can be the same for different code objects

Paul Pogonyshev added the comment: Hashes being equal for different objects cannot be a bug. At most an enhancement request... -- nosy: +_doublep __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue2199] cPickle error with gtk GEnum classes

Paul Pogonyshev added the comment: Please close this issue. It is a PyGObject bug, nothing to do with Python: http://bugzilla.gnome.org/show_bug.cgi?id=519645 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue2199] cPickle error with gtk GEnum classes

Paul Pogonyshev added the comment: It doesn't seem 'pickle' itself works: >>> import pickle >>> import gtk >>> s = pickle.dumps (gtk.RC_TOKEN_LOWEST, pickle.HIGHEST_PROTOCOL) >>> pickle.loads (s) __main__:1: Warning: cannot retrieve class

[issue2199] cPickle error with gtk GEnum classes

Paul Pogonyshev added the comment: Using slightly modified PyGObject (so that it gives more useful error message in pyg_enum_new) and adding 'raise' in the end of attached example, I got this: Traceback (most recent call last): File "", line 5, in ValueError: value out

[issue1394] simple patch, improving unreachable bytecode removing

Paul Pogonyshev added the comment: Actually, it is even better. Since you don't increment codelen, that extra RETURN_VALUE is "virtual" in that it acts as a sentinel, but will not appear in the resulting bytecode. You can test this by backing out the patch and disassembling

[issue1394] simple patch, improving unreachable bytecode removing

Paul Pogonyshev added the comment: Well, I cannot guarantee it will _always_ be eliminated, since I too don't really know when generated bytecode can (currently) end in non-return. However, if before it ended in non-return, that non-return must have been unreachable, obviously (else code

[issue1394] simple patch, improving unreachable bytecode removing

Paul Pogonyshev added the comment: Thanks for writing the test. Yes, I did read the comment. As I understood it, RETURN_VALUE is needed only so that various optimization can assume codestr[] cannot suddenly end without one. E.g. if you match for BINARY_ADD, you can safely check the next

[issue1394] simple patch, improving unreachable bytecode removing

Paul Pogonyshev added the comment: Speaking of which, I propose that codestr[] array is made one byte longer and RETURN_VALUE opcode wrote in that extra byte. It will be removed by this patch anyway (if it is accepted), but we'll remove a way to accidentally disable peephole optimizer. I

[issue1394] simple patch, improving unreachable bytecode removing

Paul Pogonyshev added the comment: Yes, help with unit tests would be appreciated. Especially since it is not supposed to fix anything, so I'm not sure what unit tests should be like... BTW, trying to understand why the patch didn't remove unreachable code in your first example, I no

[issue1878] class attribute cache failure (regression)

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

[issue1878] class attribute cache failure (regression)

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&quo

[issue1878] class attribute cache failure (regression)

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 l

[issue1878] class attribute cache failure (regression)

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] class attribute cache failure (regression)

Paul Pogonyshev added the comment: Weird. Does it even run with a stable Python (not trunk)? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1878> __ ___ Pyth

[issue1878] class attribute cache failure (regression)

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 "", line 1, in TypeError: can't set attributes of built-in/extension t

[issue1878] class attribute cache failure (regression)

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) >>> Abstr

[issue1878] class attribute cache failure (regression)

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] class attribute cache failure (regression)

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 n

[issue1393] function comparing lacks NotImplemented error

Paul Pogonyshev added the comment: I'd like to ping this issue as I think it is important enough (core is affected). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue1416] @prop.setter decorators

Paul Pogonyshev added the comment: Looks great (regardless of how this is implemented). I always hated this def get_foo / def set_foo / foo = property (get_foo, set_foo). -- nosy: +_doublep __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1417] Weakref not working properly

Paul Pogonyshev added the comment: Because self.bla is a bound-method object, which is created and then instantly deleted as unreferenced. This is not a bug, it is expected. >>> class X: ... def foo (self): pass ... >>> x = X () >>> x.foo is x.foo False Note ho

[issue1405] Garbage collection not working correctly in Python 2.3

Paul Pogonyshev added the comment: Meh, copied too much. Disregard first part, second shows it. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1405> __ ___ Pyth

[issue1405] Garbage collection not working correctly in Python 2.3

Paul Pogonyshev added the comment: Looks like the memory _is_ freed. As Guido said, "It may be available for reallocation within Python, just not given back to the operating system". I suggest closing this as invalid. [EMAIL PROTECTED]:~$ python Python 2.3.5 (#2, Oct 16 2006, 19:1

[issue1405] Garbage collection not working correctly in Python 2.3

Paul Pogonyshev added the comment: See if gc.set_threshold (0, 0, 0) helps. -- nosy: +_doublep __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1405> __ __

[issue1390] toxml generates output that is not well formed

Paul Pogonyshev added the comment: I think unexpected exception in toxml() is not worse than producing unreadable output. With createComment() it is different, since you can e.g. create a temporary DOM tree only to discard it later and never serialize

[issue1409] new keyword-only function parameters interact badly with nested functions

New submission from Paul Pogonyshev: Attached scripts fails with 'NameError: free variable 'a' referenced before assignment in enclosing scope'. If you remove '*' in function parameter list, it works. I think it is a bug. -- components: Interpreter Core

[issue1390] toxml generates output that is not well formed

Paul Pogonyshev added the comment: Well, it seems that allows createComment() in minidom to raise something implementation/language specific. I personally would prefer this (e.g. a ValueError) instead of raising on serialization step, as I prefer early error checks, when these checks obviously

[issue1390] toxml generates output that is not well formed

Paul Pogonyshev added the comment: Looks like bad design on W3 part: postponing an error happening, though it wouldn't be difficult to check right in createComment(). But I guess minidom should still be changed to conform to standard. -- nosy: +_do

[issue1394] simple patch, improving unreachable bytecode removing

New submission from Paul Pogonyshev: This patch improves bytecode output, by removing unreachable code. It doesn't target special cases, as now, but provides a generic implementation. -- components: Interpreter Core files: unreachable-code.diff messages: 57141 nosy: Paul Pogon

[issue1393] function comparing lacks NotImplemented error

New submission from Paul Pogonyshev: I believe attached script demonstrates a bug in Python 3000. As far as I can tell, it should print four times 'True'. -- components: Interpreter Core files: test.py messages: 57135 nosy: Paul Pogonyshev severity: normal status: open title

[issue1379] reloading imported modules sometimes fail with 'parent not in sys.modules' error

Paul Pogonyshev added the comment: Thank you for the commit. I just had a problem with my package, and since I was not sure if it was a bug in Py3k or the package, I went to debugging the former and found this. I just didn't know how to work with Unicode strings pro

[issue1379] reloading imported modules sometimes fail with 'parent not in sys.modules' error

New submission from Paul Pogonyshev: This is apparently because sys.modules contains Unicode (str) keys, while 'parentname' is an old-style string. Attached patch seems to fix it, but I have no idea if it is correct in principle -- components: Interpreter Core files: reloadin