[ python-Feature Requests-1209664 ] calling it revert is fine with me
Feature Requests item #1209664, was opened at 2005-05-27 07:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: calling it revert is fine with me Initial Comment: Calling it revert is fine with me. I don't want to get into an editor war thing, let's just say emacs is what I've always used; it's not a matter of any single "killer feature", it's a highly integrated system and I do everything in it (shell, news reader, email, syntax driven editing for N different languages, etc). I do use IDLE sometimes but comparing IDLE to Emacs is almost like comparing it to Eclipse. They're just light years apart. Btw re editor wars, I'm reminded of the T-shirt with a kid asking "Why are we running from the police, daddy?". The dad answers "Because we use emacs, son. They use vi". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209671 ] dict.popitem documentation should mention empty dict case
Bugs item #1209671, was opened at 2005-05-27 00:49 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=1209671&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: William Chang (misterwilliam) Assigned to: Nobody/Anonymous (nobody) Summary: dict.popitem documentation should mention empty dict case Initial Comment: Currently the documentation in the Python Library Reference entry for Mapping Types does not mention what happens when dict.popitem() is called on an empty mapping. I think that the documentation should mention that a KeyError exception is raised. (At least this is what happens when I try it in the official Python 2.4 release with a dictionary.) If this omission was intentional to give room for future implementors of python/mappings I feel that this should at least be mentioned in the documentation to remind programmers this behavior is not specified. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209671 ] dict.popitem documentation should mention empty dict case
Bugs item #1209671, was opened at 2005-05-27 00:49 Message generated for change (Comment added) made by misterwilliam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: William Chang (misterwilliam) Assigned to: Nobody/Anonymous (nobody) Summary: dict.popitem documentation should mention empty dict case Initial Comment: Currently the documentation in the Python Library Reference entry for Mapping Types does not mention what happens when dict.popitem() is called on an empty mapping. I think that the documentation should mention that a KeyError exception is raised. (At least this is what happens when I try it in the official Python 2.4 release with a dictionary.) If this omission was intentional to give room for future implementors of python/mappings I feel that this should at least be mentioned in the documentation to remind programmers this behavior is not specified. -- >Comment By: William Chang (misterwilliam) Date: 2005-05-27 00:51 Message: Logged In: YES user_id=1286263 I wasn't being very precise when I substituted dict for mapping types in the summary. I'm so used to thinking of them interchangeablely. I suppose it might matter though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c
Bugs item #1185883, was opened at 2005-04-19 13:07 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&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: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kristján Valur (krisvale) Assigned to: Tim Peters (tim_one) Summary: PyObject_Realloc bug in obmalloc.c Initial Comment: obmalloc.c:835 If the previous block was not handled by obmalloc, and the realloc is for growing the block, this memcpy may cross a page boundary and cause a segmentation fault. This scenario can happen if a previous allocation failed to successfully allocate from the obmalloc pools, due to memory starvation or other reasons, but was successfully allocated by the c runtime. The solution is to query the actual size of the allocated block, and copy only so much memory. Most modern platforms provide size query functions complementing the malloc()/free() calls. on Windows, this is the _msize () function. -- >Comment By: Michael Hudson (mwh) Date: 2005-05-27 10:35 Message: Logged In: YES user_id=6656 Ping! -- Comment By: Tim Peters (tim_one) Date: 2005-04-19 16:34 Message: Logged In: YES user_id=31435 krisvale: Thank you for the very clear explanation. Even I understand this now . We won't use _msize here -- Python has to run under dozens of compilers and C libraries, and it's saner to give up on this "optimization" completely than to introduce a rat's nest of #ifdefs here. IOW, I expect the entire "if (nbytes <= SMALL_REQUEST_THRESHOLD)" block will go away, so that the platform realloc() gets called in every case obmalloc doesn't control the incoming block. BTW, note that there's no plan to do another release in the Python 2.3 line. -- Comment By: Kristján Valur (krisvale) Date: 2005-04-19 16:22 Message: Logged In: YES user_id=1262199 The platform is windows 2000/2003 server, single threaded C runtime. I have only had the chance to do postmortem debugging on this but it would appear to be as you describe: The following page is not mapped in. Windows doesn´t use the setbrk() method of heap management and doesn´t automatically move the break. Rather they (the multiple heaps) requests pages as required. A malloc may have succeeded from a different page and copying to much from the old block close to the boundary caused an exception _at_ the page boundary. Fyi, old block was 68 bytes at 0x6d85efb8. This block ends at -effc. The new size requested was 108 bytes. Reading 108 bytes from this address caused an exception at address 0x6d85f000. As you know, reading past a malloc block results in undefined behaviour and sometimes this can mean a crash. I have patched python locally to use MIN(nbytes, _msize(p)) in stead and we are about to run the modified version on our server cluster. Nodes were dying quite regularly because of this. I'll let you know if this changes anyting in that aspect. Btw, I work for ccp games, and we are running the MMORPG eve online (www.eveonline.com) -- Comment By: Tim Peters (tim_one) Date: 2005-04-19 16:00 Message: Logged In: YES user_id=31435 mwh: Umm ... I don't understand what the claim is. For example, what HW does Python run on where memcpy segfaults just because the address range crosses a page boundary? If that's what's happening, sounds more like a bug in the platform memcpy. I can memcpy blocks spanning thousands of pages on my box -- and so can you . krisvale: which OS and which C are you using? It is true that this code may try to access a bit of memory that wasn't allocated. If that's at the end of the address space, then I could see a segfault happening. If it is, I doubt there's any portable way to fix it short of PyObject_Realloc never trying to take over small blocks it didn't control to begin with. Then the platform realloc() will segfault instead . -- Comment By: Kristján Valur (krisvale) Date: 2005-04-19 15:39 Message: Logged In: YES user_id=1262199 I can only say that I´ve been seeing this happeing with our software. Admittedly it's because we are eating up all memory due to other reasons, but we would like to deal with that with a MemoryError rather than a crash. -- Comment By: Michael Hudson (mwh) Date: 2005-04-19 15:30 Message: Logged In: YES user_id=665
[ python-Bugs-1122301 ] marshal may crash on truncated input
Bugs item #1122301, was opened at 2005-02-14 11:14 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&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 Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: marshal may crash on truncated input Initial Comment: marshal doesn't behave well on truncated or otherwise malformed input. here's a short demo script, from a recent comp.lang.python thread: ::: the problem is that the following may or may not reach the "done!" statement, somewhat depending on python version, memory allocator, and what data you pass to dumps. import marshal data = marshal.dumps((1, 2, 3, "hello", 4, 5, 6)) for i in range(len(data), -1, -1): try: print marshal.loads(data[:i]) except EOFError: print "EOFError" except ValueError: print "ValueError" print "done!" (try different data combinations, to see how far you get on your platform...) fixing this should be relatively easy, and should result in a safe unmarshaller (your application will still have to limit the amount of data fed into load/loads, of course). ::: (also note that marshal may raise either EOFError or ValueError exceptions, again somewhat depending on how the file is damaged. a little consistency wouldn't hurt, but I'm not sure if/how this can be fixed...) -- >Comment By: Michael Hudson (mwh) Date: 2005-05-27 10:36 Message: Logged In: YES user_id=6656 Ping! -- Comment By: Michael Hudson (mwh) Date: 2005-04-19 15:58 Message: Logged In: YES user_id=6656 I think the attached fixes this example, and another involving marshalled sets. I spent a while feeding random data to marshal a few days ago and found that the commonest problem was attempting to allocate really huge sequences. Also, the TYPE_STRINGREF is horribly fragile, but I'm hoping Martin's going to fix that (he has a bug filed against him, anyway). Can you test/check it in? My marshal.c has rather a lot of local changes. Also, a test suite entry would be nice... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209671 ] dict.popitem documentation should mention empty dict case
Bugs item #1209671, was opened at 2005-05-27 02:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: William Chang (misterwilliam) Assigned to: Nobody/Anonymous (nobody) Summary: dict.popitem documentation should mention empty dict case Initial Comment: Currently the documentation in the Python Library Reference entry for Mapping Types does not mention what happens when dict.popitem() is called on an empty mapping. I think that the documentation should mention that a KeyError exception is raised. (At least this is what happens when I try it in the official Python 2.4 release with a dictionary.) If this omission was intentional to give room for future implementors of python/mappings I feel that this should at least be mentioned in the documentation to remind programmers this behavior is not specified. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-27 05:46 Message: Logged In: YES user_id=80475 Okay, fixed. Thanks for the report. -- Comment By: William Chang (misterwilliam) Date: 2005-05-27 02:51 Message: Logged In: YES user_id=1286263 I wasn't being very precise when I substituted dict for mapping types in the summary. I'm so used to thinking of them interchangeablely. I suppose it might matter though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209671&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209880 ] doc bug in Lock.acquire
Bugs item #1209880, was opened at 2005-05-27 10:04 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=1209880&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: Chris Perkins (cperkins) Assigned to: Nobody/Anonymous (nobody) Summary: doc bug in Lock.acquire Initial Comment: The docs for the acquire method in both the thread and threading modules are incorrect. They describe an old (insane) version that returned None when called with no argument. It appears that acquire is now sane, and always returns True or False. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1210001 ] Typo in "Differences from mimelib"
Bugs item #1210001, was opened at 2005-05-27 18:26 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=1210001&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Zumi (zumi001) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in "Differences from mimelib" Initial Comment: In the online manual: http://www.python.org/doc/2.4/lib/node577.html "12.2.12 Differences from mimelib" there's a typo: "The methodgetmaintype() was renamed to get_main_type()." Suggestion: a space after the word "method". So something like this: "The method getmaintype() was renamed to get_main_type()." -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1210001 ] Typo in "Differences from mimelib"
Bugs item #1210001, was opened at 2005-05-27 12:26 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Zumi (zumi001) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Typo in "Differences from mimelib" Initial Comment: In the online manual: http://www.python.org/doc/2.4/lib/node577.html "12.2.12 Differences from mimelib" there's a typo: "The methodgetmaintype() was renamed to get_main_type()." Suggestion: a space after the word "method". So something like this: "The method getmaintype() was renamed to get_main_type()." -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1205239 ] Let shift operators take any integer value
Feature Requests item #1205239, was opened at 2005-05-19 19:54 Message generated for change (Comment added) made by dtorp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. -- >Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 17:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 08:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1205239 ] Let shift operators take any integer value
Feature Requests item #1205239, was opened at 2005-05-19 12:54 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 11:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 -- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 10:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 01:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1205239 ] Let shift operators take any integer value
Feature Requests item #1205239, was opened at 2005-05-19 19:54 Message generated for change (Comment added) made by dtorp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. -- >Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 18:49 Message: Logged In: YES user_id=681258 Forgive my directness, but the last post doesn't show the slightest clue about how Python works. The existing test for a negative shift count takes place downstream from the interpreter in the int_lshift function in intobject.c (and the same for longobject.c). The RFE is to replace the line that raises a Value Error exception with a line that does something useful like flipping the sign of the argument and delegating to int_rshift. That is a zero net change in code complexity. The runtime of non-negative cases is likewise unchanged. Is there someone else reading this who has an informed opinion? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 18:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 -- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 17:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 08:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1205239 ] Let shift operators take any integer value
Feature Requests item #1205239, was opened at 2005-05-19 12:54 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 12:22 Message: Logged In: YES user_id=341410 Pardon me for believing that your RFE was applicable to any object with an __lshift__ method. Being that you did not explicitly state that it was for integers only, merely that you did use it with integers. Regardless, changing integers to support negative shifts would imply that floats should also support negative shifts, and that all objects supporting __(l|r)shift__ methods also support negative shifts. One of Python's strengths is about consistancy, my rude friend, not merely about your particular use case for negative shifts. You should also realize that because this would be a new feature, it would have to wait until Python 2.5, which has at least a year before it is to be released. Are you willing to wait a year to use this? If not, you should get the source for 2.4, modify it as you see fit, and run your own version. If waiting a year for 2.5 and for your change to maybe be included or running your own version of 2.4 is not sufficient, then you have a serious problem on your hands, and no one here can help you. -- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 11:49 Message: Logged In: YES user_id=681258 Forgive my directness, but the last post doesn't show the slightest clue about how Python works. The existing test for a negative shift count takes place downstream from the interpreter in the int_lshift function in intobject.c (and the same for longobject.c). The RFE is to replace the line that raises a Value Error exception with a line that does something useful like flipping the sign of the argument and delegating to int_rshift. That is a zero net change in code complexity. The runtime of non-negative cases is likewise unchanged. Is there someone else reading this who has an informed opinion? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 11:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 -- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 10:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same way as with array indices)? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-26 01:01 Message: Logged In: YES user_id=341410 Is your code time critical? Do your numbers have more than 53 bits of precision? Do your numbers vary beyond 2**1024 or 1/2**1024? If not, then the following should be sufficient for your uses: int(x * 2**y) -- You can respond by visiting: https://sourceforge.net/track
[ python-Feature Requests-1205239 ] Let shift operators take any integer value
Feature Requests item #1205239, was opened at 2005-05-19 15:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. -- >Comment By: Tim Peters (tim_one) Date: 2005-05-27 15:50 Message: Logged In: YES user_id=31435 -0. I could live with this change, but would rather not. In my experience complaints about using a negative shift count has correctly pointed out logic errors in my code, and I wouldn't want to lose that. Note that floats don't support __[lr]shift__ regardless; neither do complex numbers nor Decimals; the benefit/damage among the builtin types would be confined to int & long. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 15:22 Message: Logged In: YES user_id=341410 Pardon me for believing that your RFE was applicable to any object with an __lshift__ method. Being that you did not explicitly state that it was for integers only, merely that you did use it with integers. Regardless, changing integers to support negative shifts would imply that floats should also support negative shifts, and that all objects supporting __(l|r)shift__ methods also support negative shifts. One of Python's strengths is about consistancy, my rude friend, not merely about your particular use case for negative shifts. You should also realize that because this would be a new feature, it would have to wait until Python 2.5, which has at least a year before it is to be released. Are you willing to wait a year to use this? If not, you should get the source for 2.4, modify it as you see fit, and run your own version. If waiting a year for 2.5 and for your change to maybe be included or running your own version of 2.4 is not sufficient, then you have a serious problem on your hands, and no one here can help you. -- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 14:49 Message: Logged In: YES user_id=681258 Forgive my directness, but the last post doesn't show the slightest clue about how Python works. The existing test for a negative shift count takes place downstream from the interpreter in the int_lshift function in intobject.c (and the same for longobject.c). The RFE is to replace the line that raises a Value Error exception with a line that does something useful like flipping the sign of the argument and delegating to int_rshift. That is a zero net change in code complexity. The runtime of non-negative cases is likewise unchanged. Is there someone else reading this who has an informed opinion? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 14:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 -- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 13:05 Message: Logged In: YES user_id=681258 Yes, I use this on long integers. And, the whole point of doing shifts is to avoid the costs of computing and multiplying by powers of two. Besides the math equivalents do not express the algorithms as well or as directly as shifts. Other than coming up with cumbersome workarounds (which I already had), do you have an objection to letting the shift operators use negative indices (in much the same wa
[ python-Feature Requests-1205239 ] Let shift operators take any integer value
Feature Requests item #1205239, was opened at 2005-05-19 19:54 Message generated for change (Comment added) made by dtorp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. -- >Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 20:08 Message: Logged In: YES user_id=681258 When balancing expressiveness against error checking, do you know what tipped the scales in favor of negative list indices? I imagine the issues were similar (although shifting isn't nearly as common as shifting). -- Comment By: Tim Peters (tim_one) Date: 2005-05-27 19:50 Message: Logged In: YES user_id=31435 -0. I could live with this change, but would rather not. In my experience complaints about using a negative shift count has correctly pointed out logic errors in my code, and I wouldn't want to lose that. Note that floats don't support __[lr]shift__ regardless; neither do complex numbers nor Decimals; the benefit/damage among the builtin types would be confined to int & long. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 19:22 Message: Logged In: YES user_id=341410 Pardon me for believing that your RFE was applicable to any object with an __lshift__ method. Being that you did not explicitly state that it was for integers only, merely that you did use it with integers. Regardless, changing integers to support negative shifts would imply that floats should also support negative shifts, and that all objects supporting __(l|r)shift__ methods also support negative shifts. One of Python's strengths is about consistancy, my rude friend, not merely about your particular use case for negative shifts. You should also realize that because this would be a new feature, it would have to wait until Python 2.5, which has at least a year before it is to be released. Are you willing to wait a year to use this? If not, you should get the source for 2.4, modify it as you see fit, and run your own version. If waiting a year for 2.5 and for your change to maybe be included or running your own version of 2.4 is not sufficient, then you have a serious problem on your hands, and no one here can help you. -- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 18:49 Message: Logged In: YES user_id=681258 Forgive my directness, but the last post doesn't show the slightest clue about how Python works. The existing test for a negative shift count takes place downstream from the interpreter in the int_lshift function in intobject.c (and the same for longobject.c). The RFE is to replace the line that raises a Value Error exception with a line that does something useful like flipping the sign of the argument and delegating to int_rshift. That is a zero net change in code complexity. The runtime of non-negative cases is likewise unchanged. Is there someone else reading this who has an informed opinion? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-27 18:06 Message: Logged In: YES user_id=341410 Yes, I do have an objection. On execution, either: 1. The interpreter would necessarily have to ask the question "is this shift value positive or negative" in order to possibly change which operation is to be executed. 2. Every shift operator would need to be rewritten to support negative shift values. Both of these solutions add compexity to what has been historically (in all languages) a very simple operation, and as the zen says "Simple is better than complex." -1 -- Comment By: David Albert Torpey (dtorp) Date: 2005-05-27 17:05 Message: Logged In: YES user_id=681258 Yes, I use this
