[issue29371] Typo in doctest documentation

Raymond Hettinger added the comment: This mostly looks correct. I would change "bitwise-OR‘ed" to "bitwise ORed". That latter form without the hyphen or apostrophe matches what is used in library/winsound.rst. Once that change is made (in two places), go ahead an apply the patch. --

[issue29459] `__contains__` and `get` methods for match objects?

New submission from irdb: __getitem__ was added to match objects as a resolution of issue24454. Wouldn't it be nice to also have `__contains__` and `get` methods for match objects? Is it even feasible to implement them in neat way? They should work similar to dictionaries, i.e: ``` match = re

[issue29449] clear() should return prior state in threading.Event

Raymond Hettinger added the comment: > A return value from clear will indicate to a thread if it > won the race to clear the event. Why would we care who won the race to clear? I would think that the important thing is that the event is cleared, not who did it. -- nosy: +rhettinger pr

[issue29460] Speed up _PyArg_NoKeywords() and like

New submission from Serhiy Storchaka: Proposed patch makes _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and _PyArg_NoPositional() macros. This eliminates the overhead of the cross-module function call in common case. This idea was previously discussed in issue26822 and raised again in issue29

[issue26822] itemgetter/attrgetter/methodcaller objects ignore keyword arguments

Serhiy Storchaka added the comment: Seems I missed to attach a patch. Opened issue29460 for this tweak. -- ___ Python tracker ___ ___

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

Serhiy Storchaka added the comment: This already was discussed in issue26822. Issue29460 makes _PyArg_NoStackKeywords() cheaper. -- ___ Python tracker ___ __

[issue29459] `__contains__` and `get` methods for match objects?

Serhiy Storchaka added the comment: I predicted that that change will open a can of worms. The match object is not a dictionary. I don't see a need in new methods. The get() method you propose looks virtually the same as the group() method. "'a' in match" is virtually the same as "match.get('a

[issue29028] Use-After-Free in PyString_FromStringAndSize() of stringobject.c

Serhiy Storchaka added the comment: I wanted first to finish issue27867 (expose new API as public). But this is not needed for this issue. -- dependencies: -various issues due to misuse of PySlice_GetIndicesEx resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue29459] `__contains__` and `get` methods for match objects?

Raymond Hettinger added the comment: +1 for m.get(key[, default]) -1 for __contains__ The get() makes logical sense and it is perfectly reasonable to want a default value for a missing group. The contains idea makes less sense and is problematic on several fronts. "'a' in match" only works i

[issue29460] Speed up _PyArg_NoKeywords() and like

Raymond Hettinger added the comment: +1 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue29460] Speed up _PyArg_NoKeywords() and like

Roundup Robot added the comment: New changeset 82d1c8d15e18 by Serhiy Storchaka in branch 'default': Issue #29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and https://hg.python.org/cpython/rev/82d1c8d15e18 -- nosy: +python-dev ___ Python tracker

[issue29460] Speed up _PyArg_NoKeywords() and like

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue29460] Speed up _PyArg_NoKeywords() and like

STINNER Victor added the comment: Oh right, I recall that I proposed it. Thanks for this change :-) The next question might it: would it be worth it to try using unlikely() macro on (kwargs == NULL) test in the macro? ;-) I'm talking about GCC/Clang __builtin_expect: #define unlikely(x) _

[issue29455] Mention coverage.py in trace module documentation

Marco Buttu added the comment: I added a "seealso" at the end of the page. -- keywords: +patch nosy: +marco.buttu Added file: http://bugs.python.org/file46538/issue29455.patch ___ Python tracker ___

[issue29449] clear() should return prior state in threading.Event

Jyotirmoy Bhattacharya added the comment: > > A return value from clear will indicate to a thread if it > > won the race to clear the event. > > Why would we care who won the race to clear? I would think that the > important thing is that the event is cleared, not who did it. > Here's the scenar

[issue29449] clear() should return prior state in threading.Event

Serhiy Storchaka added the comment: > A return value from clear will indicate to a thread if it won the race to > clear the event. I think other synchronization primitives should be used for this. I'm not sure that other implementations of Event (e.g. multiprocessing.Event) can efficiently re

[issue29460] Speed up _PyArg_NoKeywords() and like

Roundup Robot added the comment: New changeset f5ef851ff6b26529382747cfea4674158c7c1ebc by Serhiy Storchaka in branch 'master': Issue #29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and https://github.com/python/cpython/commit/f5ef851ff6b26529382747cfea4674158c7c1ebc -- ___

[issue29460] Speed up _PyArg_NoKeywords() and like

Serhiy Storchaka added the comment: > The next question might it: would it be worth it to try using unlikely() > macro on (kwargs == NULL) test in the macro? ;-) Perhaps this may help in some critical tight loops (in implementations of dict, string operations or long integer arithmetic), but I

[issue29461] Experiment usage of likely/unlikely in CPython core

New submission from STINNER Victor: Attached patch is an attempt to use the GCC/Clang __builtin_expect() attribute to provide the compiler with branch prediction information, it adds _Py_likely() and _Py_unlikely() macros, similar to the Linux kernel macros. I always wanted to experiment this

[issue29461] Experiment usage of likely/unlikely in CPython core

STINNER Victor added the comment: Copy of msg287111 (issue #29460), Serhiy Storchaka (serhiy.storchaka): > The next question might it: would it be worth it to try using unlikely() > macro on (kwargs == NULL) test in the macro? ;-) Perhaps this may help in some critical tight loops (in implement

[issue29460] Speed up _PyArg_NoKeywords() and like

STINNER Victor added the comment: I created the issue #29461: "Experiment usage of likely/unlikely in CPython core". -- ___ Python tracker ___ __

[issue29461] Experiment usage of likely/unlikely in CPython core

Changes by Christian Heimes : -- nosy: +christian.heimes ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue29461] Experiment usage of likely/unlikely in CPython core

STINNER Victor added the comment: http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html Using __builtin_expect() in a very long loop 10^9 iteratos (1,000,000,000) makes the loop 15% faster (2.67 sec => 2.28 sec), *but* using PGO avoids the need of using __builtin_expect() exp

[issue24459] Mention PYTHONFAULTHANDLER in the man page

Berker Peksag added the comment: Thanks for the patch and sorry for my late response. I did some tweaks and am planning to commit the tweaked version of your patch this week. -- Added file: http://bugs.python.org/file46540/issue24459_cleanup.diff ___

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

STINNER Victor added the comment: > Over this looks good. Just one other minor tweak (one that has served me > well elsewhere) would be to bypass the cross-module function call with a > cheap (near zero cost) register variable test: (...) This has just been optimized by Serhiy, change 82d1c8d

[issue29461] Experiment usage of likely/unlikely in CPython core

STINNER Victor added the comment: Benchmarks with Python compiled by gcc -O3 (without PGO). haypo@smithers$ ./python -m perf timeit 'len("abc")' --duplicate=1000 --compare-to=../default-ref/python Median +- std dev: [ref] 40.4 ns +- 0.8 ns -> [likely] 40.8 ns +- 2.1 ns: 1.01x slower (+1%) hay

[issue24459] Mention PYTHONFAULTHANDLER in the man page

Changes by Berker Peksag : Added file: http://bugs.python.org/file46541/issue24459_cleanup_2.diff ___ Python tracker ___ ___ Python-bugs-list

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

New submission from Alessandro Vesely: Comments are allowed almost everywhere in an email message, and should be eliminated before attributing any meaning to a field. In the words of RFC5322, any CRLF that appears in FWS is semantically "invisible". In particular, some note that comments can

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

INADA Naoki added the comment: I've tried to update ast_opt.c[t] without changing AST. But I can't find clear way to solve "foo" + "bar" docstring problem. This patch adds only docstring to AST. -- Added file: http://bugs.python.org/file46542/ast-docstring.patch ___

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

STINNER Victor added the comment: Naoki: Can you please open a new issue for your ast-docstring.patch change? I like it, but this issue became too big, and I'm not sure that everyone in the nosy list is interested by this specific change. -- ___ Pyt

[issue29362] regrtest: don't fail immediately if a child does crash

Roundup Robot added the comment: New changeset 4446613000a3 by Victor Stinner in branch 'default': regrtest: don't fail immediately if a child does crash https://hg.python.org/cpython/rev/4446613000a3 -- nosy: +python-dev ___ Python tracker

[issue29362] regrtest: don't fail immediately if a child does crash

Roundup Robot added the comment: New changeset 99e4e687145a76ac28055a651ee31470496c3ac7 by Victor Stinner in branch 'master': regrtest: don't fail immediately if a child does crash https://github.com/python/cpython/commit/99e4e687145a76ac28055a651ee31470496c3ac7 -- __

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

Changes by Alex Gaynor : -- nosy: -alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue29362] regrtest: don't fail immediately if a child does crash

STINNER Victor added the comment: I fixed regrtest in Python 3.7. Maybe I will backport the fix later to other branches, but I prefer to limit regrtest changes in stable branches. -- resolution: -> fixed stage: -> resolved status: open -> closed __

[issue26901] Argument Clinic test is broken

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

[issue29300] Modify the _struct module to use FASTCALL and Argument Clinic

STINNER Victor added the comment: @Serhiy: Can we please now close this issue? Or is there still something to do? -- ___ Python tracker ___ __

[issue27659] Prohibit implicit C function declarations

Roundup Robot added the comment: New changeset ca2f024ce7cb by Victor Stinner in branch 'default': Prohibit implicit C function declarations https://hg.python.org/cpython/rev/ca2f024ce7cb -- nosy: +python-dev ___ Python tracker

[issue27659] Prohibit implicit C function declarations

STINNER Victor added the comment: Martin Panter: "If there is an obscure platform where we don’t include the right header file for a function, changing the warning into an error would cause the build to fail." In my experience, calling a function which was not declared is very likely to cause

[issue27659] Prohibit implicit C function declarations

Chi Hsuan Yen added the comment: > If yes, can we close the issue? Yes and thanks! As a side note, on Android it prevents broken grp.cpython-37m.so, too. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue29457] strftime('%x') does not use my locale

R. David Murray added the comment: Yes, it is the default behavior, because the default locale, as for most (almost all?) programming languages (not just Python), is the C locale, until you change it. The reason for this is to get consistent behavior no matter what the locale is set to, unles

[issue27659] Prohibit implicit C function declarations

STINNER Victor added the comment: Oh by the way, if someone sees a build error because of a missing function declaration, please report a new issue. -- ___ Python tracker ___ __

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

Stefan Krah added the comment: If the API can still change (msg287083), I think I'll wait with this until shortly before 3.7 beta. -- ___ Python tracker ___

[issue27659] Prohibit implicit C function declarations

Roundup Robot added the comment: New changeset 9a26d20d2baa27407501b13435d733dcc26f3d53 by Victor Stinner in branch 'master': Prohibit implicit C function declarations https://github.com/python/cpython/commit/9a26d20d2baa27407501b13435d733dcc26f3d53 -- ___

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

STINNER Victor added the comment: > If the API can still change (msg287083), I think I'll wait with this until > shortly before 3.7 beta. I do not understand why Serhiy keeps repeating that the API is going to change, I have no such plan. IMHO the FASTCALL API is now very well defined: (PyObje

[issue23980] Documentation for format units starting with 'e' is inconsistent

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

R. David Murray added the comment: My reading of rfc 2231 is that CFWS is not allowed in that position. Can you explain your interpretation with specific cites to the RFC? Also please provide an example of specific behavior of the email package that you think is incorrect. An email processor

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

R. David Murray added the comment: Oh, and the answer to you "why" is that the email package is only dealing with content semantically in address lists. Everywhere else it is up to the library using program to interpret the structured headers. In 2.7 the email package provides you the tools

[issue29463] Change docstring to attribute from first statement.

New submission from INADA Naoki: spin off of #11549. http://bugs.python.org/issue11549#msg130955 > b) Docstring is now an attribute of Module, FunctionDef and ClassDef, > > rather than a first statement. Docstring is a special syntactic > construction, it's not an executable code, so it makes

[issue27051] Create PIP gui

Nick Coghlan added the comment: Regarding pip installability, the intended beneficiaries of that are: * folks *collaborating* on the GUI, since it means it can be installed into virtual environments, tested across multiple versions with tox, etc * developers that would like a pip GUI, and alrea

[issue29453] Remove reference to undefined dictionary ordering in Tutorial

Jim Fasarakis-Hilliard added the comment: > But maybe it is worth to mention that the output corresponds to the order of > passed keyword arguments Should I add this note? It looks fine to me as is but I'm not the experienced one here :-) -- ___ P

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

Raymond Hettinger added the comment: Yes, go ahead and apply. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue26355] Emit major version based canonical URLs for docs

Nick Coghlan added the comment: Thanks Matthias! Regarding 2v3, the layout differences aren't a problem, since the canonical URLs are separate (/2/* vs /3/*). That's one of the benefits I actually hope for with this change - due to PEP 430, deep links still go to the Python 2 documentation by

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

Changes by STINNER Victor : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

Roundup Robot added the comment: New changeset 1c048539200c by Victor Stinner in branch 'default': Optimize deque index, insert and rotate() methods https://hg.python.org/cpython/rev/1c048539200c -- nosy: +python-dev ___ Python tracker

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

STINNER Victor added the comment: Raymond: "Yes, go ahead and apply." Great, done. Thanks for the reviews Serhiy and Raymond. As I wrote, you can consider to use Argument Clinic later, but there is no urgency for that ;-) I close the issue. -- resolution: -> fixed stage: -> resolved

[issue29464] Specialize FASTCALL for functions with positional-only parameters

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

New submission from Serhiy Storchaka: Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes bare METH_FASTCALL be used for functions with positional-only parameters. This eliminates small cost that these functions pay for handling empty keywords: calling _PyStack_Unpack

[issue29461] Experiment usage of likely/unlikely in CPython core

Raymond Hettinger added the comment: I had read that likely/unlikely were hard to use well and often not worth the trouble. IIRC, they are used extensively in the Linux kernel but people were finding zero measurable effect when enabling or disabling the constructs. -- nosy: +rhetting

[issue29461] Experiment usage of likely/unlikely in CPython core

Christian Heimes added the comment: I would expect that PGO/LGO builds give better improvements with less coding bloat. Did you compare a PGO likely/unlikely build against a standard PGO build? -- ___ Python tracker

[issue29464] Specialize FASTCALL for functions with positional-only parameters

STINNER Victor added the comment: > Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes > bare METH_FASTCALL be used for functions with positional-only parameters. While I tried to keep everything related to FASTCALL private, it seems like Cython uses some FASTCALL fe

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

Roundup Robot added the comment: New changeset 55949f988dc1b943796d9852cc4d588c58cc4255 by Victor Stinner in branch 'master': Optimize deque index, insert and rotate() methods https://github.com/python/cpython/commit/55949f988dc1b943796d9852cc4d588c58cc4255 -- ___

[issue29461] Experiment usage of likely/unlikely in CPython core

Serhiy Storchaka added the comment: I also always wanted to experiment this change. But I was afraid that providing such macros can encourage of overusing it. I don't want to wrap any test for NULL or -1 with these macros. If we expect some benefit from using these macros, I would play with th

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

STINNER Victor added the comment: Oh ok, it seems like Serhiy wants to change METH_FASTCALL. I didn't know :-) He just opened the issue #29464: "Specialize FASTCALL for functions with positional-only parameters". Interesting idea. -- ___ Python trac

[issue29464] Specialize FASTCALL for functions with positional-only parameters

Serhiy Storchaka added the comment: We can avoid breaking backward compatibility and introduce new call method METH_FASTCALL_NO_KEYWORDS. But combining existing flags looks better to me. FASTCALL is not a part of stable ABI. I still didn't do any benchmarking or stack usage measurements.

[issue29464] Specialize FASTCALL for functions with positional-only parameters

STINNER Victor added the comment: > I still didn't do any benchmarking or stack usage measurements. I'm running benchmarks on the speed-python server. -- ___ Python tracker ___

[issue29464] Specialize FASTCALL for functions with positional-only parameters

Stefan Krah added the comment: Adding Stefan Behnel, perhaps Cython doesn't need backwards compatibility. -- nosy: +scoder, skrah ___ Python tracker ___ _

[issue29465] Add _PyObject_FastCall() to reduce stack consumption

New submission from STINNER Victor: While testing issue #29464 patch, I failed to see a major enhancement on the stack usage of fast calls without keyword arguments. The problem is that functions like _PyObject_FastCallKeywords() and _PyObject_FastCallDict() still have to pass a NULL argument

[issue29465] Add _PyObject_FastCall() to reduce stack consumption

STINNER Victor added the comment: meth_fastcall_stacksize.patch: Patch adding _testcapi.meth_fastcall_stacksize() to measure the stack usage to call a METH_FASTCALL function. -- Added file: http://bugs.python.org/file46546/meth_fastcall_stacksize.patch

[issue29464] Specialize FASTCALL for functions with positional-only parameters

STINNER Victor added the comment: > We can avoid breaking backward compatibility and introduce new call method > METH_FASTCALL_NO_KEYWORDS. But combining existing flags looks better to me. > FASTCALL is not a part of stable ABI. If we decide that having two FASTCALL calling convention, I prefe

[issue29464] Specialize FASTCALL for functions with positional-only parameters

STINNER Victor added the comment: I measured the stack consumption, it's not better. But I created the issue #29465 "Add _PyObject_FastCall() to reduce stack consumption" which would allow to reduce the stack consumption with this patch. -- ___ Pyth

[issue29400] Add instruction level tracing via sys.settrace

George King added the comment: Attached is a new patch, which does not settrace/gettrace and instead offers new settraceinst/gettraceinst per Victor's recommendation. I did not implement the proposed behavior of raising an exception if the old APIs are used when the inst_tracing flag is set. H

[issue29400] Add instruction level tracing via sys.settrace

STINNER Victor added the comment: > I did it this way because I would like to consider adding a third mode, which > would only trigger tracing for interesting control-flow events, namely steps > for which the previous instruction was a branch. Hum, let's use https://en.wikipedia.org/wiki/Basic

[issue29455] Mention coverage.py in trace module documentation

Brett Cannon added the comment: Thanks for the patch, Marco! Typically we put the mention at the top to give the 3rd-party library a better chance of being noticed (see the urllib.request docs to see how requests is mentioned). -- assignee: docs@python -> brett.cannon

[issue29441] Update examples to use async and await keywords in asyncio-task.rst

Guido van Rossum added the comment: LGTM. Thanks! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue29455] Mention coverage.py in trace module documentation

Marco Buttu added the comment: Thank you Brett, here is another patch. I added the seealso directive right after the introduction of the trace module, in the same way as urllib.request does for requests. -- Added file: http://bugs.python.org/file46548/issue29455_2nd.patch

[issue24905] Allow incremental I/O to blobs in sqlite3

Aviv Palivoda added the comment: Uploading patch after fixes from berker CR. The `blob_open` API can can have the following options: 1. The table, column and row must be mandatory parameters. 2. The read/write permissions can have the following options: a. No default (mandatory parameter).

[issue29466] pickle does not serialize Exception __cause__ field

New submission from Mark Diekhans: python3 pickle does not serialize the __cause__ field, as shown by the attached demo program. -- components: Library (Lib) files: cause_pickle.py messages: 287163 nosy: diekhans priority: normal severity: normal status: open title: pickle does not seri

[issue29425] File-altering aspects of pathlib should return new pathlib objects

Brett Cannon added the comment: The idea in general seems reasonable. Anyone else have an opinion? -- nosy: +brett.cannon ___ Python tracker ___ _

[issue29400] Add instruction level tracing via sys.settrace

George King added the comment: I'm not sure exactly, but the way I see it (for code coverage), we want to trace transitions between basic blocks. So I would define it as: each entry into a BB is traced, with a tuple of (previous_offset, current_offset). This way when a function call starts, we

[issue29466] pickle does not serialize Exception __cause__ field

Changes by Mark Diekhans : -- nosy: +alexandre.vassalotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

Alessandro Vesely added the comment: Neither I found CFWS in rfc2231. In addition, rfc 2045 (Introduction) says that Content-Disposition —where filename is defined— cannot include comments. However, Content-Type can include RFC 822 comments, so the filename should be de-commented in case it

[issue29439] _decimal on Android requires linking with libm

Xavier de Gaye added the comment: With the following module named dlsym.py, the command 'python dlsym.py log10' produces the same successful output on linux and on Android API 21 (when _decimal is not explicitly linked with libm.so, i.e.without changeset b60b46ad8751): 'The symbol "log10" is

[issue29439] _decimal on Android requires linking with libm

Xavier de Gaye added the comment: > Perhaps test_decimal should fail for CPython if _decimal can't be imported. This is not a problem specific to _decimal, the same problem exists for third-party extension modules, for example pyephem (https://github.com/brandon-rhodes/pyephem/issues/114) and e

[issue29232] Quiet Install

Earl Maier added the comment: I have since rebuilt the machine that I was doing my testing on, so I am unable grab log files from the installs. I have not been able to reproduce the issue since the rebuild of the machine. On a good note: Everything is working as it should. I appreciate you l

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

R. David Murray added the comment: Your thought is correct: python2 no longer gets enhancements. So improved comment handling can only be added to python3, assuming anyone is interested in doing it :) -- ___ Python tracker

[issue29371] Typo in doctest documentation

Mariatta Wijaya added the comment: Thanks, Raymond. I have an updated patch there the hypen and apostrophe are removed. -- versions: -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file46552/issue29371v2.patch ___ Python tracker

[issue28686] py.exe ignored PATH when using python3 shebang

Riccardo Polignieri added the comment: > I'm inclined to say YAGNI, and we simply leave "/usr/bin/env python3" > undefined. I can't say I'm really happy with this answer. Fact is, 1) you almost always have to work from within a virtual env these days, 2) you really want to have meaningful sh

[issue29467] Allow return mismatch to be caught by function

New submission from Ted Shaneyfelt: def f(): try: return 0 except: return 1,2 x = f() # x is 0 x,y = f() # proposal: x,y should be 1,2 instead of uncaught TypeError It would make sense to be able to catch [TypeError: 'int' object is not iterable] and return the correct number of values

[issue28686] py.exe ignored PATH when using python3 shebang

Paul Moore added the comment: > 2) you really want to have meaningful shebangs (ie, version-specific) in your > scripts because, well, 2017 and the world is still split between py2 and py3, This is the one I think is overspecifying. I don't see a really *good* reason for not just saying /usr/

[issue28686] py.exe ignored PATH when using python3 shebang

Steve Dower added the comment: > If Python on Windows changed to ship python3.exe and python37.exe alongside > python.exe, then it might be worth revisiting this discussion Agreed, though if we started including versioned executables wouldn't that resolve this issue naturally? (As in, we'd sea

[issue29464] Specialize FASTCALL for functions with positional-only parameters

STINNER Victor added the comment: Hum, benchmark results don't seem good. There is probably a performance bug somewhere. I should investigate further to analyze these results. M aybe combined with the issue #29465, results will be better. haypo@speed-python$ python3 -m perf compare_to ~/bench

[issue28164] _PyIO_get_console_type fails for various paths

Roundup Robot added the comment: New changeset 4463e311f5bd by Steve Dower in branch '3.6': Issue #28164: Improves test on Windows 7 https://hg.python.org/cpython/rev/4463e311f5bd New changeset 8132bcc1522d by Steve Dower in branch 'default': Issue #28164: Improves test on Windows 7 https://hg.p

[issue28164] _PyIO_get_console_type fails for various paths

Steve Dower added the comment: That test looks good for me, and I verified it on both Win7 and Win10. (Hopefully we don't have any Win8.1 edge cases in here...) -- status: open -> closed ___ Python tracker ___

[issue28164] _PyIO_get_console_type fails for various paths

Roundup Robot added the comment: New changeset c6c32889c9d80ffd599a57fd0d4c4a88deece29b by Steve Dower in branch 'master': Issue #28164: Improves test on Windows 7 https://github.com/python/cpython/commit/c6c32889c9d80ffd599a57fd0d4c4a88deece29b New changeset dc5c4bc90770d6a5875666434cf797c77e

[issue28164] _PyIO_get_console_type fails for various paths

Roundup Robot added the comment: New changeset c6c32889c9d80ffd599a57fd0d4c4a88deece29b by Steve Dower in branch '3.6': Issue #28164: Improves test on Windows 7 https://github.com/python/cpython/commit/c6c32889c9d80ffd599a57fd0d4c4a88deece29b -- __

[issue28686] py.exe ignored PATH when using python3 shebang

Paul Moore added the comment: I agree, I don't particularly want versioned executables. I'm not sure I see much point to even having versioned launchers - "py -2" and "py -3" seem fine to me if needed. The only use cases I can see are: 1. Use the Python executable that's first on PATH: "py" 2

[issue29467] Allow return mismatch to be caught by function

Eric V. Smith added the comment: Thanks for the suggestion. However, I don't think it's possible or desirable for python to implement this. There are two problems: 1) the internals of python would have to be drastically changed to support this, and 2) you'd need different syntax to support thi

[issue29465] Add _PyObject_FastCall() to reduce stack consumption

STINNER Victor added the comment: pyobject_fastcall-2.patch: More complete changes. Sorry, the patch also contains unrelated refactoring! It's a more advanced implementation which tries to reduce the depth of the C backtrace. For example, _PyObject_FastCall() is now inlined manually in _PyObje

[issue29465] Add _PyObject_FastCall() to reduce stack consumption

STINNER Victor added the comment: Oh, I forgot to rebase my local git branch: patch version 2 contains unrelated changes. Please see instead the path version 3 which was rebased. -- Added file: http://bugs.python.org/file46554/pyobject_fastcall-3.patch _

[issue29466] pickle does not serialize Exception __cause__ field

Changes by Xiang Zhang : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

  1   2   >