[issue19713] Deprecate various things in importlib thanks to PEP 451

Eric Snow added the comment: I'd meant to do that. I'll update the patch when I have a chance. -- ___ Python tracker ___ ___ Python-b

[issue19713] Deprecate various things in importlib thanks to PEP 451

Serhiy Storchaka added the comment: Could you please use correct stacklevel, such that warnings will point to places where deprecated function used, not where they are defined? -- nosy: +serhiy.storchaka ___ Python tracker

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Thank you, Victor and Serhiy, for your pointers into the code. I'm hoping we have general agreement about %c, %o, %x, and %X and having them use __index__ only (using __int__ would open the door to float conversions). I still have a question about %i, though. T

[issue19717] resolve() fails when the path doesn't exist

Serhiy Storchaka added the comment: Vajrasky's patch implements fourth strategy, which is not conform neither --canonicalize nor --canonicalize-missing. Path(BASE, 'foo', 'in', 'spam') is resolved to Path(BASE, 'foo'). I doubt that this is most expected behavior. -- __

[issue19713] Deprecate various things in importlib thanks to PEP 451

Eric Snow added the comment: Here's a patch that simply adds all the deprecation warnings. It does not include any effort to silence the zillion warnings that happen when the test suite is run with -Wall. I plan on addressing all those when I have some time. That will be a matter of refacto

[issue19710] Make sure documentation for PEP 451 is finished

Changes by Eric Snow : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue19710] Make sure documentation for PEP 451 is finished

Eric Snow added the comment: I'm leaving this as pending for the moment in case we notice anything I missed. -- status: pending -> open ___ Python tracker ___ ___

[issue19713] Deprecate various things in importlib thanks to PEP 451

Eric Snow added the comment: P.S. changeset b78de8029606 should have referred to #19710. -- ___ Python tracker ___ ___ Python-bugs-lis

[issue19713] Deprecate various things in importlib thanks to PEP 451

Eric Snow added the comment: The doc deprecations should now be complete. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue19710] Make sure documentation for PEP 451 is finished

Changes by Eric Snow : -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> pending type: -> enhancement ___ Python tracker ___

[issue19710] Make sure documentation for PEP 451 is finished

Eric Snow added the comment: New changeset 2c27c0e5bc50 by Eric Snow in branch 'default': Issue #19713: Update importlib docs for module spec changes, including deprecations. http://hg.python.org/cpython/rev/2c27c0e5bc50 New changeset b78de8029606 by Eric Snow in branch 'default': Issue #19713:

[issue19713] Deprecate various things in importlib thanks to PEP 451

Roundup Robot added the comment: New changeset 2c27c0e5bc50 by Eric Snow in branch 'default': Issue #19713: Update importlib docs for module spec changes, including deprecations. http://hg.python.org/cpython/rev/2c27c0e5bc50 New changeset b78de8029606 by Eric Snow in branch 'default': Issue #19

[issue20001] pathlib inheritance diagram too large

Roundup Robot added the comment: New changeset fe49ed665190 by Eli Bendersky in branch 'default': Issue #20001: Add the SVG source of the pathlib-inheritance diagram to Hg http://hg.python.org/cpython/rev/fe49ed665190 -- nosy: +python-dev ___ Python t

[issue20003] Language Ref "raise" doc misssing "from None"

New submission from rurpy: In the current (3.3.3 and 3.4dev) Language Reference Manual, the section on the Raise statement fails to mention that the second expression can be None (per PEP-409/415) or the special behavior (suppressing a chained exception) that ensues. Rather it explicitly stat

[issue19994] re.match does not return or takes long time

Tim Peters added the comment: @vajrasky, I didn't close it just because "the usual suspects" haven't chimed in yet. That is, it's a pretty common kind of report, and these usually attract the same kinds of comments pointing to other regexp implementations. So leaving it to "the regexp person

[issue19994] re.match does not return or takes long time

Vajrasky Kok added the comment: Tim, if you made this ticket as invalid, why don't you close it? Any reason? -- nosy: +vajrasky ___ Python tracker ___ ___

[issue19717] resolve() fails when the path doesn't exist

Vajrasky Kok added the comment: Updated patch to tip. Later, I refactor Windows code to make sure it does not loop forever. -- Added file: http://bugs.python.org/file33171/add_non_strict_resolve_pathlib_v4.patch ___ Python tracker

[issue19518] Add new PyRun_xxx() functions to not encode the filename

Changes by Nick Coghlan : -- priority: -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue19518] Add new PyRun_xxx() functions to not encode the filename

Nick Coghlan added the comment: Just getting this on Larry's radar and summarising the current position. The original problem: using "char *" to pass filenames around doesn't work properly on Windows, we need to use Unicode objects. The solution: parallel APIs that accept PyObject * rather tha

[issue19996] httplib infinite read on invalid header

R. David Murray added the comment: Heh. A missing header *name* was something I never considered in the email package tests. So yeah, that's worth handing one way or another. I'll put reviewing this on my TODO list, since I'm the maintainer of the email package. I'm updating the versions pe

[issue19997] imghdr.what doesn't accept bytes paths

Vajrasky Kok added the comment: Why limit to str and bytes. Open can accept integer as well. I am asking not suggesting. >>> with open('/tmp/cutecat.txt', 'wb') as f: ... f.write(b'cutecat') ... 7 >>> a = open('/tmp/cutecat.txt') >>> a.fileno() 3 >>> b = open(3) >>> b.read() 'cutecat' -

[issue7980] time.strptime not thread safe

R. David Murray added the comment: There's no patch posted here, and the issue is still open, so no. On the other hand, the way imports are handled in 3.3 and later is a bit different, and if I run the unit test (which does still fail for me on 2.7 tip) on 3.3 and 3.4 tip it passes. Given tha

[issue12263] punycode codec ignores the error handler argument

STINNER Victor added the comment: I prefer to not touch punycode right now, it works, there is no need to modify it. -- resolution: -> wont fix status: open -> closed ___ Python tracker __

[issue13024] cgitb uses stdout encoding

Changes by STINNER Victor : -- resolution: -> out of date status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue19518] Add new PyRun_xxx() functions to not encode the filename

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue19518] Add new PyRun_xxx() functions to not encode the filename

STINNER Victor added the comment: Sorry, but because of the bikeshedding, I'm not more interested to work on this issue. Don't hesitate to re-work my patch if you want to fix the bug ("On Windows, these changes should allow to pass an unencodable filename on the command line"). -- __

[issue19229] operator.py: move the Python implementation in the else block of try/except ImportError

Changes by STINNER Victor : -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue18733] elementtree: stop the parser more quickly on error

STINNER Victor added the comment: No reaction from Fred Drake, I don't know how to implement it and I'm no more interested to optimize this case, so I'm closing the issue. Reopen it with a patch if you are interested to work on it. -- resolution: -> wont fix status: open -> closed __

[issue18421] Refactor call_with_frame() function of pyexpat.c

STINNER Victor added the comment: I'm not really interested to refactory pyexpat.c code. If you are interested, open a new the issue with a patch. -- resolution: -> wont fix status: open -> closed ___ Python tracker

[issue18227] Use Python memory allocators in external libraries like zlib or OpenSSL

STINNER Victor added the comment: I modified modules when it was possible and easy to do. More modules should be modified, but it's more tricky. If you are interested, please open new issues. -- resolution: -> fixed status: open -> closed ___ Python

[issue16286] Use hash if available to optimize a==b and a!=b for bytes and str

STINNER Victor added the comment: If it's hard to see a real speedup, it's probably not interesting to use the hash in string comparison. -- resolution: -> invalid status: open -> closed ___ Python tracker __

[issue18283] shutil.which() should support bytes

STINNER Victor added the comment: which_bytes.patch does not work on Windows. According to Serhiy, it's a new feature and so should wait for Python 3.5. -- resolution: fixed -> status: closed -> open versions: +Python 3.5 -Python 3.4 ___ Python trac

[issue20001] pathlib inheritance diagram too large

STINNER Victor added the comment: Please include the SVG source of the diagram in the Python source code, so the picture can be regenerated. -- nosy: +haypo ___ Python tracker _

[issue20001] pathlib inheritance diagram too large

Eli Bendersky added the comment: The source for the diagram is here: https://docs.google.com/drawings/d/1F8do-1WL1sIGkZuiufcxcpZRtS0w4SwAowq-Uamrwt8/edit?usp=sharing Anyone - feel free to copy that doc over and create a new diagram with smaller whitespacing. Let me know if there are any proble

[issue19995] hex() and %x, oct() and %o do not behave the same

Serhiy Storchaka added the comment: In addition, PyLong_AsLong() calls __int__, while PyLong_AsUnsignedLong() doesn't call __int__. -- ___ Python tracker ___ ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: > Antoine, > > Does that mean you are reducing your previous statement of > > > So trying __index__ in str.format() sounds like a distraction. > > to "using __index__ for %d, %i, and %u is not correct, but is correct > for %c, %o, %x, and %X" ? Ah, yes, sorry

[issue19999] test_monotonic fails on x86 OpenIndiana

STINNER Victor added the comment: Hum, there is something wrong with this buildbot! http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.3/builds/1266/steps/test/logs/stdio == FAIL: test_monotonic (test.test_time.TimeT

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Antoine, Does that mean you are reducing your previous statement of > So trying __index__ in str.format() sounds like a distraction. to "using __index__ for %d, %i, and %u is not correct, but is correct for %c, %o, %x, and %X" ? -- ___

[issue18283] shutil.which() should support bytes

Changes by Arfrever Frehtes Taifersar Arahesis : -- stage: -> committed/rejected versions: +Python 3.4 -Python 3.5 ___ Python tracker ___ ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: > Antoine, if I understand you correctly, you are saying that any type > that defines __index__ is an integer, and should therefore also define > __int__, in which case Python can just use __int__ and not worry about > __index__? ... is an integer-like, yes. >

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Antoine, if I understand you correctly, you are saying that any type that defines __index__ is an integer, and should therefore also define __int__, in which case Python can just use __int__ and not worry about __index__? Here's the problem with that: --> '%x

[issue20002] Cleanup and microoptimize pathlib

Serhiy Storchaka added the comment: > Do you have performance numbers that show a significant improvement? No. The benefit is too small (but theoretically it should be). Some changes also simplify the code. This is why this patch should be applied now, while pathlib code is not frozen yet. Fo

[issue18283] shutil.which() should support bytes

Changes by STINNER Victor : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue18283] shutil.which() should support bytes

Roundup Robot added the comment: New changeset a1a05e2724dd by Victor Stinner in branch 'default': Issue #18283: shutil.which() now supports bytes argument, not only text argument. http://hg.python.org/cpython/rev/a1a05e2724dd -- nosy: +python-dev __

[issue20002] Cleanup and microoptimize pathlib

Antoine Pitrou added the comment: > Here is compatible with 2.7 part of the patch. It is important to > apply it before 3.4 release otherwise supporting different versions > will be more tedious. Do you have performance numbers that show a significant improvement? -- __

[issue20002] Cleanup and microoptimize pathlib

Serhiy Storchaka added the comment: Here is compatible with 2.7 part of the patch. It is important to apply it before 3.4 release otherwise supporting different versions will be more tedious. -- Added file: http://bugs.python.org/file33170/pathlib_cleanup_compatible.patch _

[issue18283] shutil.which() should support bytes

STINNER Victor added the comment: Almost all functions of the shutil module support bytes filenames. I tested shutil.copyfile(), shutil.ignore_patterns(), shutil.copytree(), shutil.rmtree() and shutil.move(). I only found one function which only support Unicode filenames: shutil.make_archive(

[issue19999] test_monotonic fails on x86 OpenIndiana

Roundup Robot added the comment: New changeset 4864c0b914ae by Victor Stinner in branch '3.3': Close #1: tolerate coarse time when testing time.monotonic() on very http://hg.python.org/cpython/rev/4864c0b914ae New changeset a34582c53911 by Victor Stinner in branch 'default': (Merge 3.3) Clos

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: > In other words > > - if %d or %u is specified, try __int__, then __index__ > (according to the docs, u is obsolete and identical to d) Again, I don't think trying __index__ is useful. > - if %i, %o, %x, %X, or %c is specified, try only __index__ I t

[issue18283] shutil.which() should support bytes

Serhiy Storchaka added the comment: All low-level functions in the os.path module supports string and bytes paths. But not all high-level functions in the shutil module supports bytes paths. Adding support for bytes paths will complicate implementation and tests. -- versions: +Python 3

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Ethan Furman previously stated: --- > So the complete list of spcecifiers then is d, i, o, u, U, and c [1], and they > should work if __index__ works. Okay, so 'd' then should be considered a conversion operation, whilst the others sho

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: > --> '%x' % 3.14 # calls __int__ > '3' > > One of those behaviours is wrong. Which? For '%x' and '%o', it probably doesn't make sense to convert the float to an int. (however, it does make sense for other formatters, such as '%d') -- __

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Antoine Pitrou opined: -- > I'm with Guido: it doesn't really make sense to allow __index__ but not > __int__ on > a type. So trying __index__ in str.format() sounds like a distraction. --> hex(3.14) # calls __index__ Traceback (most rece

[issue19998] Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain

Arfrever Frehtes Taifersar Arahesis added the comment: Modules/_ctypes/libffi directory contains a copy of externally maintained libffi library. Please report problem to libffi maintainers: https://github.com/atgreen/libffi -- nosy: +Arfrever ___ Pyt

[issue19995] hex() and %x, oct() and %o do not behave the same

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue20000] SSLContext.get_ca_certs() and self-signed certs

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue20002] Cleanup and microoptimize pathlib

Antoine Pitrou added the comment: Ok, since it makes backporting more tedious, I'd rather keep this for post-3.4. -- versions: +Python 3.5 -Python 3.4 ___ Python tracker ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: I'm with Guido: it doesn't really make sense to allow __index__ but not __int__ on a type. So trying __index__ in str.format() sounds like a distraction. -- ___ Python tracker ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Eric V. Smith commented: > If you were going to make this change, I'd think you'd have to look > for __index__ and then __int__. Does the order matter? Are there any types (and should there be) that would have both and return different a

[issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK

Christian Heimes added the comment: Thanks! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> pending ___ Python tracker ___

[issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK

Roundup Robot added the comment: New changeset 40955ae17472 by Christian Heimes in branch '3.3': Issue #19919: Fix flacky SSL test. connect_ex() sometimes returns http://hg.python.org/cpython/rev/40955ae17472 New changeset 593c3fa7aa2c by Christian Heimes in branch 'default': Issue #19919: Fix f

[issue19996] httplib infinite read on invalid header

Cory Benfield added the comment: Alright, here's a patch for the current tip. I'll need to prepare a different patch for earlier versions of Python, which will take me a little while longer to do (maybe not today). I've also signed a contributor agreement, but it doesn't look like that's propa

[issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK

Antoine Pitrou added the comment: Looks fine to me. -- stage: -> patch review versions: +Python 3.3 ___ Python tracker ___ ___ Python

[issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK

Christian Heimes added the comment: Here is a patch. -- keywords: +patch Added file: http://bugs.python.org/file33168/issue19919.patch ___ Python tracker ___

[issue20002] Cleanup and microoptimize pathlib

New submission from Serhiy Storchaka: Here is a patch which contains many small cleanups and optimizations for the pathlib module. Not all of them can be backported to 2.7 version. -- assignee: pitrou components: Library (Lib) files: pathlib_cleanup.patch keywords: patch messages: 20635

[issue19993] Pool.imap doesn't work as advertised

Tim Peters added the comment: Just for interest, I'll attach the worm-around I mentioned (imu.py). At this level it's a very simple implementation, but now that I look at it, it's actually a lazy implementation of imap() (or of an unimaginative ;-) imap_unordered()). -- Added file: h

[issue19930] os.makedirs('dir1/dir2', 0) always fails

Changes by Serhiy Storchaka : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue19921] Path.mkdir(0, True) always fails

Changes by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue19921] Path.mkdir(0, True) always fails

Roundup Robot added the comment: New changeset 87b81b7df7f0 by Antoine Pitrou in branch 'default': Issue #19921: When Path.mkdir() is called with parents=True, any missing parent is created with the default permissions, ignoring the mode argument (mimicking the POSIX "mkdir -p" command). http:/

[issue20001] pathlib inheritance diagram too large

New submission from Antoine Pitrou: The inheritance diagram at http://docs.python.org/dev/library/pathlib.html is too large, it can easily take up half the vertical space (or perhaps all of it on a smaller screen). The font size looks fine, it's just that there's a lot of spacing around. (of c

[issue19996] httplib infinite read on invalid header

Cory Benfield added the comment: Actually, that might be OK. I don't know the email package at all, but I suspect being able to handle empty header keys (by ignoring them) is a reasonable thing to do in the email case as well. Thoughts? -- ___ Pytho

[issue19921] Path.mkdir(0, True) always fails

Antoine Pitrou added the comment: Note that the description of the POSIX mkdir utility (*) has something a bit more complex to say about the `-p` option. Instead of simply applying the default umask, it computes """(S_IWUSR|S_IXUSR|~filemask)&0777 as the mode argument, where filemask is the fi

[issue20000] SSLContext.get_ca_certs() and self-signed certs

Christian Heimes added the comment: Example: $ openssl s_server -cert Lib/test/ssl_cert.pem -key Lib/test/ssl_key.pem $ ./python >>> import ssl >>> ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv3) >>> ctx.verify_mode = ssl.CERT_REQUIRED >>> ctx.check_hostname = True >>> ctx.load_verify_locations("Lib/t

[issue19996] httplib infinite read on invalid header

Cory Benfield added the comment: An update: in Python 2.7 through 3.3, fixing this should only affect http.client/httplib, because they do most of their header parsing themselves. Fixing this in later versions of Python is more interesting, as http.client got rewritten to use email.parser (whi

[issue19887] Path.resolve() fails on complex symlinks

Antoine Pitrou added the comment: Thanks a lot for the patch! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue19887] Path.resolve() fails on complex symlinks

Roundup Robot added the comment: New changeset 12a52186b4fd by Antoine Pitrou in branch 'default': Issue #19887: Improve the Path.resolve() algorithm to support certain symlink chains. http://hg.python.org/cpython/rev/12a52186b4fd -- nosy: +python-dev __

[issue20000] SSLContext.get_ca_certs() and self-signed certs

New submission from Christian Heimes: The new method SSLContext.get_ca_certs() returns all certificates in the context's trusted X509_STORE. I recently found out that it is possible to put a self-signed certificate into the store and use it successfully with verify_mode CERT_REQUIRED. get_ca_c

[issue19887] Path.resolve() fails on complex symlinks

Antoine Pitrou added the comment: Ah, I remember. Using subtests would make it more annoying to backport to 2.7. -- ___ Python tracker ___ ___

[issue19887] Path.resolve() fails on complex symlinks

Antoine Pitrou added the comment: > why you repeat similar code 3-4 times instead using loops? For no real reason :) I'll try with a loop. -- ___ Python tracker ___

[issue19999] test_monotonic fails on x86 OpenIndiana

New submission from Christian Heimes: I have seen this failure multiple times. http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/7353/steps/test/logs/stdio == FAIL: test_monotonic (test.test_time.TimeTestCa

[issue16733] Solaris ctypes_test failures

Christian Heimes added the comment: The ctypes issue also affects test_uuid. #19045 is a duplicate of this bug, too. == FAIL: test_ints (ctypes.test.test_bitfields.C_Test)

[issue19045] Make on Solaris 11 x64 with OracleStudio12.3 failed

Christian Heimes added the comment: Thanks for the report. This is a duplicate of issue #16733. I'm closing this bug as duplicated. -- nosy: +christian.heimes resolution: -> duplicate stage: -> committed/rejected status: open -> closed versions: +Python 3.3, Python 3.4 __

[issue19995] hex() and %x, oct() and %o do not behave the same

Eric V. Smith added the comment: If you were going to make this change, I'd think you'd have to look for __index__ and then __int__. But I'll admit I haven't thought through all of the ramifications. It would be interesting to see what tests would break. -- ___

[issue7980] time.strptime not thread safe

David Palms added the comment: I am still seeing this in 2.7.5, has a patch been created yet? -- nosy: +dpalms2011 ___ Python tracker ___ _

[issue19995] hex() and %x, oct() and %o do not behave the same

Guido van Rossum added the comment: Also (the tracker email interface swallowed this): > it is possible to want a type that can be used as an index or slice but that > is still not a number I'm sorry, but this requirement is absurd. An index *is* a number. You have to make up your mind. (I kno

[issue19995] hex() and %x, oct() and %o do not behave the same

Guido van Rossum added the comment: Not so fast. Currently, even in Python 3, '%d' % 3.14 returns '3'. "Fixing" this will likely break a huge amount of code. -- versions: +Python 3.5 -Python 3.4 ___ Python tracker

[issue19987] Winsound: test_alias_fallback fails on WS 2008

Christian Heimes added the comment: Awesome! Thanks a lot! :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19995] hex() and %x, oct() and %o do not behave the same

Eric V. Smith added the comment: Yes, I think adding __index__ to d, i, o, u, U, and c is the correct thing to do here. -- ___ Python tracker ___ ___

[issue19987] Winsound: test_alias_fallback fails on WS 2008

Zachary Ware added the comment: The revised test passes on that buildbot on 3.3 and 3.x; the 2.7 build is having permissions issues (and seems to have been for some time). Closing the issue. Thanks for pointing it out and approving the rewrite, Christian! -- resolution: -> fixed sta

[issue19993] Pool.imap doesn't work as advertised

Tim Peters added the comment: Nice to see you, Jurjen! Been a long time :-) I'd like to see changes here too. It's unclear what "a lazy version" is intended to mean, exactly, but I agree the actual behavior is surprising, and that mpool.py is a lot less surprising in several ways. I got bi

[issue19995] hex() and %x, oct() and %o do not behave the same

Serhiy Storchaka added the comment: > > Did I mention __index__ is an unfortunate name for the current trend for > > this method? > Yes, but it's probably too late to change that now. Also, a fully precise > name would be something like: > > __to_int_exact_iff_object_has_integer_nature__ :)

[issue19995] hex() and %x, oct() and %o do not behave the same

STINNER Victor added the comment: > Are we in agreement? Start maybe on writing unit tests :-) IMO all int-like objects should behave the same. I don't see any good reason why hex(value) would succeed whereas "%x" % value fails. Both should succeed (or both should fail). -- __

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Hmmm... Well, much as I hate to say it, it's sounding like the correct solution here is to have %o and %x work when __index__ is available, instead of the other way around. :( .format is not an issue because one must specify one's own if inheriting from objec

[issue19912] ntpath.splitunc() is broken and not tested

Serhiy Storchaka added the comment: Oh, my fault. Thank you Berker. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue19994] re.match does not return or takes long time

Tim Peters added the comment: It will always complete, but may take a very long time - this is one of many ways to write a regexp that can't match requiring time exponential in the length of the string. It's not a bug - it's the way Python's kind of regexp engine works. For detailed explanat

[issue19912] ntpath.splitunc() is broken and not tested

Roundup Robot added the comment: New changeset 4de09cbd3b97 by Serhiy Storchaka in branch '2.7': Removed old implementation of ntpath.splitunc() (issue #19912). http://hg.python.org/cpython/rev/4de09cbd3b97 -- ___ Python tracker

[issue19912] ntpath.splitunc() is broken and not tested

Berker Peksag added the comment: Hi Serhiy, there are commented-out lines in changeset http://hg.python.org/cpython/rev/e4beb183a674. Are they intentionally there? +#if p[1:2] == ':': +#return '', p # Drive letter present +#firstTwo = p[0:2] +#if firstTwo == '//' or firstTwo

[issue19995] hex() and %x, oct() and %o do not behave the same

Stefan Krah added the comment: > Did I mention __index__ is an unfortunate name for the current trend for this > method? Yes, but it's probably too late to change that now. Also, a fully precise name would be something like: __to_int_exact_iff_object_has_integer_nature__ :) > When you say

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Did I mention __index__ is an unfortunate name for the current trend for this method? Stefan Krah commented: -- > memoryview, struct and probably also array.array accept __index__. When you say "accept __index__" do you mean for use as indice

[issue19995] hex() and %x, oct() and %o do not behave the same

Stefan Krah added the comment: Ethan Furman wrote: > The current meaning is unfortunate in that it is possible to want a type that > can be used as an index or slice but that is still not a number, and in fact > won't be used as a number in any scenario _except_ bin(), hex(), and oct(). memoryv

  1   2   >