[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Stefan Behnel added the comment: >> Yield-from iterates, and a coroutine is not supposed to be iterable, only >> awaitable (at least, that's what all error messages tell me when I try it). >> So why should "yield from" work on them? What if foo() was not an Iterable >> but a Coroutine? Should

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Stefan Behnel added the comment: BTW, given that "iter(iterator)" works and returns the iterator, should we also allow "await x.__await__()" to work? I guess that would be tricky to achieve given that __await__() is only required to return any kind of arbitrary Iterator, and Iterators cannot b

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Terry J. Reedy added the comment: For Idle, the addition could be made in current versions. Idle compiles user code in the idle process and ships it to the user process for execution. In particular, idlelib.run.Executive.runcode, line 351, is exec(code, self.locals) Am I to pre

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Stefan Behnel added the comment: > Can't your Coroutine object return itself from its __await__, and implement > __next__? Like genobject in CPython simply returns self from its __iter__. That was my first try, sure, and it mostly worked. It has a drawback, though: it's an incomplete implement

[issue24311] urllib2.urlopen() through proxy fails when HTTPS URL contains port number

Changes by Ned Deily : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue24311] urllib2.urlopen() through proxy fails when HTTPS URL contains port number

New submission from Atzm WATANABE: urllib2.urlopen() through proxy causes ssl.CertificateError when HTTPS URL contains port number. Sample code: $ https_proxy='http://proxy.example.com:8080/' python -c 'import urllib2; urllib2.urlopen("https://www.python.org:443/";)' Traceback (most recent ca

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: Okay, that sounds reasonable to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue24309] string.Template should be using str.format and/or deprecated

Dmitry Kazakov added the comment: Ugh, I guess I was too quick to propose deprecation, sorry :( But is it a strict "No" to the proposed use of str.format as well? This would be a (relatively) minor but useful change which, again, won't break anything. I can write the patch. -- __

[issue24310] Idle documentation -- what to do if you do not see an underscore.

Laura Creighton added the comment: Thank you. I don't think that this problem is unique to Retina Macbooks -- I had it on an ancient Toshiba laptop I was using about 15 years ago. It's not something that I have thought of very much recently. :) -- _

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Nick Coghlan added the comment: Given that tp_call is just "ternaryfunc", my guess would be "because when the iterator protocol was added, someone went with function-pointer-type-per-slot rather than function-pointer-type-per-call-signature". We *are* a little inconsistent here (e.g. "reprfunc

[issue24310] Idle documentation -- what to do if you do not see an underscore.

Ned Deily added the comment: Yes, that's probably a good thing to do in any case. I can add it to the Tcl/Tk info page for OS X as at least an interim measure: https://www.python.org/download/mac/tcltk/ -- assignee: docs@python -> ned.deily components: +IDLE versions: -Python 3.2, Py

[issue24310] Idle documentation -- what to do if you do not see an underscore.

Laura Creighton added the comment: I don't have one, alas. It was a question sent to webmaster. I just happened to know that reconfiguring your font size fixes the 'no underscore' problem, so it occured to me that mentioning this in the idle documentation might save some grief. -- ___

[issue24310] Idle documentation -- what to do if you do not see an underscore.

Ned Deily added the comment: That may be a problem better fixed in Tk itself. I don't have a Retina display handy. Assuming you have a current ActiveTcl 8.5 (8.5.18) installed, could you try some of the Tk text widget demos in /usr/local/bin/wish8.5 and see if the problem shows up there, too

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Yury Selivanov added the comment: > For your first question, I agree getawaitablefunc / aiternextfunc / > getaiterfunc should all be dropped and replaced with the existing "unaryfunc". I have no problem with that. But why do we have iternextfunc & getiterfunc (no "a" prefix)? -- __

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Nick Coghlan added the comment: Thanks for highlighting these Stefan - you guessed correctly that I'd missed them on the review. For your first question, I agree getawaitablefunc / aiternextfunc / getaiterfunc should all be dropped and replaced with the existing "unaryfunc". For your second q

[issue24310] Idle documentation -- what to do if you do not see an underscore.

New submission from Laura Creighton: On some operating systems, for instance a Macbook Pro with Retina, the bottoms of hanging letters such as 'g' or 'y', as well as underscorces, cannot be seen in IDLE. The fix is to go to Options -> Configure IDLE, and change the size of the default font to

[issue24309] string.Template should be using str.format and/or deprecated

Serhiy Storchaka added the comment: I'm strongly -1 for deprecating string.Template. It provides simple, widely used syntax, and is used in a lot of third-party code. I don't think that it needs to be extended. However I have an idea about implementing general string composing engine than cou

[issue24306] Backport py.exe to 3.4

Steve Dower added the comment: I didn't mention it initially, but the harm it can do is overriding newer versions. The 3.5 and later installers have proper versioning built in, but I don't think that's possible with the 3.4 installer as well (due to MSI limitations, not any deficiency of the p

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Yury Selivanov added the comment: > > It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an > > object with an __await__ > method. > > "coroutine", yes. But "Coroutine"? Shouldn't the Coroutine ABC then require > "__await__" to be implemented? Maybe even by inheriting from Awai

[issue24309] string.Template should be using str.format and/or deprecated

Raymond Hettinger added the comment: > I came across this piece of code in Lib/string.py:146: That may be artifact from the days of ASCII strings and may or may not have analog with the bytes data type. > But I'm not exactly sure string.Template should be in > Python 3 at all. It still has v

[issue24309] string.Template should be using str.format and/or deprecated

New submission from Dmitry Kazakov: I came across this piece of code in Lib/string.py:146: # We use this idiom instead of str() because the latter will # fail if val is a Unicode containing non-ASCII characters. return '%s' % (mapping[named],) This seems vestigial. I think it'd be a

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Stefan Behnel added the comment: > It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object > with an __await__ method. "coroutine", yes. But "Coroutine"? Shouldn't the Coroutine ABC then require "__await__" to be implemented? Maybe even by inheriting from Awaitable? > Jus

[issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules

Nick Coghlan added the comment: Issue 24305 covers either making this a public API for general use, or else just making module level deprecation warnings skip the import machinery automatically. I also wonder whether Eric's _boostrap_external changes might have broken any of the frame hiding

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nick Coghlan added the comment: I've made this depend on issue 23810, rather than duplicating it. That way, issue 23810 can cover fixing the stdlib deprecation warnings, while this can cover making it a public API. -- dependencies: +Suboptimal stacklevel of deprecation warnings for for

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Stefan Behnel added the comment: Another question: is it ok if Cython implements and uses the "tp_as_async" slot in all Py3.x versions (3.2+)? It shouldn't hurt, but it would speed up async/await in Cython at least under Py3.x. Only Py2.6/7 would then have to resort to calling "__await__()" et

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Yury Selivanov added the comment: > 2) Awaitable.register(Coroutine) > I think this is incorrect. A Coroutine is not Awaitable unless it also > implements "__await__". How else should it be awaited? It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object with an __await__

[issue4753] Faster opcode dispatch on gcc

Ned Deily added the comment: @Vamsi, could you please open a new issue and attach your patch there so it can be properly tracked for 2.7? This issue has been closed for five years and the code has been out in the field for a long time in Python 3. Thanks! -- nosy: +ned.deily ___

[issue24175] Sporadic test_utime() failures on FreeBSD

koobs added the comment: See also: Issue 16287 (Solaris) Issue 15745 (Related to FreeBSD/ZFS, has patch) 3.4 and 3.x are still failing -- title: Test failure in test_utime on FreeBSD -> Sporadic test_utime() failures on FreeBSD ___ Python tracker

[issue23275] Can assign [] = (), but not () = []

Changes by Stefan Behnel : -- nosy: +scoder ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue24306] Backport py.exe to 3.4

Mark Lawrence added the comment: Can it actually do any harm? It certainly appears to remove the potential for a lot of bug reports from a lot of frustrated users, myself included. -- nosy: +BreamoreBoy ___ Python tracker

[issue24259] tar.extractall() does not recognize unexpected EOF

Ethan Furman added the comment: I took an existing tar file and chopped it in half with `head -c`. I was able to extract half the files, but I didn't check the viability of the last file as I was looking for tar or python error feedback. -- ___ Pyt

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Stefan Behnel added the comment: I added a couple of review comments to patch 6, but since no-one has responded so far, I guess they simply haven't been noticed. So I'll just repeat them here. 1) getawaitablefunc / aiternextfunc / getaiterfunc Is there a reason why these need to have their spe

[issue24308] Test failure: test_with_pip (test.test_venv.EnsurePipTest in 3.x

koobs added the comment: My mistake, revision 1ca30423b0c99c9599d5d4654323eeeae4a03804 or revision 29b95625a07cc5bb22e260c983500ed9efed67bf -- ___ Python tracker ___

[issue18032] Optimization for set/frozenset.issubset()

Raymond Hettinger added the comment: > Personally I don't sure that this optimization is worth to apply. I concur. Closing as "not worth it" :-) -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue24308] Test failure: test_with_pip (test.test_venv.EnsurePipTest in 3.x

New submission from koobs: test_with_pip fails since revision 0d0989359bbbff9aa502158e362eb298e1a8ba7c with the following output: == FAIL: test_with_pip (test.test_venv.EnsurePipTest) ---

[issue24259] tar.extractall() does not recognize unexpected EOF

Martin Panter added the comment: I guess it depends on the particular tar file and where it gets truncated. Just now I tested with a tar file created from Python’s Tools directory: $ tar c Tools/ > good.tar $ ls -gG good.tar -rw-r--r-- 1 17397760 May 28 02:43 good.tar $ head -c 13 good.tar

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Berker Peksag added the comment: This looks like a duplicate of issue 23810 (there is a patch for stdlib usages, but it probably can be changed to a more general solution). -- nosy: +berker.peksag ___ Python tracker

[issue18032] Optimization for set/frozenset.issubset()

Serhiy Storchaka added the comment: Personally I don't sure that this optimization is worth to apply. Its cost is high and optimized case is not common. This is rather an experiment, how large can be maximal effect of the optimization. -- ___ Python

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nick Coghlan added the comment: The difference between the two used to be clearer: prior to Python 2.7, PendingDeprecationWarning was hidden by default (and thus mainly only visible to folks testing with -Wall), while DeprecationWarning was visible by default. We blurred the line between the t

[issue24307] pip error on windows whose current user name contains non-ascii characters

Changes by Ned Deily : -- nosy: +Marcus.Smith, dstufft, ncoghlan, paul.moore ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue24307] pip error on windows whose current user name contains non-ascii characters

New submission from tanbro-liu: On windows8.1 x64, current user name contains non-ascii characters. When executing ``pip`` in the command-line, such an error happens:: C:\Users\雪彦>pip Traceback (most recent call last): File "C:\Python27\lib\runpy.py", line 162, in _run

[issue24298] inspect.signature includes bound argument for wrappers around bound methods

Changes by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue24298] inspect.signature includes bound argument for wrappers around bound methods

Roundup Robot added the comment: New changeset 42819b176d63 by Yury Selivanov in branch '3.4': Issue 24298: Fix signature() to properly unwrap wrappers around bound methods https://hg.python.org/cpython/rev/42819b176d63 New changeset d7e392c5c53a by Yury Selivanov in branch '3.5': Issue 24298: F

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

Changes by Mike Gilbert : -- nosy: +floppymaster ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: *cough* You know, there's more to life than Python-X.Y.tar.gz :-). Not that I know how PendingDeprecationWarning is used in the wild. I've been thinking maybe we (numpy) should start using it for stuff that we want to discourage people from using (we know it

[issue24298] inspect.signature includes bound argument for wrappers around bound methods

Yury Selivanov added the comment: > I'm OK with the patch as is, but I'm definitely concerned about the > maintainability of inspect.signature in general. I agree, _signature_from_callable is getting quite complex. The good news is that we have a very good test coverage for signatures. As fo

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nick Coghlan added the comment: +1 for showing DeprecationWarning by default (as these features may be going away in the next X.Y release of Python) -0 for showing PendingDeprecationWarning by default (as these won't be going away until X.Y+1 at the earliest) -- nosy: +ncoghlan _

[issue24259] tar.extractall() does not recognize unexpected EOF

Ethan Furman added the comment: I ran the OP's code in 2.7, 3.3, 3.4, and 3.5, as well as using ubuntu's gnu tar 1.27.1: gnu tar did not report any errors. Python (all tested versions) did not report any errors (with the errorlevel parameter missing, set to 1, and set to 2). --

[issue24298] inspect.signature includes bound argument for wrappers around bound methods

Nick Coghlan added the comment: I'm OK with the patch as is, but I'm definitely concerned about the maintainability of inspect.signature in general. I'm trying to decide if a block comment covering the order of calling protocols that we check, and where we potentially recurse, would be a help

[issue24259] tar.extractall() does not recognize unexpected EOF

Ethan Furman added the comment: Actually, the OP was using 2.7.6. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue24259] tar.extractall() does not recognize unexpected EOF

Ethan Furman added the comment: On the SO question [1] the OP stated that he tried errorlevel of both 1 and 2 with no effect... however, he was using Python2.6. Martin, can you run that same test with 2.6 to verify that errorlevel did not work there, but does now? [1] http://stackoverflow.co

[issue24259] tar.extractall() does not recognize unexpected EOF

Martin Panter added the comment: Actually, looking closer at the module, perhaps you just need to set the errorlevel=1 option: >>> with tarfile.open("truncated.tar", errorlevel=1) as tar:... >>> tar.extractall("test-dir") ... Traceback (most recent call last): File "", line 2, in Fil

[issue24298] inspect.signature includes bound argument for wrappers around bound methods

Yury Selivanov added the comment: > That's also a little more future-proof, in case any further checks happen to > be inserted ahead of the check for __wrapped__. Well, we unwrap until we see a "__signature__" attribute (or we can't unwrap anymore). And right after unwrapping we try to return

[issue24259] tar.extractall() does not recognize unexpected EOF

Martin Panter added the comment: I might be able to make a patch, but what should the patch do exactly? * Raise an exception as soon as something wrong is found * Defer exceptions until close() is called, to allow partial data recovery * Add some sort of defects API that you can optionally inspe

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nick Coghlan added the comment: Somewhat related issues are issue 16217 (traceback noise when running under python -m) and issue 23773 (traceback noise when running under custom import hooks) For 3.4 and 3.5, we may want to consider a brute force solution where the warnings module just straig

[issue4753] Faster opcode dispatch on gcc

Robert Collins added the comment: FWIW I'm interested and willing to poke at this if more testers/reviewers are needed. -- nosy: +rbcollins ___ Python tracker ___ ___

[issue24301] gzip module failing to decompress valid compressed file

Martin Panter added the comment: I suspect Eric’s file has non-zero, non-gzip garbage bytes appended to the end of it. Assuming I am right, here is way to reproduce that scenario: >>> from gzip import GzipFile >>> from io import BytesIO >>> file = BytesIO() >>> with GzipFile(fileobj=file, mode=

[issue24298] inspect.signature includes bound argument for wrappers around bound methods

Nick Coghlan added the comment: It occurs to me we're also bypassing the check that the unwrapped obj is a callable, so it probably makes sense to just recurse unconditionally after unwrapping the object, rather than only recursing for methods. That's also a little more future-proof, in case a

[issue4753] Faster opcode dispatch on gcc

Srinivas Vamsi Parasa added the comment: Hi All, This is Vamsi from Server Scripting Languages Optimization team at Intel Corporation. Would like to submit a request to enable the computed goto based dispatch in Python 2.x (which happens to be enabled by default in Python 3 given its perform

[issue23275] Can assign [] = (), but not () = []

Nick Coghlan added the comment: +1 for Martin's suggestion of removing the inconsistency the other way (i.e. allowing "() = iterable" to mean the same thing as "[] = iterable", effectively asserting that an iterable is empty) I also agree with Raymond that it doesn't need to be mentioned in th

[issue24306] Backport py.exe to 3.4

New submission from Steve Dower: For 3.5 32-bit installs we register in a different key to avoid collisions with 64-bit installs, but now the 3.4 launcher can't find us. If you have installed 3.4 for all users (likely) and then install 3.5 just-for-me (also likely), then you'll continue to get

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Ned Deily : -- nosy: +brett.cannon, eric.snow, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

New submission from Nathaniel Smith: (Noticed while fixing the IPython equivalent of issue 24294) The obvious way to deprecate a module is to issue a DeprecationWarning inside the main body of the module, i.e. # thirdpartymodule.py import warnings warnings.warn("{} is deprecated".format(__name

[issue24293] Windows installer unreadable with std/custom themes

Mike Miller added the comment: Thanks. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.o

[issue24290] c_uint32 bitfields break structures

Rony Batista added the comment: Well, looks like the issue is with 64 bit mode then. For the first 5 cases the right answer is 69.95930480957031, and for the last 2 its -69.95930480957031. The results for the 32 bit mode are all correct. -- ___ Pyth

[issue1243678] httplib gzip support

Changes by Martin Panter : -- superseder: Performance for small reads and fix seek problem -> transparent gzip compression in urllib ___ Python tracker ___ ___

[issue24304] Documentation broken link to license

Ned Deily added the comment: Thanks for the report! -- nosy: +ned.deily resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 2.7, Python 3.4, Python 3.5 ___ Python tracker

[issue24304] Documentation broken link to license

Roundup Robot added the comment: New changeset d4080f3c0894 by Ned Deily in branch '2.7': Issue 24304: Fix broken license link in FAQ. https://hg.python.org/cpython/rev/d4080f3c0894 New changeset 8631d61f6577 by Ned Deily in branch '3.4': Issue 24304: Fix broken license link in FAQ. https://hg.p

[issue24298] inspect.signature includes bound argument for wrappers around bound methods

Changes by Yury Selivanov : Added file: http://bugs.python.org/file39526/signature2.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue23359] Speed-up set_lookkey()

Raymond Hettinger added the comment: [Reply to pitrou that I didn't seem to be able to make on Rietveld] This part of the code is the most time sensitive and warrants expansion much more than other proposals (set copying, subset tests, etc). I long aspired to split the lookup and insertion lo

[issue8232] webbrowser.open incomplete on Windows

Brandon Milam added the comment: I kept the changes to the WindowsDefault.open() method and used and extended eryksun's code to build the browser list using the registry. Also I added support for a few more browsers. Some of the browsers I could not find ways to differentiate between opening a

[issue24295] Backport of #17086 causes regression in setup.py

Moritz Sichert added the comment: I wouldn't call it reverting since it already was like this before and only got changed by accident in another backport. -- ___ Python tracker

[issue24304] Documentation broken link to license

New submission from Leonardo Tada: In this page https://docs.python.org/3.4/faq/general.html#are-there-copyright-restrictions-on-the-use-of-python the link for "the PSF license page" is broken. -- assignee: docs@python components: Documentation messages: 244217 nosy: Leonardo Tada, docs

[issue24298] inspect.signature includes bound argument for wrappers around bound methods

Yury Selivanov added the comment: Thanks for reporting this, Petr! Nick, could you please take a look at the patch? -- assignee: -> yselivanov keywords: +patch stage: -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file39524/signature.patch __

[issue23275] Can assign [] = (), but not () = []

flying sheep added the comment: > isn't it logical? > > [] is a mutable data structure > while () is a immutable data structure but you don’t assign to data structures, but to names. you *modify* data structures. and in the square bracket assignment syntax you don’t modify the list created by

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

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

[issue24301] gzip module failing to decompress valid compressed file

Ned Deily added the comment: Can you add a public copy of a file that fails this way? There are several open issues with gzip, like Issue1159051, that might cover this but it's hard to know for sure without a test case. -- nosy: +ned.deily type: crash ->

[issue24288] Include/opcode.h is modified during building

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ __

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

Changes by Mike Frysinger : -- nosy: +vapier ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

Changes by Ned Deily : -- nosy: +davin -devin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue24299] 2.7.10 test__locale.py change breaks on Solaris

Serhiy Storchaka added the comment: This is not the Right Answer because on Linux the thousands-separator for the fr_FR locale is a space. Perhaps better solution would be to specify the UTF-8 encoding for fr_FR locale. -- assignee: -> serhiy.storchaka nosy: +lemburg, loewis, serhiy.s

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

Changes by Ned Deily : -- nosy: +devin, sbt stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

New submission from Paul Hobbs: Using pid namespacing it is possible to have multiple processes with the same pid. "semlock_new" creates a semaphore file with the template "/dev/shm/mp{pid}-{counter}". This can conflict if the same semaphore file already exists due to another Python process

[issue23359] Speed-up set_lookkey()

Serhiy Storchaka added the comment: Why you have added entry->hash == 0? -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue24295] Backport of #17086 causes regression in setup.py

Matthias Klose added the comment: I'll look at this in June. I don't think that reverting is the right choice here. -- ___ Python tracker ___ ___

[issue24295] Backport of #17086 causes regression in setup.py

Changes by Ned Deily : -- nosy: +doko priority: normal -> high ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue23275] Can assign [] = (), but not () = []

Raymond Hettinger added the comment: Berker's patch looks good. It has several virtues: * the error message is reasonable and clear * it makes the language more consistent * it doesn't break any existing code. * it makes the AST a little simpler and faster by removing a special case The patch

[issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows

Ned Deily added the comment: So you did, sorry! Another, perhaps evan more reliable option is (requires enabling the purge extension in hg): hg purge --all -- ___ Python tracker _

[issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows

R. David Murray added the comment: Right, that's why I said make *dist*clean. That does delete any existing Setup file(s), which is what you want when working with a checkout for Python development purposes. -- ___ Python tracker

[issue23359] Speed-up set_lookkey()

Changes by Raymond Hettinger : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue23359] Speed-up set_lookkey()

Roundup Robot added the comment: New changeset cd1e1715becd by Raymond Hettinger in branch 'default': Issue #23359: Specialize set_lookkey intoa lookup function and an insert function. https://hg.python.org/cpython/rev/cd1e1715becd -- ___ Python trac

[issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows

Ned Deily added the comment: > Note that when I run into build problems after an update, I generally > run 'make distclean' and then redo the configure/make. Yes, but I believe that won't help with changed Modules/Setup* files and, because it is needed in the core interpreter executable, timemo

[issue24302] Dead Code of Handler check in function faulthandler_fatal_error()

Changes by R. David Murray : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows

R. David Murray added the comment: Note that when I run into build problems after an update, I generally run 'make distclean' and then redo the configure/make. This generally cleans up any problems like this (and I don't find that I need to do it very often.) -- _

[issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows

Yury Selivanov added the comment: > Check the times and contents on all of your Modules/Setup* files. Try > deleting Setup.local for one. I just made a clean checkout and that helped. I have no idea what caused this. Thank you, Ned, for troubleshooting this with me! -- priority: cr

[issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows

Majeed Arni added the comment: Though %f is a valid format from Python's doc https://docs.python.org/2/library/datetime.html, the fix just ignores it on Windows? can we atleast get milliseconds on Windows and Micro on Linux? %f Microsecond as a decimal number, zero-padded on the left.

[issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows

Ned Deily added the comment: Check the times and contents on all of your Modules/Setup* files. Try deleting Setup.local for one. -- ___ Python tracker ___ _

  1   2   >