[issue19507] ssl.wrap_socket() with server_hostname should imply match_hostname()
Antoine Pitrou added the comment: I'm not sure why it's surprising. SNI and certificate validation are two different things. Besides, this is adding a new level of complication to the wrap_socket() signature. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19507 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19508] Add warning that Python doesn't verify SSL certs by default
Antoine Pitrou added the comment: There is already an entire section about this: http://docs.python.org/dev/library/ssl.html#security-considerations It's up to consumers of the API to choose their security policy, the ssl module merely provides building blocks to implement it. I think the ssl docs are sufficiently explicit about it right now, we're not going to add warnings every time we think something is important to read. As for developers [who] are still surprised, well, most of them shouldn't use the ssl module directly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19508 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19508] Add warning that Python doesn't verify SSL certs by default
STINNER Victor added the comment: There is already an entire section about this: http://docs.python.org/dev/library/ssl.html#security-considerations So we just need to add a link from http, ftp, imap, ... to this section? Using only http://docs.python.org/dev/library/ftplib.html#ftp-tls-objects documentation, I don't see how to plug my own SSL validation code. I don't see any SSL context object or things like that. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19508 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15216] Support setting the encoding on a text stream after creation
Nick Coghlan added the comment: Just reviewed Victor's patch - aside from a trivial typo and not covering the C implementation or documentation yet, it looks good to me. Most importantly, the tests in that patch could be used to validate a C implementation as well. I'll see if I can find anyone interested in creating a patch for the C io implementation, otherwise we can postpone the addition until 3.5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15216 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15216] Support setting the encoding on a text stream after creation
Andrei Dorian Duma added the comment: I am interested in working on this, but I might need guidance at times. Is that acceptable? If yes, I'm willing to start as soon as possible. -- nosy: +andrei.duma ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15216 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15216] Support setting the encoding on a text stream after creation
Nick Coghlan added the comment: Thanks, Andrei, that would be great. The tests and the Python version in Victor's patch show the desired API and behaviour. In theory, the C version should just be a matter of adding an equivalent textiowrapper_set_encoding method as a static function in hg.python.org/cpython/file/default/Modules/_io/textio.c -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15216 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19378] Clean up Python 3.4 API additions in the dis module
Roundup Robot added the comment: New changeset ce8dd299cdc4 by Nick Coghlan in branch 'default': Close #19378: address flaws in the new dis module APIs http://hg.python.org/cpython/rev/ce8dd299cdc4 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19378 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17823] 2to3 fixers for missing codecs
Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19332] Guard against changing dict during iteration
Steven D'Aprano added the comment: Duplicate of this: http://bugs.python.org/issue6017 -- nosy: +stevenjd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19332] Guard against changing dict during iteration
Changes by Steven D'Aprano steve+pyt...@pearwood.info: -- nosy: -stevenjd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17823] 2to3 fixers for missing codecs
Nick Coghlan added the comment: Switch direction of dependency to make this fixer rely on restoring the codec aliases in issue 7475 first. -- dependencies: +codecs missing: base64 bz2 hex zlib hex_codec ... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
Nick Coghlan added the comment: Providing the 2to3 fixers in issue 17823 now depends on this issue rather than the other way around (since not having to translate the names simplifies the fixer a bit). -- dependencies: -2to3 fixers for missing codecs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
Changes by Tim Golden m...@timgolden.me.uk: -- assignee: - tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
Changes by Tim Golden m...@timgolden.me.uk: -- components: +Windows versions: +Python 3.4 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19511] lib2to3 Grammar file is no longer a Python 3 superset
New submission from Nick Coghlan: In writing some new fixers for issue 17823, I noticed the 2/3 bridge grammar in lib2to3 was never updated to handle yield from. This item is also missing from the checklist in the devguide: http://docs.python.org/devguide/grammar.html -- components: Devguide, Library (Lib) messages: 202265 nosy: ezio.melotti, ncoghlan priority: low severity: normal status: open title: lib2to3 Grammar file is no longer a Python 3 superset type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17823] 2to3 fixers for missing codecs
Nick Coghlan added the comment: Attached diff shows a proof of concept fixer for the encode case. It could be adjusted fairly easily to also handle decode methods (by including an alternative in the pattern and also capturing the method name) I'm sure how useful such a fixer would be in practice, though, since it only triggers when the codec name is passed as a literal - passing in a variable instead keeps it from firing. -- keywords: +patch Added file: http://bugs.python.org/file32515/issue17823_lib2to3_fixer_for_binary_codecs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
Changes by Bohuslav Slavek Kabrda bkab...@redhat.com: -- nosy: +bkabrda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17823] 2to3 fixers for missing codecs
Nick Coghlan added the comment: On 7 November 2013 00:06, Nick Coghlan rep...@bugs.python.org wrote: I'm sure how useful such a fixer would be in practice, though, since it only triggers when the codec name is passed as a literal - passing in a variable instead keeps it from firing. Oops, that should say I'm *not* sure :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
Tim Golden added the comment: Attached is a patch with tests -- keywords: +patch Added file: http://bugs.python.org/file32516/issue13674.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19511] lib2to3 Grammar file is no longer a Python 3 superset
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17823] 2to3 fixers for missing codecs
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
STINNER Victor added the comment: +if (strchr(y, outbuf[1]) buf.tm_year 0) hum... why not simply outbuf[1] == 'y' ? It would be more explicit and less surprising. For the unit test, it would be nice to test also asctime(), even if time.asctime() doesn't use asctime() of the C library. And it's better to run tests on all platforms. Only test_y_before_1900() should behave differently on other platforms, but it would be nice to run test_y_before_1900() on platforms supporting %y with year 1900. In my experience, other operating systems have also their own issues. For example, time.strftime() has a specific test to Windows, but also Solaris and AIX. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19475] Add microsecond flag to datetime isoformat()
Alexander Belopolsky added the comment: MAL: Have you thought about the rounding/truncation issues associated with not showing microseconds ? I believe it has to be the truncation. Rounding is better left to the user code where it can be done either using timedelta arithmetics or at the time source. I would expect that in the majority of cases where lower resolution printing is desired the times will be already at lower resolution at the source. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
Tim Golden added the comment: On 06/11/2013 15:23, STINNER Victor wrote: +if (strchr(y, outbuf[1]) buf.tm_year 0) hum... why not simply outbuf[1] == 'y' ? It would be more explicit and less surprising. Ummm. I have no idea what I was thinking about there. I think it was somehow connected with the strchr check a few lines earlier. Anyhow, fixed now, thanks. For the unit test, it would be nice to test also asctime(), even if time.asctime() doesn't use asctime() of the C library. And it's better to run tests on all platforms. Only test_y_before_1900() should behave differently on other platforms, but it would be nice to run test_y_before_1900() on platforms supporting %y with year 1900. In my experience, other operating systems have also their own issues. For example, time.strftime() has a specific test to Windows, but also Solaris and AIX. I'm not sure where time.asctime comes into it. The implementation doesn't use time.strftime, but even if it did, I don't see the need to add a test under this issue: the unit test for strftime should be enough to cover any direct or indirect use of the function. I'm happy to open up the other tests. TJG -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18582] PBKDF2 support
Roundup Robot added the comment: New changeset 07fa1ed0d551 by Christian Heimes in branch 'default': Issue #18582: fix memory leak in pbkdf2 code http://hg.python.org/cpython/rev/07fa1ed0d551 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19475] Add microsecond flag to datetime isoformat()
Marc-Andre Lemburg added the comment: On 06.11.2013 16:51, Alexander Belopolsky wrote: MAL: Have you thought about the rounding/truncation issues associated with not showing microseconds ? Sure, otherwise I wouldn't have mentioned it :-) mxDateTime always uses 2 digit fractions when displaying date/time values. This has turned out to be a good compromise between accuracy and usability. In early version, I used truncation, but that caused (too many) roundtrip problems, so I started using careful rounding in later versions: /* Fix a second value for display as string. Seconds are rounded to the nearest microsecond in order to avoid cases where e.g. 3.42 gets displayed as 03.41 or 3.425 is diplayed as 03.42. Special care is taken for second values which would cause rounding to 60.00 -- these values are truncated to 59.99 to avoid the value of 60.00 due to rounding to show up even when the indicated time does not point to a leap second. The same is applied for rounding towards 61.00 (leap seconds). The second value returned by this function should be formatted using '%05.2f' (which rounds to 2 decimal places). */ This approach has worked out well, though YMMV. I believe it has to be the truncation. Rounding is better left to the user code where it can be done either using timedelta arithmetics or at the time source. I would expect that in the majority of cases where lower resolution printing is desired the times will be already at lower resolution at the source. In practice you often don't know the resolution of the timing source. Nowadays, the reverse of what you said is usually true: the source resolution is higher than the precision you use to print it. MS SQL Server datetime is the exception to that rule, with a resolution of 333ms and weird input rounding: http://msdn.microsoft.com/en-us/library/ms187819.aspx For full seconds, truncation will add an error of +/- 1 second, whereas rounding only adds +/- 0.5 seconds. This is what convinced me to use rounding instead of truncation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
New submission from STINNER Victor: In interactive mode, when I run python in gdb, I see that PyUnicode_DecodeUTF8Stateful() is called a lot of times. Calls come from PyDict_GetItemString() or PySys_GetObject() for example. Allocating a temporary Unicode string and decode a byte string from UTF-8 is inefficient: the memory allocator is stressed and the byte string is decoded at each call. I propose to reuse the _Py_IDENTIFIER API in most common places to limit calls to the memory allocator and to PyUnicode_DecodeUTF8Stateful(). -- messages: 202273 nosy: haypo priority: normal severity: normal status: open title: Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
STINNER Victor added the comment: pysys_getobjectid.patch: - add _PySys_GetObjectId() and _PyDict_GetItemId() functions - add global identifiers for most common strings: argv, path, stdin, stdout, stderr - use these new functions and identifiers -- keywords: +patch Added file: http://bugs.python.org/file32517/pysys_getobjectid.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19475] Add microsecond flag to datetime isoformat()
Alexander Belopolsky added the comment: I am afraid that the rounding issues may kill this proposal. Can we start with something simple? For example, we can start with show=None keyword argument and allow a single value 'microseconds' (or 'us'). This will solve the issue at hand with a reasonable syntax: t.isoformat(show='us'). If other resolutions will be required, we can later add more values and may even allow t.isoformat(show=2) to show 2 decimal digits. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
Serhiy Storchaka added the comment: PySys_GetObject() is called with followed literal strings: argv, displayhook, excepthook, modules, path, path_hooks, path_importer_cache, ps1, ps2, stderr, stdin, stdout, tracebacklimit. PyDict_GetItemString() is called with followed literal strings: __abstractmethods__, __builtins__, __file__, __loader__, __module__, __name__, __warningregistry__, _abstract_, _argtypes_, _errcheck_, _fields_, _flags_, _iterdump, _needs_com_addref_, _restype_, _type_, builtins, decimal_point, default_int_handler, displayhook, excepthook, fillvalue, grouping, imp, metaclass, options, sys, thousands_sep. Are any of these calls performance critical? -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
STINNER Victor added the comment: Are any of these calls performance critical? I'm trying to focus on the interactive interpreter. I didn't touch literal strings used once, for example at module initialization. Well, if it doesn't make the code much uglier or much slower, it's maybe not a big deal to replace all string literals with identifiers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
Roundup Robot added the comment: New changeset a2f42d57b91d by Victor Stinner in branch 'default': Issue #19512: sys_displayhook() now uses an identifier for builtins http://hg.python.org/cpython/rev/a2f42d57b91d New changeset 55517661a053 by Victor Stinner in branch 'default': Issue #19512: _print_total_refs() now uses an identifier to get showrefcount http://hg.python.org/cpython/rev/55517661a053 New changeset af822a6c9faf by Victor Stinner in branch 'default': Issue #19512: Add PyRun_InteractiveOneObject() function http://hg.python.org/cpython/rev/af822a6c9faf -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
STINNER Victor added the comment: Oh, by the way, identifiers have a nice side effect: they are interned, and so dict lookup should be faster. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
Roundup Robot added the comment: New changeset 8a6a920d8eae by Victor Stinner in branch 'default': Issue #19512: Py_ReprEnter() and Py_ReprLeave() now use an identifier for the http://hg.python.org/cpython/rev/8a6a920d8eae New changeset 69071054b42f by Victor Stinner in branch 'default': Issue #19512: Add a new _PyDict_DelItemId() function, similar to http://hg.python.org/cpython/rev/69071054b42f New changeset 862a62e61553 by Victor Stinner in branch 'default': Issue #19512: type_abstractmethods() and type_set_abstractmethods() now use an http://hg.python.org/cpython/rev/862a62e61553 New changeset e5476ecb8b57 by Victor Stinner in branch 'default': Issue #19512: eval() and exec() now use an identifier for __builtins__ string http://hg.python.org/cpython/rev/e5476ecb8b57 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19475] Add microsecond flag to datetime isoformat()
Skip Montanaro added the comment: I am afraid that the rounding issues may kill this proposal. Can we start with something simple? For example, we can start with show=None keyword argument and allow a single value 'microseconds' (or 'us'). This will solve the issue at hand with a reasonable syntax: t.isoformat(show='us'). If other resolutions will be required, we can later add more values and may even allow t.isoformat(show=2) to show 2 decimal digits. I don't think the meaning of this proposed show keyword argument should be overloaded as you suggest. If you show microseconds, just show all of them. Furthermore... If we go far enough back, my original problem was really that the inclusion of microseconds in csv module output was inconsistent, making it impossible for me to later parse those values in another script using a fixed strptime format. Since the csv module uses str() to convert input values for output, nothing you do to isoformat() will have any effect on my original problem. In my own code (where I first noticed the problem) I acquiesced, and changed this d[time] = now to this: d[time] = now.strftime(%Y-%m-%dT%H:%M:%S.%f) where now is a datetime object. I thus guarantee that I can parse these timestamps later using the same format. I realize the inclusion of T means my fields changed in other ways, but that was intentional, and not germane to this discussion. So, fiddle all you want with isoformat(), but do it right. I vote that if you want to add a show parameter it should simply include all fields down to that level, omitting any lower down. If people want to round or truncate things you can give them that option, returning a suitably adjusted, new datetime object. I don't think rounding, truncation, or other numeric operations should be an element of conversion to string form. This does not happen today: import datetime x = datetime.datetime.now() x datetime.datetime(2013, 11, 6, 12, 19, 5, 759020) x.strftime(%Y-%m-%d %H:%M:%S) '2013-11-06 12:19:05' (%S doesn't produce 06) Skip -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
Serhiy Storchaka added the comment: I don't think these changes are required. The interactive interpreter is not a bottleneck. And definitely adding new public functions to API needs more discussion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3849] FUD in documentation for urllib.urlopen()
Changes by A.M. Kuchling li...@amk.ca: -- keywords: -easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue626452] Support RFC 2392 in email package
Changes by A.M. Kuchling li...@amk.ca: -- keywords: -easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue626452 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue634412] RFC 2387 in email package
Changes by A.M. Kuchling li...@amk.ca: -- keywords: -easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue634412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Changes by A.M. Kuchling li...@amk.ca: -- keywords: -easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True
Changes by A.M. Kuchling li...@amk.ca: -- keywords: -easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11965] Simplify context manager in os.popen
A.M. Kuchling added the comment: Closing this issue; I agree with Ronald's assessment. -- nosy: +akuchling resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
Changes by A.M. Kuchling li...@amk.ca: -- resolution: - invalid status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1348 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1671676] test_mailbox is hanging while doing gmake test on HP-UX v3
Changes by A.M. Kuchling li...@amk.ca: -- status: open - languishing ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1671676 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7593] Computed-goto patch for RE engine
Changes by A.M. Kuchling li...@amk.ca: -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7593 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue834840] Unhelpful error message from cgi module
Changes by A.M. Kuchling li...@amk.ca: -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue834840 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19505] OrderedDict views don't implement __reversed__
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- priority: normal - low type: - enhancement versions: -Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8003] Fragile and unexpected error-handling in asyncore
A.M. Kuchling added the comment: asyncore is no longer maintained, so this will not get fixed. -- nosy: +akuchling resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19441] itertools.tee improve documentation
Raymond Hettinger added the comment: I don't want to recommend overwriting the variable name but will add a note for the rest: Copied iterators depend the original iterator. If the original advances, then so do the copies. After teeing the iterators, the usual practice is to stop working with the original iterator and operate only on the new tee-ed iterators. FWIW, the situation is analogous to str.upper(). We note that string methods produce new strings. We don't state that a best practice is to overwrite the variable with s = s.upper(). That is sometimes what you want and sometimes not. -- priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19441 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19332] Guard against changing dict during iteration
Raymond Hettinger added the comment: A few thoughts: * No existing, working code will benefit from this patch; however, almost all code will pay a price for it -- bigger size for an empty dict and a runtime cost (possibly very small) on the critical path (every time a value is stored in a dict). * The sole benefit of the patch is provide an earlier warning that someone is doing something weird. For most people, this will never come up (we have 23 years of Python history indicating that there isn't a real problem to that needs to be solved). * The normal rule (not just for Python) is that a data structures have undefined behavior for mutating while iterating, unless there is a specific guarantee (for example, we guarantee that the dicts are allowed to mutate values but not keys during iteration and we guarantee the behavior of list iteration while iterating). * It is not clear that other implementations such as IronPython and Jython would be able to implement this behavior (Jython wraps the Java ConcurrentHashMap). * The current patch second guesses a decision that was made long ago to only detect size changes (because it is cheap, doesn't take extra memory, isn't on the critical path, and handles the common case). * The only case whether we truly need a stronger protection is when it is needed to defend against a segfault. That is why collections.deque() implement a change counter. It has a measureable cost that slows down deque operations (increasing the number of memory accesses per append, pop, or next) but it is needed to prevent the iterator from spilling into freed memory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
STINNER Victor added the comment: I don't think these changes are required. The interactive interpreter is not a bottleneck. What is the problem with these changes? Identifiers have different advantages. Errors become more unlikely because objects are only initialized once, near startup. So it put also less pressure on code handling errors :) (it is usually the least tested part of the code) And definitely adding new public functions to API needs more discussion. You mean for PyRun_InteractiveOneObject()? Oh, it can be made private, but what is the problem of adding yet another PyRun_Interactive*() function? There are already a lot of them :-) I also worked hard to support unencodable filenames: using char*, you cannot support arbitrary Unicode filename on Windows. That's why a added many various functions with Object suffix. Some examples: PyWarn_ExplicitObject(), PyParser_ParseStringObject(), PyImport_AddModuleObject(), etc. Some users complained that they were not able to run Python scripts on Windows with unencodable filenames (like russian characters on an english setup). I can try to find the related issues. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7061] Improve turtle module documentation
A.M. Kuchling added the comment: Is there anything left to do for this issue? -- nosy: +akuchling ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19505] OrderedDict views don't implement __reversed__
Serhiy Storchaka added the comment: We can't add __reversed__() to the Set or MappingView protocols without breaking third party code, but we can add it to concrete implementations of mapping views. In particular for views of OrderedDict which itself already have __reversed__(). Here is a patch which makes OrderedDict's views reversible. -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file32518/OrderedDict_reversed_views.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
Roundup Robot added the comment: New changeset 5e402c16a74c by Victor Stinner in branch 'default': Issue #19512: Add _PySys_GetObjectId() and _PySys_SetObjectId() functions http://hg.python.org/cpython/rev/5e402c16a74c New changeset cca13dd603a9 by Victor Stinner in branch 'default': Issue #19512: PRINT_EXPR bytecode now uses an identifier to get sys.displayhook http://hg.python.org/cpython/rev/cca13dd603a9 New changeset 6348764bacdd by Victor Stinner in branch 'default': Issue #19512: pickle now uses an identifier to only create the Unicode string http://hg.python.org/cpython/rev/6348764bacdd New changeset 954167ce92a3 by Victor Stinner in branch 'default': Issue #19512: add some common identifiers to only create common strings once, http://hg.python.org/cpython/rev/954167ce92a3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6868] Check errno of epoll_ctrl
A.M. Kuchling added the comment:
I don't understand the bug being reported. The code you quote should
probably be written as if (result 0 errno == EBADF), but the block's net
effect is to ignore an error by resetting result and errno.
It doesn't matter if we occasionally set result and errno to 0 when result is
already zero, but errno happens to be set to EBADF from some earlier operation.
The open('xxx', O_RDONLY) would raise an exception, not return a fd of -1, so I
don't see how that can be used to trigger a problem.
Therefore I'll close this issue, but am willing to re-open it if someone can
explain a way this code could actually cause problems.
--
nosy: +akuchling
resolution: - wont fix
stage: test needed - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6868
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
STINNER Victor added the comment:
Another problem is that PyUnicode_FromString() failure is not handled correctly
in some cases. PyUnicode_FromString() can fail because an decoder error, but
also because of a MemoryError. For example, PyDict_GetItemString() returns NULL
as if the entry does not exist if PyUnicode_FromString() failed :-(
---
PyObject *
PyDict_GetItemString(PyObject *v, const char *key)
{
PyObject *kv, *rv;
kv = PyUnicode_FromString(key);
if (kv == NULL) {
PyErr_Clear();
return NULL;
}
rv = PyDict_GetItem(v, kv);
Py_DECREF(kv);
return rv;
}
---
While working on failmalloc issues (#18048, #19437), I found some places where
MemoryError caused tricky bugs because of this. Example of such issue:
---
changeset: 84684:af18829a7754
user:Victor Stinner victor.stin...@gmail.com
date:Wed Jul 17 01:22:45 2013 +0200
files: Objects/structseq.c Python/pythonrun.c
description:
Close #18469: Replace PyDict_GetItemString() with _PyDict_GetItemId() in
structseq.c
_PyDict_GetItemId() is more efficient: it only builds the Unicode string once.
Identifiers (dictionary keys) are now created at Python initialization, and if
the creation failed, Python does exit with a fatal error.
Before, PyDict_GetItemString() failure was not handled: structseq_new() could
call PyObject_GC_NewVar() with a negative size, and structseq_dealloc() could
also crash.
---
So moving from PyDict_GetItemString() to _PyDict_GetItemId() is for
perfomances, but the main motivation is to handle better errors. I hope that
the identifier will be initialized quickly at startup, and if its
initialization failed, the failure is handled better...
There is also a _PyDict_GetItemIdWithError() function. But it is not used
currently (it was in changeset 2dd046be2c88).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19512
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19479] textwrap.dedent doesn't work properly with strings containing CRLF
Alexis Daboville added the comment: Added patch. -- keywords: +patch Added file: http://bugs.python.org/file32519/dedent.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19479 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
Roundup Robot added the comment: New changeset 40c73ccaee95 by Victor Stinner in branch 'default': Issue #19512: __build_class() builtin now uses an identifier for the metaclass string http://hg.python.org/cpython/rev/40c73ccaee95 New changeset 7177363d8c5c by Victor Stinner in branch 'default': Issue #19512: fileio_init() reuses PyId_name identifier instead of name http://hg.python.org/cpython/rev/7177363d8c5c New changeset dbee50619259 by Victor Stinner in branch 'default': Issue #19512: _count_elements() of _collections reuses PyId_get identifier http://hg.python.org/cpython/rev/dbee50619259 New changeset 6a1ce1fd1fc0 by Victor Stinner in branch 'default': Issue #19512: builtin print() function uses an identifier instead of literal http://hg.python.org/cpython/rev/6a1ce1fd1fc0 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid temporary Unicode strings, use identifiers to only create the string once
STINNER Victor added the comment: I changed the issue title to make it closer to the real changesets related to the issue. -- title: Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode - Avoid temporary Unicode strings, use identifiers to only create the string once ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19512] Avoid temporary Unicode strings, use identifiers to only create the string once
Roundup Robot added the comment: New changeset 77bebcf5c4cf by Victor Stinner in branch 'default': Issue #19512: add _PyUnicode_CompareWithId() function http://hg.python.org/cpython/rev/77bebcf5c4cf New changeset 3f9f2cfae53b by Victor Stinner in branch 'default': Issue #19512: Use the new _PyId_builtins identifier http://hg.python.org/cpython/rev/3f9f2cfae53b -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19513] Use PyUnicodeWriter instead of PyAccu in repr(tuple) and repr(list)
New submission from STINNER Victor: PyUnicodeWriter is (a little bit) more efficient than PyAccu to build Unicode strings. Attached patch list_repr_writer.patch modify list_repr() to use PyUnicodeWriter. -- files: list_repr_writer.patch keywords: patch messages: 202298 nosy: haypo, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Use PyUnicodeWriter instead of PyAccu in repr(tuple) and repr(list) versions: Python 3.4 Added file: http://bugs.python.org/file32520/list_repr_writer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19513 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19513] Use PyUnicodeWriter instead of PyAccu in repr(tuple) and repr(list)
STINNER Victor added the comment: bench_list_repr.py: benchmark script. It would be interesting to run it on Windows, performances of realloc() may be different. Result on my Linux box: Common platform: Python unicode implementation: PEP 393 Platform: Linux-3.9.4-200.fc18.x86_64-x86_64-with-fedora-18-Spherical_Cow Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Timer: time.perf_counter CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Bits: int=32, long=64, long long=64, size_t=64, void*=64 CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz Platform of campaign pyaccu: SCM: hg revision=fafe20297927 tag=tip branch=default date=2013-11-07 00:53 +0100 Date: 2013-11-07 01:40:23 Python version: 3.4.0a4+ (default:fafe20297927, Nov 7 2013, 01:40:19) [GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] Timer precision: 36 ns Platform of campaign writer: Timer precision: 40 ns SCM: hg revision=fafe20297927+ tag=tip branch=default date=2013-11-07 00:53 +0100 Date: 2013-11-07 01:39:59 Python version: 3.4.0a4+ (default:fafe20297927+, Nov 7 2013, 01:38:30) [GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] -+-+--- Tests | pyaccu | writer -+-+--- list(a) | 308 ns (*) | 259 ns (-16%) list(abc) | 489 ns (*) | 468 ns [a]*(100) | 8.17 us (*) | 7.8 us [abc]*(100) | 8.46 us (*) | 8.88 us [a * 100]*(100) | 35.2 us (*) | 36.2 us [a]*(10**6) | 91.4 ms (*) | 77.3 ms (-15%) [abc]*(10**6) | 96.3 ms (*) | 85.2 ms (-11%) [a * 100]*(10**5) | 46.8 ms (*) | 35.1 ms (-25%) list(range(10**6)) | 105 ms (*) | 96.9 ms (-8%) list(map(str, range(10**6))) | 108 ms (*) | 88.7 ms (-18%) -+-+--- Total | 448 ms (*) | 383 ms (-14%) -+-+--- -- Added file: http://bugs.python.org/file32521/bench_list_repr.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19513 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19514] Merge duplicated _Py_IDENTIFIER identifiers in C code
New submission from STINNER Victor: Some C files use more than once the same _Py_IDENTIFIER identifier. It would be more efficient to merge duplicated identifiers. Just move the definition to the top of the file. _Py_IDENTIFIER(as_integer_ratio): Modules/_datetimemodule.c:1569 _Py_IDENTIFIER(as_integer_ratio): Modules/_datetimemodule.c:1668 _Py_IDENTIFIER(cursor): Modules/_sqlite/connection.c:1282 _Py_IDENTIFIER(cursor): Modules/_sqlite/connection.c:1312 _Py_IDENTIFIER(cursor): Modules/_sqlite/connection.c:1342 _Py_IDENTIFIER(fromutc): Modules/_datetimemodule.c:4210 _Py_IDENTIFIER(fromutc): Modules/_datetimemodule.c:4249 _Py_IDENTIFIER(fromutc): Modules/_datetimemodule.c:4812 _Py_IDENTIFIER(__len__): Objects/typeobject.c:5071 _Py_IDENTIFIER(__len__): Objects/typeobject.c:5235 _Py_IDENTIFIER(insert): Modules/_bisectmodule.c:198 _Py_IDENTIFIER(insert): Modules/_bisectmodule.c:93 _Py_IDENTIFIER(isoformat): Modules/_datetimemodule.c:2638 _Py_IDENTIFIER(isoformat): Modules/_datetimemodule.c:3596 _Py_IDENTIFIER(isoformat): Modules/_datetimemodule.c:4532 _Py_IDENTIFIER(strftime): Modules/_datetimemodule.c:1280 _Py_IDENTIFIER(strftime): Modules/_datetimemodule.c:2679 -- keywords: easy messages: 202300 nosy: haypo priority: normal severity: normal status: open title: Merge duplicated _Py_IDENTIFIER identifiers in C code versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19514 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19515] Share duplicated _Py_IDENTIFIER identifiers in C code
New submission from STINNER Victor: I started to share some common identifiers in Python/pythonrun.c, extract: /* Common identifiers */ _Py_Identifier _PyId_argv = _Py_static_string_init(argv); _Py_Identifier _PyId_builtins = _Py_static_string_init(builtins); ... Do you think it would be interesting to continue to share such identifier somewhere? Maybe in a new file? We might do the same for some common strings like empty string, single character (like \n), etc. See also issue #19514. Duplicated identifiers in the io module: _Py_IDENTIFIER(_dealloc_warn): Modules/_io/bufferedio.c:17 _Py_IDENTIFIER(_dealloc_warn): Modules/_io/textio.c:15 _Py_IDENTIFIER(__IOBase_closed): Modules/_io/iobase.c:183 _Py_IDENTIFIER(__IOBase_closed): Modules/_io/iobase.c:62 _Py_IDENTIFIER(read1): Modules/_io/bufferedio.c:24 _Py_IDENTIFIER(read1): Modules/_io/textio.c:25 _Py_IDENTIFIER(readable): Modules/_io/bufferedio.c:25 _Py_IDENTIFIER(readable): Modules/_io/textio.c:26 _Py_IDENTIFIER(readall): Modules/_io/fileio.c:590 _Py_IDENTIFIER(readall): Modules/_io/iobase.c:802 _Py_IDENTIFIER(seek): Modules/_io/iobase.c:101 _Py_IDENTIFIER(seek): Modules/_io/textio.c:29 _Py_IDENTIFIER(writable): Modules/_io/bufferedio.c:27 _Py_IDENTIFIER(writable): Modules/_io/textio.c:33 Duplicated identifiers in other files: _Py_IDENTIFIER(append): Modules/_elementtree.c:2373 _Py_IDENTIFIER(append): Modules/_pickle.c:5056 _Py_IDENTIFIER(__bases__): Objects/abstract.c:2417 _Py_IDENTIFIER(__bases__): Objects/typeobject.c:2813 _Py_IDENTIFIER(builtins): pythonrun.c _Py_IDENTIFIER(builtins): Python/sysmodule.c:169 _Py_IDENTIFIER(__bytes__): Objects/bytesobject.c:2458 _Py_IDENTIFIER(__bytes__): Objects/object.c:563 _Py_IDENTIFIER(__class__): Objects/abstract.c:2492 _Py_IDENTIFIER(__class__): Objects/typeobject.c:42 _Py_IDENTIFIER(__class__): Python/codecs.c:470 _Py_IDENTIFIER(__class__): Python/compile.c:553 _Py_IDENTIFIER(close): Modules/_io/bufferedio.c:16 _Py_IDENTIFIER(close): Modules/_io/fileio.c:129 _Py_IDENTIFIER(close): Modules/_io/textio.c:14 _Py_IDENTIFIER(close): Modules/mmapmodule.c:707 _Py_IDENTIFIER(close): Modules/ossaudiodev.c:540 _Py_IDENTIFIER(close): Modules/selectmodule.c:1513 _Py_IDENTIFIER(close): Objects/genobject.c:173 _Py_IDENTIFIER(close): Python/traceback.c:235 _Py_IDENTIFIER(__delitem__): Objects/typeobject.c:5132 _Py_IDENTIFIER(__delitem__): Objects/typeobject.c:5183 _Py_IDENTIFIER(__dict__): Modules/arraymodule.c:2040 _Py_IDENTIFIER(__dict__): Modules/_collectionsmodule.c:894 _Py_IDENTIFIER(__dict__): Modules/_pickle.c:5204 _Py_IDENTIFIER(__dict__): Objects/bytearrayobject.c:2704 _Py_IDENTIFIER(__dict__): Objects/moduleobject.c:479 _Py_IDENTIFIER(__dict__): Objects/setobject.c:1946 _Py_IDENTIFIER(__dict__): Objects/typeobject.c:43 _Py_IDENTIFIER(__dict__): Parser/asdl_c.py:702 _Py_IDENTIFIER(__dict__): Python/bltinmodule.c:1942 _Py_IDENTIFIER(__dict__): Python/ceval.c:4660 _Py_IDENTIFIER(__dict__): Python/Python-ast.c:544 _Py_IDENTIFIER(__doc__): Objects/descrobject.c:1443 _Py_IDENTIFIER(__doc__): Objects/typeobject.c:44 _Py_IDENTIFIER(enable): Modules/faulthandler.c:1050 _Py_IDENTIFIER(enable): Modules/_posixsubprocess.c:50 _Py_IDENTIFIER(encoding): Python/bltinmodule.c:1716 _Py_IDENTIFIER(encoding): Python/pythonrun.c:1359 _Py_IDENTIFIER(encoding): Python/sysmodule.c:107 _Py_IDENTIFIER(filename): Python/errors.c:932 _Py_IDENTIFIER(filename): Python/pythonrun.c:1634 _Py_IDENTIFIER(fileno): Modules/faulthandler.c:133 _Py_IDENTIFIER(fileno): Modules/_io/_iomodule.c:238 _Py_IDENTIFIER(fileno): Modules/_io/textio.c:17 _Py_IDENTIFIER(fileno): Objects/fileobject.c:200 _Py_IDENTIFIER(fileno): Python/bltinmodule.c:35 _Py_IDENTIFIER(flush): Modules/faulthandler.c:134 _Py_IDENTIFIER(flush): Modules/_io/bufferedio.c:18 _Py_IDENTIFIER(flush): Modules/_io/textio.c:18 _Py_IDENTIFIER(flush): Python/bltinmodule.c:1550 _Py_IDENTIFIER(flush): Python/bltinmodule.c:36 _Py_IDENTIFIER(flush): Python/pythonrun.c:2120 _Py_IDENTIFIER(flush): Python/pythonrun.c:519 _Py_IDENTIFIER(__getinitargs__): Modules/_datetimemodule.c:3075 _Py_IDENTIFIER(__getinitargs__): Modules/_pickle.c:4501 _Py_IDENTIFIER(TextIOWrapper): Python/pythonrun.c:1005 _Py_IDENTIFIER(TextIOWrapper): Python/traceback.c:237 _Py_IDENTIFIER(__getstate__): Modules/_datetimemodule.c:3076 _Py_IDENTIFIER(__getstate__): Objects/typeobject.c:3448 _Py_IDENTIFIER(__import__): Python/ceval.c:2428 _Py_IDENTIFIER(__import__): Python/import.c:1230 _Py_IDENTIFIER(__module__): Objects/typeobject.c:48 _Py_IDENTIFIER(__module__): Python/errors.c:840 _Py_IDENTIFIER(__module__): Python/pythonrun.c:1916 _Py_IDENTIFIER(__name__): Objects/classobject.c:17 _Py_IDENTIFIER(__name__): Objects/typeobject.c:49 _Py_IDENTIFIER(__name__): Objects/weakrefobject.c:159 _Py_IDENTIFIER(__name__): Python/_warnings.c:260 _Py_IDENTIFIER(__name__): Python/codecs.c:471 _Py_IDENTIFIER(__name__): Python/import.c:1234 _Py_IDENTIFIER(__new__): Modules/_ctypes/callproc.c:1643
[issue19514] Merge duplicated _Py_IDENTIFIER identifiers in C code
STINNER Victor added the comment: See also issue #19515 which is more general. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19514 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19516] segmentation fault using a dict as a key
New submission from Michael Merickel:
I assume there is some incompatibility in the maverick's C runtime, but getting
a segfault only on the python binaries from python.org.
Version shipped by Apple OS X 10.9 Mavericks:
~❯ python2.7
Python 2.7.5 (default, Sep 12 2013, 21:33:34)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type help, copyright, credits or license for more information.
foo = {}
foo[{}] = 1
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unhashable type: 'dict'
2.7 binary installed from python.org:
~❯ /Library/Frameworks/Python.framework/Versions/2.7/bin/python
Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or license for more information.
foo = {}
foo[{}] = 1
[1]4517 segmentation fault
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
3.3 binary installed from python.org:
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or license for more information.
foo = {}
foo[{}] = 1
[1]1898 segmentation fault python
--
assignee: ronaldoussoren
components: Macintosh
messages: 202303
nosy: mmerickel, ronaldoussoren
priority: normal
severity: normal
status: open
title: segmentation fault using a dict as a key
type: crash
versions: Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19516
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19516] segmentation fault using a dict as a key
Changes by Philip Jenvey pjen...@underboss.org: -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19516 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19516] segmentation fault using a dict as a key
Tim Peters added the comment: Sure looks like the bug where virtually _any_ two lines entered in the shell cause a segfault. -- nosy: +tim.peters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19516 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19516] segmentation fault using a dict as a key
Tim Peters added the comment: Betting this is a duplicate of: http://bugs.python.org/issue18458 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19516 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19516] segmentation fault using a dict as a key
Ned Deily added the comment: It is a duplicate. Fixed in 3.3.3 and 2.7.6. -- resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19516 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19516] segmentation fault using a dict as a key
Ned Deily added the comment: P.S. See that issue for a workaround. Also release candidate installers for 3.3.3 and 2.7.6 are now available with final releases very soon. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19516 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19514] Merge duplicated _Py_IDENTIFIER identifiers in C code
Changes by Andrei Dorian Duma andrei.duma.dor...@gmail.com: -- nosy: +andrei.duma ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19514 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19515] Share duplicated _Py_IDENTIFIER identifiers in C code
STINNER Victor added the comment: _Py_IDENTIFIER(__delitem__): Objects/typeobject.c:5132 _Py_IDENTIFIER(__delitem__): Objects/typeobject.c:5183 I moved this one to #19514. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19515 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19514] Merge duplicated _Py_IDENTIFIER identifiers in C code
STINNER Victor added the comment: Oh, I forgot: _Py_IDENTIFIER(__delitem__): Objects/typeobject.c:5132 _Py_IDENTIFIER(__delitem__): Objects/typeobject.c:5183 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19514 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
