[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: 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

[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

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

[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

[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(

[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 _

[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? -- __

[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 __

[issue18283] shutil.which() should support bytes

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

[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

[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

[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. >

[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

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" ? -- ___

[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

Serhiy Storchaka added the comment: In addition, PyLong_AsLong() calls __int__, while PyLong_AsUnsignedLong() doesn't call __int__. -- ___ 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

[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 _

[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

[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 __

[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

[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

[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 __

[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

[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"). -- __

[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

[issue13024] cgitb uses stdout encoding

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

[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 __

[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

[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' -

[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

[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

[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.

[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

[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 ___ ___

[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

[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

[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

[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

[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:

[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 ___

[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

[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

[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 ___ ___

[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.

[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

[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. -- __

[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

[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

[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

<    1   2