[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-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 sharing is fine, or should some copying (which function?) be used. -- components: Interpreter Core messages: 72362 nosy: _doublep severity: normal status: open title: PEP 3121 --- PyType_Copy is missing type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 --- module state is not nul-initalized as claimed in the PEP type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 as now, at least then programmers will know something is wrong and have a chance to workaround, etc. -- nosy: +_doublep ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue3081 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue2474 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 [EMAIL PROTECTED] http://bugs.python.org/issue1617161 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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)
3 JUMP_IF_FALSE 16 (to 22)
6 POP_TOP
7 7 LOAD_FAST1 (b)
10 JUMP_IF_FALSE5 (to 18)
13 POP_TOP
8 14 LOAD_CONST 1 ('true')
17 RETURN_VALUE
18 POP_TOP
19 JUMP_FORWARD 1 (to 23)
22 POP_TOP
23 LOAD_CONST 0 (None)
26 RETURN_VALUE
After:
6 0 LOAD_FAST0 (a)
3 JUMP_IF_FALSE 16 (to 22)
6 POP_TOP
7 7 LOAD_FAST1 (b)
10 JUMP_IF_FALSE9 (to 22)
13 POP_TOP
8 14 LOAD_CONST 1 ('true')
17 RETURN_VALUE
18 POP_TOP
19 JUMP_FORWARD 1 (to 23)
22 POP_TOP
23 LOAD_CONST 0 (None)
26 RETURN_VALUE
Note that size of bytecode doesn't become smaller, however one execution
branch (jump from offset 10) becomes shorter by one JUMP_FORWARD.
Additionally, two commands at offset 18 become unreachable. However,
they will not be removed by the patch in issue1394 currently, because
there is a basic-block change at 18, where JUMP_IF_FALSE previously had
its target. If we want unreachable code be removed in such cases, we
need to make peepholer make two passes with recomputing blocks[] in
between. This would enable more optimizations.
--
components: Interpreter Core
files: jump-to-pop-optimization.diff
keywords: patch
messages: 63422
nosy: _doublep
severity: minor
status: open
title: conditional jump to a POP_TOP optimization
Added file: http://bugs.python.org/file9640/jump-to-pop-optimization.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2260
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_FAST0 (a)
3 JUMP_IF_FALSE 27 (to 33)
6 POP_TOP
12 7 LOAD_FAST1 (b)
10 JUMP_IF_FALSE 16 (to 29)
13 POP_TOP
13 14 LOAD_FAST2 (c)
17 JUMP_IF_FALSE5 (to 25)
20 POP_TOP
14 21 LOAD_CONST 1 ('true')
24 RETURN_VALUE
25 POP_TOP
26 JUMP_ABSOLUTE 34
29 POP_TOP
30 JUMP_FORWARD 1 (to 34)
33 POP_TOP
34 LOAD_CONST 0 (None)
37 RETURN_VALUE
After:
11 0 LOAD_FAST0 (a)
3 JUMP_IF_FALSE 27 (to 33)
6 POP_TOP
12 7 LOAD_FAST1 (b)
10 JUMP_IF_FALSE 20 (to 33)
13 POP_TOP
13 14 LOAD_FAST2 (c)
17 JUMP_IF_FALSE 13 (to 33)
20 POP_TOP
14 21 LOAD_CONST 1 ('true')
24 RETURN_VALUE
25 POP_TOP
26 JUMP_ABSOLUTE 34
29 POP_TOP
30 JUMP_FORWARD 1 (to 34)
33 POP_TOP
34 LOAD_CONST 0 (None)
37 RETURN_VALUE
Without the while(), target for jump at offset 17 wouldn't be optimized,
because jump to unconditional jump optimization hasn't been done yet:
it is farther in the code.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2260
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 be caught only in very special cases. I don't find it good Python interpreter not following its own rules. -- nosy: +_doublep __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2196 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue2198 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: enum GTK_RC_TOKEN_LOWEST of type GtkRcTokenType class 'gtk._gtk.RcTokenType' Traceback (most recent call last): File stdin, line 5, in module ValueError: value out of range (294 not in 0..40) Not sure what it means yet... -- nosy: +_doublep __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2199 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 for invalid (unclassed) type `invalid' ** ERROR **: file pygenum.c: line 55 (pyg_enum_repr): assertion failed: (G_IS_ENUM_CLASS(enum_class)) aborting... Aborted __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2199 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 flow would fall off of the valid bytecode string). So, there is pretty good chance that this patch will remove both the unreachable code and the fake return byte. In the worst case, we increase bytecode length by 1 byte, but we always enable peephole optimizer, which can be expected to give a much more significant gain. As your unit tests suggest, the patch doesn't always remove unreachable code, because some opcodes after which this can be done are already handled differently. Also, there might in theory be some false block boundaries (e.g. a jump from unreachable code to another piece of such code). BTW, I think that just removing #if 0'd block is not correct. I propose to convert it to a comment then, just to explain that there are more opcodes after which we can expect unreachable code and don't check only because it'd give duplicate case labels. Maybe some goto magic can handle them, don't have sources here. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 something. For this reason, if() before writing the RETURN_VALUE is not needed. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 noticed this (both cases are with patch): def f1(): return 1 x() disassembly: 3 0 LOAD_CONST 1 (1) 3 RETURN_VALUE 4 4 LOAD_GLOBAL 0 (x) 7 CALL_FUNCTION0 10 POP_TOP def f2(): return 1 x() return 2 disassembly: 3 0 LOAD_CONST 1 (1) 3 RETURN_VALUE Looking a bit further, I noticed this: if (codestr[codelen-1] != RETURN_VALUE) goto exitUnchanged; So, the patch really can't help with your first example, because peephol optimizer just bails out before real action begins. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mean, it would cost almost nothing, yet will prevent making some functions non-optimized. E.g. like this: def foo(x): if x = 0: return x * 2 raise ValueError __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 command: if BINARY_ADD matched, there is a _guaranteed_ next command, not an out-of-array failure. Such proposed fake RETURN_VALUE _must_ be unreachable, so it must not be problematic at all. If it was reachable, real codestr[] would end in reachable non-return command, which must not happen during compilation. I dunno, maybe interpreter guards against execution point falling of the bytecode string, but in any case this must not happen in non-corrupted files generated by the bytecode compiler. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 are not all that common, I'm sure there are extensions out there that do it. For Py3k things can be different. I'm not sure what would be the best way, but at least Py3k is not required to be compatible with 2.x in all aspects. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1878 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 notice set_default() method below changes a class attribute. from notify.all import * original_protector = AbstractGCProtector.default new_protector = FastGCProtector () AbstractGCProtector.default is new_protector False AbstractGCProtector.default is original_protector True Please note that this a regression. This code works as expected in 2.3 and 2.5. -- components: Interpreter Core messages: 61316 nosy: _doublep severity: major status: open title: class attribute cache failure (regression) type: behavior versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1878 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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) AbstractGCProtector.default is new_protector False AbstractGCProtector.default is original_protector True It seems that this behaviour is somewhat random. Sometimes the False/True lines are reversed, as expected. I.e. it seems that attribute cache is sometimes recomputed... __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1878 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 stdin, line 1, in module TypeError: can't set attributes of built-in/extension type 'notify.gc.AbstractGCProtector' About source code: go to http://download.gna.org/py-notify/ download, unpack and do './run-tests.py' at top level. One test fails with Python SVN precisely because of this problem. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1878 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 library, but can you guarantee that no other extension will get broken? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1878 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, line 59, in test_default_property AbstractGCProtector.set_default (original_protector) TypeError: can't set attributes of built-in/extension type 'notify.gc.AbstractGCProtector' With this code: if (PyObject_SetAttrString ((PyObject *) AbstractGCProtector_Type, default, new_protector) == -1) return NULL; __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1878 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue1393 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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:19:48) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type help, copyright, credits or license for more information. import gc len ([object for object in gc.get_objects () if isinstance (object, list)]) 25 aList = [] for i in xrange(5E5): ... aList += [[]] ... for j in xrange(10): ... aList[-1].append([] ... ... KeyboardInterrupt aList[-1].append([] KeyboardInterrupt [EMAIL PROTECTED]:~/emacs$ python Python 2.3.5 (#2, Oct 16 2006, 19:19:48) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type help, copyright, credits or license for more information. import gc len ([object for object in gc.get_objects () if isinstance (object, list)]) 25 aList = [] for i in xrange(5E5): ... aList += [[]] ... for j in xrange(10): ... aList[-1].append([]) ... __main__:1: DeprecationWarning: integer argument expected, got float del aList len ([object for object in gc.get_objects () if isinstance (object, list)]) 25 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1405 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 how the objects are different. -- nosy: +_doublep __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1417 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue1416 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
files: test.py
messages: 57277
nosy: _doublep
severity: normal
status: open
title: new keyword-only function parameters interact badly with nested functions
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8716/test.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1409
__# Note that '*,' here is important.
def foo(*, a=None):
def bar(dictionary):
dictionary['a'] = a
return dictionary
return bar
print(foo(a=42)({ }))
print(foo()({ }))
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: +_doublep __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 relate to some place in the code. In any way, I think that either createComment() should raise or toxml(), but generating non-well formed output is a bug. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: function comparing lacks NotImplemented error versions: Python 3.0 Added file: http://bugs.python.org/file8698/test.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1393 __class Anything: def __eq__(self, other): return True def __ne__(self, other): return False x = lambda: None print(x == Anything()) print(Anything() == x) y = object() print(y == Anything()) print(Anything() == y) ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Pogonyshev severity: minor status: open title: simple patch, improving unreachable bytecode removing versions: Python 2.6 Added file: http://bugs.python.org/file8699/unreachable-code.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __Index: Python/peephole.c === *** Python/peephole.c (revision 58867) --- Python/peephole.c (working copy) *** *** 550,566 case EXTENDED_ARG: goto exitUnchanged; ! /* Replace RETURN LOAD_CONST None RETURN with just RETURN */ ! /* Remove unreachable JUMPs after RETURN */ case RETURN_VALUE: ! if (i+4 = codelen) ! continue; ! if (codestr[i+4] == RETURN_VALUE ! ISBASICBLOCK(blocks,i,5)) ! memset(codestr+i+1, NOP, 4); ! else if (UNCONDITIONAL_JUMP(codestr[i+1]) !ISBASICBLOCK(blocks,i,4)) ! memset(codestr+i+1, NOP, 3); break; } } --- 550,571 case EXTENDED_ARG: goto exitUnchanged; ! /* Remove unreachable code completely */ ! #if 0 ! /* These are handled differently above */ ! case CONTINUE_LOOP: ! case JUMP_FORWARD: ! case JUMP_ABSOLUTE: ! #endif ! case RAISE_VARARGS: ! case BREAK_LOOP: case RETURN_VALUE: ! j = i + CODESIZE(codestr[i]); ! tgt = j; ! while (tgt codelen blocks[tgt] == blocks[i]) ! tgt += CODESIZE(codestr[tgt]); ! if (tgt j) ! memset(codestr+j, NOP, tgt-j); break; } } ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 properly. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1379 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
