[ python-Feature Requests-487738 ] weaklist
Feature Requests item #487738, was opened at 2001-11-30 20:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487738&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: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-27 09:02 Message: Logged In: YES user_id=80475 Weaksets would not be warranted unless the use cases demonstrated needs for methods unique to sets (intersection, union, etc). Otherwise, weakdictionaries would suffice and we could avoid bloating the module. Also, I'm not sure weaklists are a good idea. First, it is not clear that the subscription use case can be reliably implemented with gc as the primary means of unsubscribing -- traditionally, that is done with an explicit unsubscribe() call issued by the subscriber. Second, weaklists only have a differential advantage when it comes to maintaining insertion order. It is not clear that that feature is really useful. What is clear is that the approach incurs extra costs for maintaing order and O(n) removal time. When order tracking is necessary, there are reasonable implementations using weakkeydictionaries with the entry values being a sequence number indicating creation order. With that data structure, group notification is still simple: for subscriber in sorted(wkd, key=wkd.__getitem__): self.notify(subscriber, message) This approach incurs an O(n log n) sort cost for each group notify but has only an O(1) deletion cost which is an improvement over weaklists. The only way I see around the deletion time issue is to have a weakdoublylinked list which would allow O(1) deletions, appends, and O(n) iteration. None of this came up on the referenced newsgroup posting because there was NO active discussion. IOW, the idea has not shown any demand and has not been through the basic due diligence needed to tease out the best approach. I recommend leaving this as a recipe until we see a battlehardened implementation, a convincing use case, and some user demand. -- Comment By: S. Kochen (g-lite) Date: 2005-07-27 06:51 Message: Logged In: YES user_id=890349 I'm not sure if either is more useful than the other, they both seem to have their advantages. It looks like a set would work for the links I mentioned, but I'd personally like to have the ability to connect to a signal/event with priority, thus needing a list. A weak set could possibly be implemented on top of WeakKeyDictionary? Have weak sets already been implemented somewhere? -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-07-26 20:19 Message: Logged In: YES user_id=3066 This might be interesting to have. Would this be more useful than, say, a weak set? Ordering may be important for the publish/subscribe use case, at least to ensure predictability. I've not looked at the contributed code, so can't make any comment on that. -- Comment By: S. Kochen (g-lite) Date: 2005-07-26 18:16 Message: Logged In: YES user_id=890349 Mind if I bring this back up? This doesn't seem to be in yet. I didn't look at the implementation, but as for motivation... Andres mentioned his original motivation on a list: http://aspn.activestate.com/ASPN/Mail/Message/python-list/929285 I've also seen it duplicated in this recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056 I'd like to see it in for the same reason. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. -- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 20:07 Message: Logged
[ python-Feature Requests-487738 ] weaklist
Feature Requests item #487738, was opened at 2001-11-30 20:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487738&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: 4
Submitted By: Andres Tuells (atuells)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: weaklist
Initial Comment:
WeakList are list whose entries are referenced weakly.
When the object is gc it is deleted from the weaklist
(and from its iterators). To be added to weakref.py
--
>Comment By: Tim Peters (tim_one)
Date: 2005-07-27 14:00
Message:
Logged In: YES
user_id=31435
FYI, ZODB has a WeakSet implementation, in utils.py here:
http://svn.zope.org/ZODB/trunk/src/ZODB/
I wouldn't add this to the core -- it's very specific to ZODB's
needs. For example, it actually uses a weak value
dictionary, because ZODB can't assume the set elements
are usably comparable or hashable.
One thing that "should be" addressed in the core is explained
in a long comment there: the core weak containers don't
supply a sane way to iterate over their weakly referenced
containees. You either risk unpredictable "dict changed size
during iteration" exceptions, or unboundedly worse gc
behavior (read the comment for more detail). The ZODB
WeakSet implementation has to break into the weak-value
dict implementation to supply a partially sane way to iterate
over its elements ("partially" means it's not incremental, and
exposes weakrefs to the client; OTOH, it doesn't suffer
mystery "dict changed size" exceptions, and plays nicely
with gc).
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-27 10:02
Message:
Logged In: YES
user_id=80475
Weaksets would not be warranted unless the use cases
demonstrated needs for methods unique to sets (intersection,
union, etc). Otherwise, weakdictionaries would suffice and
we could avoid bloating the module.
Also, I'm not sure weaklists are a good idea. First, it is
not clear that the subscription use case can be reliably
implemented with gc as the primary means of unsubscribing --
traditionally, that is done with an explicit unsubscribe()
call issued by the subscriber.
Second, weaklists only have a differential advantage when it
comes to maintaining insertion order. It is not clear that
that feature is really useful. What is clear is that the
approach incurs extra costs for maintaing order and O(n)
removal time.
When order tracking is necessary, there are reasonable
implementations using weakkeydictionaries with the entry
values being a sequence number indicating creation order.
With that data structure, group notification is still simple:
for subscriber in sorted(wkd, key=wkd.__getitem__):
self.notify(subscriber, message)
This approach incurs an O(n log n) sort cost for each group
notify but has only an O(1) deletion cost which is an
improvement over weaklists. The only way I see around the
deletion time issue is to have a weakdoublylinked list which
would allow O(1) deletions, appends, and O(n) iteration.
None of this came up on the referenced newsgroup posting
because there was NO active discussion. IOW, the idea has
not shown any demand and has not been through the basic due
diligence needed to tease out the best approach. I recommend
leaving this as a recipe until we see a battlehardened
implementation, a convincing use case, and some user demand.
--
Comment By: S. Kochen (g-lite)
Date: 2005-07-27 07:51
Message:
Logged In: YES
user_id=890349
I'm not sure if either is more useful than the other, they
both seem to have their advantages.
It looks like a set would work for the links I mentioned,
but I'd personally like to have the ability to connect to a
signal/event with priority, thus needing a list.
A weak set could possibly be implemented on top of
WeakKeyDictionary? Have weak sets already been implemented
somewhere?
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-07-26 21:19
Message:
Logged In: YES
user_id=3066
This might be interesting to have. Would this be more
useful than, say, a weak set? Ordering may be important for
the publish/subscribe use case, at least to ensure
predictability.
I've not looked at the contributed code, so can't make any
comment on that.
--
Comment By: S. Kochen (g-lite)
Date: 2005-07-26 19:16
Message:
Logged In: YES
user_id=890349
Mind if I bring this back up? This doesn't seem to be in
yet. I
[ python-Bugs-1231069 ] ioctl has problem with -ive request codes
Bugs item #1231069, was opened at 2005-07-01 17:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&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: Barry Alan Scott (barry-scott) Assigned to: Michael Hudson (mwh) Summary: ioctl has problem with -ive request codes Initial Comment: On Linux many ioctl request code values cannot be passed to ioctl because it assumes that the values are signed ints. Value with the top bit set 0x800 are common. Changing the PyArg_ParseTuple calls to use "I" instead of "i" fixes the problem. This may well also be the issue with bug 1112949 "ioctl has problems on 64 bit machines". The attached patch fixes the problem in 2.4.1 and was tested on FC4. -- >Comment By: Michael Hudson (mwh) Date: 2005-07-27 21:25 Message: Logged In: YES user_id=6656 Finally committed this as: Modules/fcntlmodule.c revision 2.44 Misc/NEWS revision 1.1326 Thanks, and sorry for the delay... -- Comment By: Barry Alan Scott (barry-scott) Date: 2005-07-18 11:57 Message: Logged In: YES user_id=28665 I've messed up attchments on SF before but the patch downloads for me. Barry -- Comment By: Michael Hudson (mwh) Date: 2005-07-03 15:50 Message: Logged In: YES user_id=6656 The patch seems to be empty (!?) Good idea, although not goo enough for me to fight CVS over dialup... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1231069 ] ioctl has problem with -ive request codes
Bugs item #1231069, was opened at 2005-07-01 17:24 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Michael Hudson (mwh) Summary: ioctl has problem with -ive request codes Initial Comment: On Linux many ioctl request code values cannot be passed to ioctl because it assumes that the values are signed ints. Value with the top bit set 0x800 are common. Changing the PyArg_ParseTuple calls to use "I" instead of "i" fixes the problem. This may well also be the issue with bug 1112949 "ioctl has problems on 64 bit machines". The attached patch fixes the problem in 2.4.1 and was tested on FC4. -- Comment By: Michael Hudson (mwh) Date: 2005-07-27 21:25 Message: Logged In: YES user_id=6656 Finally committed this as: Modules/fcntlmodule.c revision 2.44 Misc/NEWS revision 1.1326 Thanks, and sorry for the delay... -- Comment By: Barry Alan Scott (barry-scott) Date: 2005-07-18 11:57 Message: Logged In: YES user_id=28665 I've messed up attchments on SF before but the patch downloads for me. Barry -- Comment By: Michael Hudson (mwh) Date: 2005-07-03 15:50 Message: Logged In: YES user_id=6656 The patch seems to be empty (!?) Good idea, although not goo enough for me to fight CVS over dialup... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser
Bugs item #1246405, was opened at 2005-07-28 01:07 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=1246405&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: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1
Bugs item #1246473, was opened at 2005-07-27 19:18 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=1246473&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: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1 for co_firstlineno
Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&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: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) >Summary: line numbers off by 1 for co_firstlineno Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1 in dis
Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&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: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) >Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1 in dis
Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&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: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1 in dis
Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&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: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-27 20:59 Message: Logged In: YES user_id=357491 I have test_dis now passing thanks to some refactoring to handle the initial line. Now I just need to try to fix test_bug_708901. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1 in dis
Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&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: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-27 22:25 Message: Logged In: YES user_id=357491 I don't think this last problem is easily fixed. If you look at the AST, only statements have a lineno attribute. But it is an expression that is on another line from the main line of the statement. I cannot think of any way to get the line information from the statement without adding a lineno attribute to expressions and removing it from statements. That should give the coverage needed to know when another line is being outputted. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 20:59 Message: Logged In: YES user_id=357491 I have test_dis now passing thanks to some refactoring to handle the initial line. Now I just need to try to fix test_bug_708901. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1 in dis
Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&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: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- >Comment By: Brett Cannon (bcannon) Date: 2005-07-27 22:51 Message: Logged In: YES user_id=357491 Rev. 1.1.2.110 of Python/newcompile.c has the fix for test_dis:test_dis. The more thinking I do about it the more I realize that expression nodes in the AST will need to keep a lineno attribute in order to have lnotab to be set properly. That will not be a fun patch to do. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 22:25 Message: Logged In: YES user_id=357491 I don't think this last problem is easily fixed. If you look at the AST, only statements have a lineno attribute. But it is an expression that is on another line from the main line of the statement. I cannot think of any way to get the line information from the statement without adding a lineno attribute to expressions and removing it from statements. That should give the coverage needed to know when another line is being outputted. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 20:59 Message: Logged In: YES user_id=357491 I have test_dis now passing thanks to some refactoring to handle the initial line. Now I just need to try to fix test_bug_708901. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
