Re: [Python-Dev] Why not using the hash when comparing strings?
On 10/19/2012 03:22 AM, Benjamin Peterson wrote: It would be interesting to see how common it is for strings which have their hash computed to be compared. Since all identifier-like strings mentioned in Python are interned, and therefore have had their hash computed, I would imagine comparing them to be fairly common. After all, strings are often used as makeshift enums in Python. On the flip side, those strings are typically small, so a measurable overall speed improvement brought by such a change seems unlikely. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why not using the hash when comparing strings?
Hrvoje Niksic hrvoje.nik...@avl.com wrote: On 10/19/2012 03:22 AM, Benjamin Peterson wrote: It would be interesting to see how common it is for strings which have their hash computed to be compared. Since all identifier-like strings mentioned in Python are interned, and therefore have had their hash computed, I would imagine comparing them to be fairly common. After all, strings are often used as makeshift enums in Python. On the flip side, those strings are typically small, so a measurable overall speed improvement brought by such a change seems unlikely. I'm pretty sure it would result in a small slowdown. Many (most?) of the comparisons against interned identifiers will be done by dictionary lookups and the dictionary lookup code only tries the string comparison after it has determined that the hashes match. The only time dictionary key strings contents are actually compared is when the hash matches but the pointers are different; it is already the case that if the hashes don't match the strings are never compared. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rejecting PEPs 407 and 413?
On 10/18/2012 08:02 PM, Nick Coghlan wrote: With the 3.4 release PEP published using a traditional schedule, perhaps MvL would care to do the honours as BDFL-Delegate in rejecting the two faster release cycle for the standard library PEPs? (I know I asked to hold off on that when MvL last brought it up, but I've since realised that do the first alpha early isn't a stand-alone PEP, it's just a matter of convincing Larry it's worthwhile and negotiating timing with the release team after there are some release-worthy features on trunk) FWIW I don't think those peps should be rejected simply because I didn't follow either for the 3.4 release schedule. I think they should both have their day in the court of public opinion. (Of course, maybe that day has already passed.) //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rejecting PEPs 407 and 413?
On Fri, Oct 19, 2012 at 9:01 PM, Larry Hastings la...@hastings.org wrote: FWIW I don't think those peps should be rejected simply because I didn't follow either for the 3.4 release schedule. I think they should both have their day in the court of public opinion. (Of course, maybe that day has already passed.) Martin wanted to mark them rejected a while ago - reaction was decidedly mixed, and the burden of proof to justify the extra workload and complexity certainly wasn't met. I asked him to hold off because I was planning to update 413 to the simple early alphas idea, but: 1. That's up to the RM rather than really needing a PEP 2. Even if it was a PEP level suggestion, a new PEP would be better for a new idea anyway At the moment, with the 3.4 used throughout the examples in both PEPs, it's a little confusing w.r.t the actual 3.4 release PEP. I could live with Deferred instead of Rejected, but one or the other should happen. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why not using the hash when comparing strings?
2012/10/19 Benjamin Peterson benja...@python.org: It would be interesting to see how common it is for strings which have their hash computed to be compared. I implemented a quick hack. When running ./python -m test test_os: Python calls PyUnicode_RichCompare() 15206 times with Py_EQ or Py_NE operator. In 41.4% (6295 calls), the hash of the two operands is known. In 41.2% (6262 times on 15206), the hash of the two operands are known *and are different*! The hit rate may depend since when the process was started. For example, in a fresh interpreter: the hit rate is only 7% (189 hit / 2703 calls). When running the test suite, the hit rate is around 80% (hashs are known in 90%) after running 70 tests. At the same time, the average of string length is 4.1 characters and quite all strings are pure ASCII. I create the issue http://bugs.python.org/issue16286 to discuss this optimization. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why not using the hash when comparing strings?
2012/10/19 Duncan Booth duncan.bo...@suttoncourtenay.org.uk: Hrvoje Niksic hrvoje.nik...@avl.com wrote: On 10/19/2012 03:22 AM, Benjamin Peterson wrote: It would be interesting to see how common it is for strings which have their hash computed to be compared. Since all identifier-like strings mentioned in Python are interned, and therefore have had their hash computed, I would imagine comparing them to be fairly common. After all, strings are often used as makeshift enums in Python. On the flip side, those strings are typically small, so a measurable overall speed improvement brought by such a change seems unlikely. I'm pretty sure it would result in a small slowdown. Dictionary code has its own special path for string comparisons, so this is not an issue. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why not using the hash when comparing strings?
On 19 October 2012 11:02, Duncan Booth duncan.bo...@suttoncourtenay.org.uk wrote: Hrvoje Niksic hrvoje.nik...@avl.com wrote: On 10/19/2012 03:22 AM, Benjamin Peterson wrote: It would be interesting to see how common it is for strings which have their hash computed to be compared. Since all identifier-like strings mentioned in Python are interned, and therefore have had their hash computed, I would imagine comparing them to be fairly common. After all, strings are often used as makeshift enums in Python. On the flip side, those strings are typically small, so a measurable overall speed improvement brought by such a change seems unlikely. I'm pretty sure it would result in a small slowdown. Many (most?) of the comparisons against interned identifiers will be done by dictionary lookups and the dictionary lookup code only tries the string comparison after it has determined that the hashes match. The only time dictionary key strings contents are actually compared is when the hash matches but the pointers are different; it is already the case that if the hashes don't match the strings are never compared. My understanding is that: The first part of string comparison is an identity check (pointer comparison) which catches the case of comparing two equal interned strings. What is not checked for is comparing two unequal interned strings (check both strings are interned and then conclude that unequal pointers means unequal strings). The hashes are also not checked during a standard string comparison. The lengths are also not checked since the unicode_compare function is a generic cmp() function for a rich comparison rather than a specific function for equal/unequal comparison: http://hg.python.org/cpython/file/321414874b26/Objects/unicodeobject.c#l6114 Most string comparisons occur during dict lookup in which case the hash is (implicitly?) checked before the strings are compared. A second hash comparison in this case would often be redundant. My *opinion* is that: On average character by character string comparison stops very quickly after comparing 1 or 2 characters. If this is assumed to be the case then it might be wasteful to check whether the strings have hashes and then compare the hashes (likewise for checking whether they are interned). This was the subject of lengthy debate in the recent python-list thread comparing strings from the back: http://mail.python.org/pipermail/python-list/2012-September/629866.html Consider the case where the strings are not interned, non-empty, and differ in the first character: def current(s1, s2): if s1 is s2: return True elif s1.len 0 and s2.len 0 and s1[0] != s2[0]: return False # Most of the time we don't reach this point ... def proposed_hashcheck(s1, s2): if s1 is s2: return True elif s1.hash is not None and s2.hash is not None and s1.hash != s2.hash: return False # I think we often reach this point when not comparing within a dict elif s1.len 0 and s2.len 0 and s1[0] != s2[0]: return False ... When comparing within a dict the hash check (modulo dict size) is already implicitly likely-affirmative and I assume (I'm not sure) that the full hashes are explicitly checked before comparing the strings. Either way I think that the additional hash check within the string comparison will normally be redundant. When not comparing within a dict, it's hard to say how often the strings have hashes but if they usually don't then the extra hash-check will normally be redundant in that case as well. If the character by character comparison fails at the first character it may be quicker to optimise for that case than checking if both hashes are present and then comparing the hashes. Other potential optimisations include comparing length before comparing characters: def proposed_lencheck(s1, s2): if s1 is s2: return True elif s1.len != s2.len: return False elif s1.len 0 and s2.len 0 and s1[0] != s2[0]: return False ... In the above I'm trying to represent the fast path when comparing strings that differ in the first character. One case that isn't helped by either of length or hash checking is comparing equal strings: you always need to check all the characters (unless the identity check succeeds). Depending on how often unequal interned strings are compared another method could be: def proposed_interncheck(s1, s2): if s1 is s2: return True elif s1.interned and s2.interned: return False elif s1.len 0 and s2.len 0 and s1[0] != s2[0]: return False ... All of these solutions add complexity over the current method and require the string comparison functions to be refactored from the current generic rich compare method. None of them (I think) would help much when
Re: [Python-Dev] cpython (2.7): Issue #6074: Restore the long-broken support for running with read-only source
On 19.10.12 14:58, nick.coghlan wrote: http://hg.python.org/cpython/rev/321414874b26 changeset: 79827:321414874b26 branch: 2.7 parent: 79814:2f0770cc6d3f user:Nick Coghlan ncogh...@gmail.com date:Fri Oct 19 21:58:18 2012 +1000 summary: Issue #6074: Restore the long-broken support for running with read-only source files on Windows +def _iter_files(name): for f in (name + os.extsep + py, name + os.extsep + pyc, name + os.extsep + pyo, name + os.extsep + pyw, name + $py.class): +yield f Why not just return (name + os.extsep + py, name + os.extsep + pyc, name + os.extsep + pyo, name + os.extsep + pyw, name + $py.class) ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why not using the hash when comparing strings?
On Fri, Oct 19, 2012 at 8:36 AM, Victor Stinner victor.stin...@gmail.comwrote: 2012/10/19 Benjamin Peterson benja...@python.org: It would be interesting to see how common it is for strings which have their hash computed to be compared. I implemented a quick hack. When running ./python -m test test_os: Python calls PyUnicode_RichCompare() 15206 times with Py_EQ or Py_NE operator. In 41.4% (6295 calls), the hash of the two operands is known. In 41.2% (6262 times on 15206), the hash of the two operands are known *and are different*! The hit rate may depend since when the process was started. For example, in a fresh interpreter: the hit rate is only 7% (189 hit / 2703 calls). When running the test suite, the hit rate is around 80% (hashs are known in 90%) after running 70 tests. At the same time, the average of string length is 4.1 characters and quite all strings are pure ASCII. I create the issue http://bugs.python.org/issue16286 to discuss this optimization. If you want to measure the performance impact compared to a clean build then you can use the unladen benchmarks as it contains several Python 3-compatible benchmarks now. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] return type of __complex__
Hi, while fixing pypy to pass CPython 3.2 tests, I found what I think it's a inconsistency in how CPython (both 2.7 and 3.2) handles __complex__: class Obj: ... def __complex__(self): ... return 2.0 ... obj = Obj() complex(obj) (2+0j) import cmath cmath.acos(obj) Traceback (most recent call last): File stdin, line 1, in module TypeError: __complex__ should return a complex object i.e., the complex constructor does not check that __complex__ returns an actual complex, while the cmath functions do. To me it looks like a bug in complex_new which should do the check as well; however, there is a test in test_complex.test_constructor which checks that returning a float actually works. Is that the real intended behavior? ciao, Anto ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Issue #6074: Restore the long-broken support for running with read-only source
On Fri, Oct 19, 2012 at 11:36 PM, Serhiy Storchaka storch...@gmail.com wrote: Why not just return (name + os.extsep + py, name + os.extsep + pyc, name + os.extsep + pyo, name + os.extsep + pyw, name + $py.class) No good reason - I copied the shape of the existing code without really thinking about it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni anto.c...@gmail.com wrote: Is that the real intended behavior? Given the way complex numbers interact with floats generally, returning a complex number with no imaginary component as a floating point value seems legitimate and the checks in cmath overly strict. Otherwise you would get redundancy like: def __complex__(self): return complex(value) or def __complex__(self): return value + 0j More importantly, relaxing the checks in cmath is backwards compatible. while tightening up the checks in complex_new is not. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rejecting PEPs 407 and 413?
On Oct 19, 2012, at 09:33 PM, Nick Coghlan wrote: At the moment, with the 3.4 used throughout the examples in both PEPs, it's a little confusing w.r.t the actual 3.4 release PEP. I could live with Deferred instead of Rejected, but one or the other should happen. I no longer have much interest (or frankly, time) to pursue PEP 407. Deferred seems about right to me. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 426 comment: field order
On Oct 18, 2012, at 09:23 PM, Daniel Holth wrote: The email module provides an ordered multidict interface to the data. The first tag wins (if you improperly define Name: twice for example), but the order of everything is preserved. We just don't need it, except that it might be surprising to see your classifiers randomly re-ordered. Just to be clear, the email package preserves both the order and presence of headers. So if you do add Name: twice, both will be retained. Plenty of email headers (e.g. Received) can appear multiple times. The getitem API will indeed return just the first entry, but there is an alternative API that you can use to get all of them, in order. Deletions and re-insertions obviously change the order (the insertion is always an append), although there is a .replace_header() method for preserving existing order (kind of - only for the first instance of a header). Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 426 comment: field order
On Fri, Oct 19, 2012 at 10:20 AM, Barry Warsaw ba...@python.org wrote: On Oct 18, 2012, at 09:23 PM, Daniel Holth wrote: The email module provides an ordered multidict interface to the data. The first tag wins (if you improperly define Name: twice for example), but the order of everything is preserved. We just don't need it, except that it might be surprising to see your classifiers randomly re-ordered. Just to be clear, the email package preserves both the order and presence of headers. So if you do add Name: twice, both will be retained. Plenty of email headers (e.g. Received) can appear multiple times. The getitem API will indeed return just the first entry, but there is an alternative API that you can use to get all of them, in order. Deletions and re-insertions obviously change the order (the insertion is always an append), although there is a .replace_header() method for preserving existing order (kind of - only for the first instance of a header). It's a nice interface. I was surprised that there is no collections.OrderedMultiDict. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On 10/19/2012 04:13 PM, Nick Coghlan wrote: On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni anto.c...@gmail.com wrote: Is that the real intended behavior? Given the way complex numbers interact with floats generally, returning a complex number with no imaginary component as a floating point value seems legitimate and the checks in cmath overly strict. Otherwise you would get redundancy like: def __complex__(self): return complex(value) or def __complex__(self): return value + 0j More importantly, relaxing the checks in cmath is backwards compatible. while tightening up the checks in complex_new is not. indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? ciao, Anto ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:26 AM, Benjamin Peterson wrote: 2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. Why not 2.7? It is a perfectly-backward-compatible change: no currenly-working code could possibly break if cmath's restriction was relaxed. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCBdnUACgkQ+gerLs4ltQ77AQCgz90IKFRobiymE8yJmYhK+Axd R3IAoMfZRBz40rOXk31QJmtQCnafaOnR =dean -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
2012/10/19 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:26 AM, Benjamin Peterson wrote: 2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. Why not 2.7? It is a perfectly-backward-compatible change: no currenly-working code could possibly break if cmath's restriction was relaxed. It's a new feature. Also, it's possible that someone is relying on it throwing for non-complex values. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-10-12 - 2012-10-19) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3815 (+26) closed 24249 (+48) total 28064 (+74) Open issues with patches: 1701 Issues opened (58) == #2350: 'exceptions' import fixer http://bugs.python.org/issue2350 reopened by brett.cannon #11009: urllib.splituser is not documented http://bugs.python.org/issue11009 reopened by techtonik #16215: Possible double memory free in str.replace http://bugs.python.org/issue16215 opened by serhiy.storchaka #16216: Arithmetic operations with NULL http://bugs.python.org/issue16216 opened by serhiy.storchaka #16217: Tracebacks are unnecessarily verbose when using 'python -m' http://bugs.python.org/issue16217 opened by mattheww #16218: Python launcher does not support non ascii characters http://bugs.python.org/issue16218 opened by turncc #16219: segfault when using xml.etree.ElementTree.XMLTreeBuilder http://bugs.python.org/issue16219 opened by scottmax #16220: wsgiref does not call close() on iterable response http://bugs.python.org/issue16220 opened by btubbs #16221: tokenize.untokenize() compat mode misses the encoding when u http://bugs.python.org/issue16221 opened by eric.snow #16222: some terms not found by devguide's search box http://bugs.python.org/issue16222 opened by chris.jerdonek #16223: untokenize returns a string if no encoding token is recognized http://bugs.python.org/issue16223 opened by eric.snow #16224: tokenize.untokenize() misbehaves when moved to compatiblity m http://bugs.python.org/issue16224 opened by eric.snow #16228: JSON crashes during encoding resized lists http://bugs.python.org/issue16228 opened by serhiy.storchaka #16229: Demo *redemo.py* lacking in Windows installation http://bugs.python.org/issue16229 opened by fgracia #16230: select.select crashes on resized lists http://bugs.python.org/issue16230 opened by serhiy.storchaka #16231: pickle persistent_id return value http://bugs.python.org/issue16231 opened by pschaafsma #16232: curses.textpad.Textbox backtrace support http://bugs.python.org/issue16232 opened by emeaudroid.emeaudroid #16233: IDLE: conceptual problems with *Class browser* http://bugs.python.org/issue16233 opened by fgracia #16234: Implement correct block_size and tests for HMAC-SHA3 http://bugs.python.org/issue16234 opened by christian.heimes #16235: Add python-config.sh for use during cross compilation. http://bugs.python.org/issue16235 opened by Ray.Donnelly #16236: Doc/Makefile should have $PYTHON=python2 http://bugs.python.org/issue16236 opened by maker #16237: bdist_rpm SPEC files created with distutils may be distro spec http://bugs.python.org/issue16237 opened by ncoghlan #16238: Automatically remove build directory when build options change http://bugs.python.org/issue16238 opened by techtonik #16239: PEP8 arithmetic operator examples http://bugs.python.org/issue16239 opened by pwuertz #16240: Document a way to escape metacharacters in glob/fnmatch http://bugs.python.org/issue16240 opened by serhiy.storchaka #16241: -X faulthandler is not documented in -X option docs http://bugs.python.org/issue16241 opened by ramchandra.apte #16242: Pickle and __getattr__ http://bugs.python.org/issue16242 opened by powderflask #16243: Regression in inspect module http://bugs.python.org/issue16243 opened by belopolsky #16245: Update html.entities.html5 dictionary and parseentities.py http://bugs.python.org/issue16245 opened by ezio.melotti #16246: Multiprocessing infinite loop on Windows http://bugs.python.org/issue16246 opened by stoneleaf #16247: Report failing url in URLError? http://bugs.python.org/issue16247 opened by ncoghlan #16248: Security bug in tkinter allows for untrusted, arbitrary code e http://bugs.python.org/issue16248 opened by ramchandra.apte #16250: URLError invoked with reason as filename http://bugs.python.org/issue16250 opened by chris.jerdonek #16251: pickle special methods are looked up on the instance rather th http://bugs.python.org/issue16251 opened by eric.snow #16252: bytes and bytearray methods are undocumented http://bugs.python.org/issue16252 opened by pitrou #16253: Docs for PyArg_ParseTupleAndKeywords say it doesn't accept nes http://bugs.python.org/issue16253 opened by rupole #16254: PyUnicode_AsWideCharString() increases string size http://bugs.python.org/issue16254 opened by dabeaz #16255: subrocess.Popen needs /bin/sh but Android only has /system/bin http://bugs.python.org/issue16255 opened by brousch #16256: permissions wrong on Mac doc dir http://bugs.python.org/issue16256 opened by Chris.Barker #16258: test_local.TestEnUSCollection failures on Solaris 10 http://bugs.python.org/issue16258 opened by trent #16259: Replace exec() in test.regrtest with __import__ http://bugs.python.org/issue16259 opened by
Re: [Python-Dev] return type of __complex__
On Fri, Oct 19, 2012 at 5:56 PM, Benjamin Peterson benja...@python.org wrote: 2012/10/19 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:26 AM, Benjamin Peterson wrote: 2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. Why not 2.7? It is a perfectly-backward-compatible change: no currenly-working code could possibly break if cmath's restriction was relaxed. It's a new feature. Also, it's possible that someone is relying on it throwing for non-complex values. Nick just said it's a bug that cmath type checks are too strict. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On Fri, Oct 19, 2012 at 4:26 PM, Benjamin Peterson benja...@python.org wrote: 2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. +1 for relaxing the check in 3.x. The cmath code uses PyArg_ParseTuple(args, D, ...) for this; perhaps it's the D format for PyArg_ParseTuple that should be relaxed. It seems more than reasonable to allow floats wherever a complex number is expected. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
Am 19.10.2012 18:23, schrieb Maciej Fijalkowski: Nick just said it's a bug that cmath type checks are too strict. I'm not so sure about that. cmath just uses PyArg_ParseTuple with D which itself relies upon PyComplex_AsCComplex(). D (complex) [Py_complex] Convert a Python complex number to a C Py_complex structure. In order to fix the bug the code in PyComplex_AsCComplex() must be altered to support float as return type from __complex__(). That's a major change. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On Fri, Oct 19, 2012 at 5:31 PM, Christian Heimes christ...@python.org wrote: In order to fix the bug the code in PyComplex_AsCComplex() must be altered to support float as return type from __complex__(). That's a major change. Agreed that this doesn't seem appropriate for bugfix releases. We might also want to consider having PyComplex_AsCComplex check for __float__, again for consistency with the 'complex' constructor: class A(object): ... def __float__(self): ... return 42.0 ... a = A() float(a) 42.0 complex(a) (42+0j) Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:56 AM, Benjamin Peterson wrote: 2012/10/19 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:26 AM, Benjamin Peterson wrote: 2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. Why not 2.7? It is a perfectly-backward-compatible change: no currenly-working code could possibly break if cmath's restriction was relaxed. It's a new feature. That is an assertion; I can dqually assert that the current over-strict typechecking is a bug, because it doesn't conform to the semandics of 'comples_new'. Also, it's possible that someone is relying on it throwing for non-complex values. No already working, non-contrived code would break, becuase float is perfectly-promotable to complex. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCBg2cACgkQ+gerLs4ltQ5SMACfbhAMwQCwkZi1dF4WGL9uZoeR wv4AoII2FVW8TPchCcmsh3llo7QPxroW =gqkG -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
2012/10/19 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:56 AM, Benjamin Peterson wrote: 2012/10/19 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:26 AM, Benjamin Peterson wrote: 2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. Why not 2.7? It is a perfectly-backward-compatible change: no currenly-working code could possibly break if cmath's restriction was relaxed. It's a new feature. That is an assertion; I can dqually assert that the current over-strict typechecking is a bug, because it doesn't conform to the semandics of 'comples_new'. Nobody claimed it did conform to semantics of complex_new. Also, it's possible that someone is relying on it throwing for non-complex values. No already working, non-contrived code would break, becuase float is perfectly-promotable to complex. I'm not saying the code which would break is good, I'm just saying it shouldn't be broken in bugfix releases. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On Fri, Oct 19, 2012 at 12:48 PM, Benjamin Peterson benja...@python.orgwrote: 2012/10/19 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:56 AM, Benjamin Peterson wrote: 2012/10/19 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:26 AM, Benjamin Peterson wrote: 2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. Why not 2.7? It is a perfectly-backward-compatible change: no currenly-working code could possibly break if cmath's restriction was relaxed. It's a new feature. That is an assertion; I can dqually assert that the current over-strict typechecking is a bug, because it doesn't conform to the semandics of 'comples_new'. Nobody claimed it did conform to semantics of complex_new. This also leads to a voluntary dovetailing of what would be accepted between bugfix releases. Anyone remember True/False coming into existence between bugfix releases? Wasn't that fun? And in case someone didn't pick up on the sarcasm, it wasn't fun and it's why we don't widen acceptability of things between bugfix releases unless it is actually breaking code as-is (which this isn't). Also, it's possible that someone is relying on it throwing for non-complex values. No already working, non-contrived code would break, becuase float is perfectly-promotable to complex. I'm not saying the code which would break is good, I'm just saying it shouldn't be broken in bugfix releases Agreed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On 10/19/2012 06:44 PM, Tres Seaver wrote: On 10/19/2012 11:56 AM, Benjamin Peterson wrote: 2012/10/19 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2012 11:26 AM, Benjamin Peterson wrote: 2012/10/19 Antonio Cuni anto.c...@gmail.com: indeed, you are right. So I suppose that in pypy we could just relax the check in cmath and be happy. Is there any chance that this will be changed in 2.7 and/or 3.x? Certainly 3.x, but not 2.7. Why not 2.7? It is a perfectly-backward-compatible change: no currenly-working code could possibly break if cmath's restriction was relaxed. It's a new feature. That is an assertion; I can dqually assert that the current over-strict typechecking is a bug, because it doesn't conform to the semandics of 'comples_new'. Maybe, but an assertion made by the 2.7 release manager tends to be the stronger one :) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
Antonio Cuni wrote: Traceback (most recent call last): File stdin, line 1, in module TypeError: __complex__ should return a complex object i.e., the complex constructor does not check that __complex__ returns an actual complex, while the cmath functions do. Looks to me like cmath is being excessively finicky here. Why shouldn't a float be usable in *any* context expecting a complex? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On Sat, Oct 20, 2012 at 2:23 AM, Maciej Fijalkowski fij...@gmail.com wrote: On Fri, Oct 19, 2012 at 5:56 PM, Benjamin Peterson benja...@python.org wrote: It's a new feature. Also, it's possible that someone is relying on it throwing for non-complex values. Nick just said it's a bug that cmath type checks are too strict. It wouldn't be the first time PyPy has picked up on something that is technically a bug in CPython that we nevertheless deemed too risky to fix in CPython maintenance releases (the other main one I'm aware of is the fact we sometimes get the + and * operand precedence wrong for sequence types implemented in C). I don't see the same level of risk here that Benjamin does (it's not like the conversion process would be *returning* a float value, just taking the + 0j as implied when handed a floating point value by __complex__, the same way the constructor does), but it's still the RMs call as to what's acceptable for a maintenance release. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
Maciej Fijalkowski writes: Nick just said it's a bug that cmath type checks are too strict. It's a design bug, yes. The question is, does it conform to documented behavior? If so, it's not an implementation bug that should be fixed in 2.7. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] accept the wheel PEPs 425, 426, 427
Daniel Holth writes: Tweaked at http://hg.python.org/peps/rev/75474fb879d3 I'll take a look later; I have some other commitments now I should do first. On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull step...@xemacs.org wrote: Executive summary: You probably should include a full ABNF grammar The legacy PKG-INFO does not have email parse-ability. How about an example parser implementation instead, and drop email.parser.Parser() support. It will require a decent amount of additional editing. I don't think that the example implementation matters. A strict RFC 822 email header parser that treats these as unstructured fields will DTRT. The point about the ABNF grammar is based on the email community's long experience with email standards (733, 822, 2822, 5322, ...). It's always easier to relax definitions later when they prove too strict rather than tighten them up. There is less RFC822 in the document now. Thank you. Typo fixed. The ability to put the full license in a separate file exists, but would be part of the .dist-info spec. These files are parsed at runtime and it's obnoxious to have long descriptions and licenses in there. Good. Switched to using must as in RFC MUST for extension fields ExtensionName/TagName: Good. Thanks for your excellent responsiveness. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
Stephen J. Turnbull wrote: It's a design bug, yes. The question is, does it conform to documented behavior? The 2.7 docs say this about __complex__: Called to implement the built-in function complex() ... Should return a value of the appropriate type. So the question is whether float is an appropriate type when you're expecting a complex. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] return type of __complex__
On Fri, Oct 19, 2012 at 10:13 AM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni anto.c...@gmail.com wrote: Is that the real intended behavior? Given the way complex numbers interact with floats generally, returning a complex number with no imaginary component as a floating point value seems legitimate and the checks in cmath overly strict. Otherwise you would get redundancy like: def __complex__(self): return complex(value) or def __complex__(self): return value + 0j No you wouldn't: def __float__(self): return value -- Devin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
