[ python-Bugs-1545837 ] array.array borks on deepcopy
Bugs item #1545837, was opened at 2006-08-24 11:49
Message generated for change (Comment added) made by twouters
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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.5
>Status: Closed
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: Václav Haisman (wilx)
Assigned to: Thomas Wouters (twouters)
Summary: array.array borks on deepcopy
Initial Comment:
Hi,
I think there is a bug arraymodule.c this line:
{"__deepcopy__",(PyCFunction)array_copy,METH_NOARGS,
copy_doc},
should probably have METH_O instead of METH_NOARGS
there, since according to docs and the prototype of the
array_copy() function there is one parameter.
--
>Comment By: Thomas Wouters (twouters)
Date: 2006-12-29 16:05
Message:
Logged In: YES
user_id=34209
Originator: NO
Backported.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-12-28 10:11
Message:
Logged In: YES
user_id=34209
Originator: NO
The 2.5 branch at the time was still pre-2.5.0, and we didn't want to make
this change between release candidate and release. It's safe to be checked
into release25-maint now. I'll do it sometime tonight.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-12-28 08:59
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing
it was just forgotten. I don't see any mention in Misc/NEWS either.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-29 09:35
Message:
Logged In: YES
user_id=34209
Not unless you want another release candidate. copy.deepcopy
has never worked on array instances, so it's not a
release-preventing bug (but each bugfix may *add* a
release-preventing bug by accident :)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-08-28 15:32
Message:
Logged In: YES
user_id=80475
Should this be fixed in the release candidate?
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-24 20:50
Message:
Logged In: YES
user_id=34209
Thanks! Fixed in the trunk (which is 2.6-to-be) revision
51565, and it will also be fixed for Python 2.4.4 and 2.5.1.
It's unfortunately just a bit too late for 2.5.0.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1624534 ] updating a set in a list of sets will update all of them
Bugs item #1624534, was opened at 2006-12-29 22:05 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=1624534&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Amir Reza Khosroshahi (amir_reza) Assigned to: Nobody/Anonymous (nobody) Summary: updating a set in a list of sets will update all of them Initial Comment: If you make a list of sets in this way: l = [set()] * 10 And then update one of them, by another set, say y: y = set([1,2,3]) l[0] |= y Then all of the elements of l, that is, all the sets in l will be updated. But if you use a direct union: l[0] = l[0] | y This will not happen. You should define the list that way (using the * operator) in order for this situation to take place. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624534&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1624534 ] updating a set in a list of sets will update all of them
Bugs item #1624534, was opened at 2006-12-29 22:05 Message generated for change (Comment added) made by amir_reza You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624534&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.5 >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Amir Reza Khosroshahi (amir_reza) Assigned to: Nobody/Anonymous (nobody) Summary: updating a set in a list of sets will update all of them Initial Comment: If you make a list of sets in this way: l = [set()] * 10 And then update one of them, by another set, say y: y = set([1,2,3]) l[0] |= y Then all of the elements of l, that is, all the sets in l will be updated. But if you use a direct union: l[0] = l[0] | y This will not happen. You should define the list that way (using the * operator) in order for this situation to take place. -- >Comment By: Amir Reza Khosroshahi (amir_reza) Date: 2006-12-29 23:16 Message: Logged In: YES user_id=1470587 Originator: YES Sorry! It is a feature, not a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624534&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers
Bugs item #1612113, was opened at 2006-12-09 12:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html -- >Comment By: Martin v. Löwis (loewis) Date: 2006-12-29 23:03 Message: Logged In: YES user_id=21627 Originator: NO It can't fail just because of the presence of threads or weakref callbacks, unless these perform modifications to the dictionary. Such modifications can, of course, also happen in a regular loop, if the code in the loop performs the modification (either directly or indirectly, through function calls). As Tim says: if it hurts your feelings to make such an assumption, then just don't make it for yourself (i.e. don't rely on it in your own programs). -- Comment By: Calvin Spealman (ironfroggy) Date: 2006-12-24 17:27 Message: Logged In: YES user_id=112166 Originator: YES This would only fail with the use of threads or weakref callbacks, most likely. I still think thats enough reason to take them back out. Assuring any order at any time, reguardless of the circumstances, I feel, is just against the concept of the dictionary. -- Comment By: SourceForge Robot (sf-robot) Date: 2006-12-24 04:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Tim Peters (tim_one) Date: 2006-12-09 15:51 Message: Logged In: YES user_id=31435 Originator: NO The statement that the various ways of extracting info from a dict are consistent /provided that/ they're "called with no intervening modifications to the dictionary" (did you miss that crucial qualification?) is part of the language definition: it definitely and deliberately constrains the set of possible implementations. The docs didn't originally say this, but people noted it was true in then-current CPython, and asked whether they could rely on it. At that point, Guido decided to elevate this property of the CPython implementation to a language requirement, and the footnote was added. Of course you're not /required/ to rely on it ;-). -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-09 15:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows
Bugs item #1568240, was opened at 2006-09-30 11:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. Löwis (loewis) Summary: Tix is not included in 2.5 for Windows Initial Comment: (I hope "Build" is more precise than "Extension Modules" and "Tkinter" for this specific bug.) At least the following files are missing from 2.5 for Windows: DLLs\tix8184.dll tcl\tix8184.lib tcl\tix8.1\* -- >Comment By: Martin v. Löwis (loewis) Date: 2006-12-29 23:26 Message: Logged In: YES user_id=21627 Originator: NO I haven't read Neal's message yet, but I wonder what he could do about it. I plan to fix this with 2.5.1, there is absolutely no way to fix this earlier. I'm not sure who "we" is who would like to bump the bug, and what precisely this bumping would do; tzot, please refrain from changing the priority to higher than 7. These priorities are reserved to the release manager. -- Comment By: Christos Georgiou (tzot) Date: 2006-12-27 18:46 Message: Logged In: YES user_id=539787 Originator: YES Should we bump the bug up and/or assign it to Neal Norwitz as he requested on Python-Dev? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1624674 ] webbrowser.open_new() suggestion
Bugs item #1624674, was opened at 2006-12-30 01:03
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=1624674&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
Private: No
Submitted By: Imre Péntek (imi1984)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser.open_new() suggestion
Initial Comment:
Hello,
under Linux if I use
webbrowser.open_new('...') a konqueror gets invoked. At the time when invoking
konqueror (maybe you probe first, but anyways) you assume that user has a
properly installed kde. But if you assume the user has a properly installed KDE
you have a better opportunity to open a webpage, even in the browser preferred
by the user -- no matter really what it is. Try this one:
kfmclient exec http://sourceforge.net/
using this one the client associated with .html in kcontrol gets invoked.
I suppose that (becouse of the ability to customize the browser) this way would
be better if available than guessing which browser would the user prefer.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624674&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1619659 ] htonl, ntohl don't handle negative longs
Bugs item #1619659, was opened at 2006-12-20 12:42 Message generated for change (Comment added) made by mark-roberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&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 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: htonl, ntohl don't handle negative longs Initial Comment: >>> htonl(-5) -67108865 >>> htonl(-5L) Traceback (most recent call last): File "", line 1, in ? OverflowError: can't convert negative value to unsigned long It works fine in 2.1 and 2.2, but fails in 2.3, 2.4, 2.5. htons, ntohs do not appear to have the bug, but I'm not 100% sure. -- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-29 20:15 Message: Logged In: YES user_id=1591633 Originator: NO Hmmm, yes, I see a problem. At the very least, I think we may be wanting some consistency between the acceptance of ints and longs. Also, I think we should return an unsigned long instead of just a long (which can be negative). I've got a patch right now to make htonl, ntohl, htons, and ntohs never return a negative number. I'm rather waffling to the idea of whether we should accept negative numbers at all in any of the functions. The behavior is undefined, and it is, afterall, better not to guess what a user intended. However, consistency should be a desirable goal, and we should accept make the interface consistent for both ints and longs. Mark -- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-12-28 15:37 Message: Logged In: YES user_id=12364 Originator: YES I forgot to mention it, but the only reason htonl should get passed a negative number is that it (and possibly struct?) produce a negative number. Changing them to always produce positive numbers may be an alternative solution. Or we may want to do both, always producing positive while also accepting negative. -- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 03:24 Message: Logged In: YES user_id=1591633 Originator: NO >From man page for htonl and friends: #include uint32_t htonl(uint32_t hostlong); uint16_t htons(uint16_t hostshort); uint32_t ntohl(uint32_t netlong); uint16_t ntohs(uint16_t netshort); Python does call these underlying functions in Modules/socketmodule.c. The problem comes from that PyLong_AsUnsignedLong() called in socket_htonl() specifically checks to see that the value cannot be less than 0. The error checking was rather exquisite, I might add. - Mark -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599931 ] Immediate Crash on Open
Bugs item #1599931, was opened at 2006-11-20 11:45 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&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: IDLE Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Farhymn (farhymn) Assigned to: Kurt B. Kaiser (kbk) Summary: Immediate Crash on Open Initial Comment: Python 2.5 IDLE crashes -immediately- upon open, leaving enough time to hold down the enter button on the executable and only have the pythonw process show up one-at-a-time. This is version specific, as 2.4 Final worked fine. Now all applications cannot run. I made sure to uninstall 2.4 before installing 2.5, so it isn't a version conflict (as far as I can tell). Running Windows XP SP2 on an HP Laptop (paviliion dv4000) and am attempting to run the program OpenRPG+. Program can be provided for replication of test as necessary. Duplicate processes are not observed in Windows Task Manager and a complete uninstallation and installation of the Python 2.5 language provides the same unknown error. -- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-29 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-14 21:30 Message: Logged In: YES user_id=149084 Originator: NO I'm sorry, I can't understand your report. Please tell me exactly how you are starting IDLE (using the icon? using a command window?) What does OpenRPG+ have to do with it, are you calling it along with IDLE? If so, please give me the command line and a url for the program. What does your "edit" have to do with the problem? The second number is illegal, because although it's coded as an octal (starts with 0) it has characters greater than 7 in it. Fix either of those issues, and it's fine. -- Comment By: Farhymn (farhymn) Date: 2006-11-20 11:53 Message: Logged In: YES user_id=1650037 Originator: YES (edit) Forgot to mention that the problem is pythonw.exe specific as well. Python DOS runs fine, I can only get it to register a token error by typing in the following at the prompt: 1234816587613289741-0152872349817230987 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1614460 ] python-logging compatability with Zope.
Bugs item #1614460, was opened at 2006-12-12 19:02 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Simon Hookway (shookway) Assigned to: Vinay Sajip (vsajip) Summary: python-logging compatability with Zope. Initial Comment: I'm using Zope2.8.x and python2.4. On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it. This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification. See the included patch. -- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-29 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 09:13 Message: Logged In: YES user_id=308438 Originator: NO Yes, a fix was applied a while ago. -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 00:06 Message: Logged In: YES user_id=849994 Originator: NO I believe this was fixed in 2.5, but I could be mistaken. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
