[issue27515] Dotted name re-import does not rebind after deletion

Guido van Rossum added the comment: Are you sure you realize that "import email.charset" doesn't create a local variable named "email.charset"? It creates a local variable named "email" which happens to have an attribute "charset". The problem with "import pack; print(pack.sub)" being

[issue27514] SystemError when compiling deeply nested for loops

Roundup Robot added the comment: New changeset e6e7c8368c70 by Benjamin Peterson in branch '3.5': make too many nested blocks be a SyntaxError instead of a SystemError (closes #27514) https://hg.python.org/cpython/rev/e6e7c8368c70 New changeset 345ec7455b75 by Benjamin Peterson in branch

[issue1621] Do not assume signed integer overflow behavior

Serhiy Storchaka added the comment: The audioop part LGTM. If this case was found with the help of -ftrapv, I'm for adding this option in a debug build. -- nosy: +serhiy.storchaka ___ Python tracker

[issue27514] SystemError when compiling deeply nested for loops

Serhiy Storchaka added the comment: LGTM. -- stage: needs patch -> commit review ___ Python tracker ___ ___

[issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice

Changes by Serhiy Storchaka : -- nosy: +nadeem.vawda, serhiy.storchaka stage: -> patch review versions: -Python 3.3, Python 3.4 ___ Python tracker

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: I added Issue 13312 as a dependency, there is currently a test for a negative year that relies on overflow handling. Here is a patch where I tried to fix overflow detection for huge set objects. -- Added file:

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Inspired by Issue 27473, I did a quick and dirty scan for obvious places that expect overflow to wrap, and found the following, which I think should be fixed: Modules/_ctypes/_ctypes.c:1388, in PyCArrayType_new() Objects/listobject.c:492, in list_concat()

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

Martin Panter added the comment: This is on my list of things to look at, just that I have been away and am a bit backlogged atm. -- ___ Python tracker

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

Xiang Zhang added the comment: ping -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

Martin Panter added the comment: I can try to add the RuntimeWarning soon. Obviously we want the warning when executing a submodule like “package.module”. It also seems reasonable to warn when executing a top-level module that has already been imported. I presume we want these to go into the

[issue27515] Dotted name re-import does not rebind after deletion

Terry J. Reedy added the comment: I don't understand the statement that having 'import email.charset' set email.charset is an optional side effect. Without the name setting, the module is inaccessible except through sys.modules, which is not obvious to beginners. To me, making a module

[issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice

Benjamin Fogle added the comment: The above code demonstrates two separate issues. One with the decompressor, and one with the compressor. In the compressor example, the first output differs from the rest because it is a file header which is always emitted. That behavior is correct.

[issue27516] Wrong initialization of python path with embeddable distribution

Eryk Sun added the comment: It looks like you haven't copied pyvenv.cfg to your application directory, so Python isn't using the "applocal" configuration. That's why you're seeing the default paths that are relative to the current directory. It's also why PYTHONPATH and PYTHONHOME aren't

[issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail

Terry J. Reedy added the comment: The SO question and that brought the problem to my attention was in June 2015. https://stackoverflow.com/questions/30877112/tkinter-code-using-font-module-cant-run-from-command-line. The message I just unlinked had the wrong url. --

[issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail

Changes by Terry J. Reedy : -- Removed message: http://bugs.python.org/msg259039 ___ Python tracker ___

[issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice

Decorater added the comment: Why you passing decompress without passing compress before decompressing it again? Also I would expect that it would show the same compress result trice in a row on the 1st test. This must definately be a issue. -- nosy: +Decorater

[issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice

New submission from Benjamin Fogle: To reproduce: >>> import lzma >>> c = lzma.LZMACompressor() >>> c.compress(b'') b'\xfd7zXZ\x00\x00\x04\xe6\xd6\xb4F' >>> c.compress(b'') b'' >>> c.compress(b'') Traceback (most recent call last): File "", line 1, in _lzma.LZMAError: Insufficient buffer

[issue27516] Wrong initialization of python path with embeddable distribution

Steve Dower added the comment: Environment variables shouldn't make any different to the embeddable distro - it is designed to ignore them. Have you modified it at all? The path is not as clean as I'd like it to be, but the initialization changes necessary are too significant for 3.5 at this

[issue27516] Wrong initialization of python path with embeddable distribution

Palm Kevin added the comment: BTW: Is there a good reason, the folder-of-the-executable is added to the python-path? I don't see any... -- ___ Python tracker

[issue27516] Wrong initialization of python path with embeddable distribution

Changes by Ned Deily : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker ___

[issue27510] Found some Solution build missconfigurations.

Steve Dower added the comment: I just checked and the pcbuild.sln you posted is identical to what's currently checked in. Batch build settings are not part of the checkin, so if you want to use that rather than using the build scripts we provide (see PCBuild/build.bat) then you'll need to

[issue27516] Wrong initialization of python path with embeddable distribution

New submission from Palm Kevin: The way the python path is initialized with the embeddable python distribution makes no sense for me. If no environment variable PYTHONPATH is set, then the path is initialized like this: [python352]\python35.zip;.\DLLs;.\lib;[folder_of_executable] -->

[issue27514] SystemError when compiling deeply nested for loops

Ammar Askar added the comment: Amended patch with the comment fixed to refer to just the issue numbers according to advice from bitdancer. -- Added file: http://bugs.python.org/file43726/nested_blocks.diff2 ___ Python tracker

[issue27514] SystemError when compiling deeply nested for loops

Ammar Askar added the comment: This patch changes it to a SyntaxError instead of a SystemError. -- keywords: +patch nosy: +ammar2 Added file: http://bugs.python.org/file43725/nested_blocks.diff ___ Python tracker

[issue27515] Dotted name re-import does not rebind after deletion

R. David Murray added the comment: So, Guido answered your actual question, and I was confused :( The important point is that email.charset still exists in sys.modules, so import doesn't reload it, and as Guido says module load is the thing that creates the attribute mapping. --

[issue27515] Dotted name re-import does not rebind after deletion

Guido van Rossum added the comment: > On the second import, import finds email in sys.modules Actually, it only takes the shortcut because it also finds email.charset in sys.modules. -- ___ Python tracker

[issue27515] Dotted name re-import does not rebind after deletion

R. David Murray added the comment: Heh, actually strike that last sentence. Doing a del doesn't remove the module from sys.modules, so the version of the email module with charset deleted is still there, and doing del email and import email or import email.charset will not change the fact

[issue27515] Dotted name re-import does not rebind after deletion

R. David Murray added the comment: Or, to put it another way, you deleted the charset attribute from the email module. On the second import, import finds email in sys.modules, so it doesn't reimport it, so charset doesn't get recreated. So, the difference is you didn't do 'del email'.

[issue27515] Dotted name re-import does not rebind after deletion

Guido van Rossum added the comment: I don't think this is a bug. You're paraphrasing step 2 incorrectly. The local name-binding behavior just creates a local named "email" -- it doesn't concern itself with ensuring that the email package has an attribute "charset". That attribute is set as a

[issue25958] Implicit ABCs have no means of "anti-registration"

Ivan Levkivskyi added the comment: What holds back this issue now? It looks like Andrew did a great job. When I was making a patch for #25987 following Andrew's ideas, I was surprised how many different idioms has been used for __subclasshook__. I was going to open an issue on this, when I

[issue27515] Dotted name re-import does not rebind after deletion

New submission from Terry J. Reedy: https://docs.python.org/3/reference/simple_stmts.html#the-import-statement says that import , where can optionally be a dotted name referring to a module within a package, does two things: 1. Find a module object corresponding to , creating it if

[issue27501] Add typing.py class describing a PEP 3118 buffer object

Raymond Hettinger added the comment: Looking at the patch, I'm thinking that this endeavor isn't at all worthwhile. We don't need an ABC for everything especially if there in no pure python API involved. I recommend closing this one until there is a proven need and a clear path forward.

[issue27510] Found some Solution build missconfigurations.

Decorater added the comment: was targeting* -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue27510] Found some Solution build missconfigurations.

Decorater added the comment: Some parts rargenting win32 was having the solution set of 64 bit making x86 with x64 setting mixups. Basically it was doing both 32 and 64 bit assembling at the same time which of course would make it fail. -- ___

[issue25393] 'resource' module documentation error

Alakshendra Yadav added the comment: It does seem that the mentioned line belongs under RLIMIT_STACK instead of RLIMIT_FSIZE. I am submitting a patch. -- keywords: +patch nosy: +Alakshendra Yadav Added file: http://bugs.python.org/file43724/resource.patch

[issue18966] Threads within multiprocessing Process terminate early

Tim Peters added the comment: About: "The notion of categorically refusing to let a process end perhaps overreaches in certain situations." threading.py addressed that all along: if the programmer _wants_ the process to exit without waiting for a particular threading.Thread, that's fine,

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: Tested on FreeBSD 10.3. getsockname() on a IPPROTO_SCTP protocol socket returns errno = FileNoFoundError. We could just comment out that test I guess. My theory is that on FreeBSD, getsockname() on an SCTP socket fails if it is not bound. Indeed, adding

[issue24254] Make class definition namespace ordered by default

Eric Snow added the comment: FTR: PEP 520 "Preserving Class Attribute Definition Order" (https://www.python.org/dev/peps/pep-0520/) -- ___ Python tracker

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Xiang Zhang added the comment: Thanks Brett, also others. Restore the moving around. -- Added file: http://bugs.python.org/file43723/fix_fspath_crash_v3.patch ___ Python tracker

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: Updated patch, v5. Disable fdtype() function on Windows. Fix documentation nits as suggested by review of v4. -- Added file: http://bugs.python.org/file43722/fromfd2_v5.txt ___ Python tracker

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Brett Cannon added the comment: The reordering of the tests is unnecessary. Because you both changed the code *and* moved a test you have to be very careful to notice the change, otherwise it just looks like you cut-and-pasted the code to another location. Had you left the test method where

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

Brett Cannon added the comment: +1 from me -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: I just tested on Windows. fdtype() fails with: OSError: [WinError 10022] An invalid argument was supplied The getsockname() call fails with WSAGetLastError() == 10022. getsockname() is used to find the address family. Perhaps there is some other way to

[issue27513] email.utils.getaddresses does not handle Header objects

R. David Murray added the comment: This appears to be something that was overlooked when btyes support was added in 3.2. getaddresses should indeed be able to handle a Header object if handed one. -- title: email.utils.getaddresses raises exception from erroneous message get_all

[issue20842] pkgutil docs should reference glossary terms not PEP 302

Jaysinh shukla added the comment: Adding updated patch after merging Issue 26896. Requesting to review. Thanks! -- Added file: http://bugs.python.org/file43721/issue20842_v2.diff ___ Python tracker

[issue23722] During metaclass.__init__, super() of the constructed class does not work

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___

[issue14977] mailcap does not respect precedence in the presence of wildcards

R. David Murray added the comment: I think a doc update is probably worthwhile, but I haven't looked at the docs so I'm not sure. I'll try to give this a complete review this weekend, though I'm a bit busy so it may not happen. -- ___ Python

[issue18966] Threads within multiprocessing Process terminate early

R. David Murray added the comment: As far as muliprocessing's "mentality" goes, it aims to provide the *same* API as Threading, so it is logical that it should preserve threading's behavior with respect to child threads in a process, rather than violating threading's model. Anything else is

[issue18966] Threads within multiprocessing Process terminate early

R. David Murray added the comment: Note, however, that fixing this will be a backward compatibility issue, since there are doubtless programs relying on this behavior, probably mostly unintentionally. -- ___ Python tracker

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Xiang Zhang added the comment: I have to explain for myself. First, I know tests *are* important. This is not the first time uploading patches here. I don't want to add tests for this case is because such codes: call something and test for failure appears all the places in the code base. This

[issue25144] 3.5 Win install fails with "TARGETDIR"

Futur Fusionneur added the comment: For me the custom installer worked by combining the two solutions above: 1. open an elevated command prompt 2. run the installer by specifying the TargetDir -- nosy: +Futur Fusionneur ___ Python tracker

[issue18966] Threads within multiprocessing Process terminate early

Eryk Sun added the comment: > all atexit handlers, for example, would be called multiple times. Davin is (I think) proposing a multiprocessing atexit facility, which can be used to ensure threading._shutdown is called. But could Python's regular atexit handling be reset in the child, allowing

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Ethan Furman added the comment: > I think such omissions are hard to predict and you won't know where is > the omission until you encounter it. So if you don't know, how do you > know what to put in the tests? True. > And if it is encountered and fixed, such errors should not happen again.

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Ethan Furman added the comment: > I ... reorganize the existing tests a little. Please don't. Moving tests around makes it harder for reviewers to see what actually changed. Rewriting tests to do the same thing as before also takes more work from reviewers as we have to verify the new code

[issue18966] Threads within multiprocessing Process terminate early

Davin Potts added the comment: Tim: Totally agreed about threading.Thread not being a POSIX thread. It was not my intent to suggest that they were equivalent -- apologies for the confusion. Instead I was attempting to describe a mentality of processes and their common behavior across

[issue18858] dummy_threading lacks threading.get_ident() equivalent

Berker Peksag added the comment: > This patch adds a test but does not fix the bug. I forgot to explain what the first patch does. The specific problem reported by OP has already been fixed in default branch (but not in 3.5) so issue18858.diff was added a test to make sure that threading and

[issue13312] test_time fails: strftime('%Y', y) for negative year

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue27510] Found some Solution build missconfigurations.

Steve Dower added the comment: I believe changes to the batch build dialog are local to your machine, so there won't be any changes to the solution file. A regular build should include all packages. Can you explain what didn't work and why you needed to fix it? --

[issue27501] Add typing.py class describing a PEP 3118 buffer object

Daniel Moisset added the comment: As a description of the idea I'm attaching a rough patch with an implementation. Some tests fail because of the following: 1) I didn't find a good place to register the Buffer ABC for mmap.mmap, and array.mmap; the modeules themselves are C extensions (and

[issue27392] Add a server_side keyword parameter to create_connection

Jim Fulton added the comment: Here's a daft doc update. -- keywords: +patch Added file: http://bugs.python.org/file43718/connect_accepted_socket-doc.patch ___ Python tracker

[issue27514] SystemError when compiling deeply nested for loops

Nick Coghlan added the comment: +1 for Serhiy's recommendation. It's OK for the compiler to say "Don't do that", but the correct error is SyntaxError, even when it's a limitation later in the code generation pipeline (rather than failing to comply with the language grammar) --

[issue27514] SystemError when compiling deeply nested for loops

Serhiy Storchaka added the comment: There is a static limit for the number of statically nested blocks. Getting rid of this limit looks not easy. But SystemError is not an exception that should be raised. SystemError is for errors that can't be occurred in normal case. It should only be

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Xiang Zhang added the comment: The test requests for the whole fspath are reasonable. I just don't want to add tests for these two lines. 1) and 3) have already been tested. I add 2) and reorganize the existing tests a little. -- Added file:

[issue25733] Code and IDLE should catch all compile errors.

ppperry added the comment: >SystemError is serious bug. Please open separate issue for this. Done. I created issue27514 -- ___ Python tracker ___

[issue27514] SystemError when compiling deeply nested for loops

New submission from ppperry: The following code: for a in range(26): for b in range(26): for c in range(26): for d in range(26): for e in range(26): for f in range(26): for g in range(26): for h in range(26): for i in range(26): for j in

[issue27497] csv module: Add return value to DictWriter.writeheader

STINNER Victor added the comment: I'm now ok to add the return, but only in Python 3.6. It would be a minor new "feature". -- ___ Python tracker ___

[issue27510] Found some Solution build missconfigurations.

Emanuel Barry added the comment: Please submit a patch file (see https://docs.python.org/devguide/patch.html ). -- nosy: +ebarry stage: -> needs patch ___ Python tracker

[issue26579] Support pickling slots in subclasses of common classes

Serhiy Storchaka added the comment: An alternative way is to expose a default state as object.__getstate__(). It is more efficient since it is implemented in C. Following patch implements this approach. -- Added file: http://bugs.python.org/file43716/object_getstate.patch

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Serhiy Storchaka added the comment: I think should be tests for following cases: 1) __fspath__ doesn't exist; 2) __fspath__ is not callable or calling __fspath__() raises an exception; 3) the result of __fspath__() is not valid (wrong type). -- ___

[issue27513] email.utils.getaddresses raises exception from erroneous message get_all input

Hans-Peter Jansen added the comment: message.get cannot decode the header correctly, and returns a Header instance instead, which makes email.utils.getaddresses stumble upon... A much better behavior for getaddresses in this case would be returning the perfectly valid address, and ignoring

[issue27507] bytearray.extend lacks overflow check when increasing buffer

Xiang Zhang added the comment: Thanks for the analysis Antti. I don't think if (len == PY_SSIZE_T_MAX) can be moved inside the *other* if. Their handlings are different. if (len == PY_SSIZE_T_MAX) is True, it should exit immediately. But in the *other* if, you can still have a try to allocate

[issue27513] email.utils.getaddresses raises exception from erroneous message get_all input

New submission from Hans-Peter Jansen: An unfortunate combination of get_all and getaddresses results in a Traceback: Traceback (most recent call last): File "misc/decode_from_header.py", line 17, in print('From: %s' % email.utils.getaddresses(val)) File

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Xiang Zhang added the comment: I think such omissions are hard to predict and you won't know where is the omission until you encounter it. So if you don't know, how do you know what to put in the tests? And if it is encountered and fixed, such errors should not happen again. --

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Antti Haapala added the comment: I believe tests is that they should *especially* be in place for any previously found "careless omissions". If it has been done before, who is to say that it wouldn't happen again? -- nosy: +ztane ___ Python tracker

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Decorater added the comment: nevermind the above traceback from it is a issue with the code that makes it try to copy the redist file from the v14 C++ runtime. -- ___ Python tracker

[issue27507] bytearray.extend lacks overflow check when increasing buffer

Antti Haapala added the comment: if (len == PY_SSIZE_T_MAX) is necessary for the case that the iterable is already PY_SSIZE_T_MAX items. However it could be moved inside the *other* if because if (len == PY_SSIZE_T_MAX) should also fail the overflow check. However, I believe it is theoretical

[issue27507] bytearray.extend lacks overflow check when increasing buffer

Xiang Zhang added the comment: So would you like to merge it like this or Martin's alternative way? But honestly speaking I don't get Martin's point, "without trying to allocate Py_SSIZE_T_MAX first", where is this place? -- ___ Python tracker

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Decorater added the comment: This does also happen in make_zip too as it does not known about the current changes. https://bpaste.net/show/ff826604a5f0 -- nosy: +Decorater ___ Python tracker

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Xiang Zhang added the comment: Ahh, adding tests is easy. But this seems to be just a careless omission, so maybe tests is not a must. -- ___ Python tracker

[issue27507] bytearray.extend lacks overflow check when increasing buffer

Changes by Decorater : -- nosy: +Decorater ___ Python tracker ___ ___ Python-bugs-list

[issue27507] bytearray.extend lacks overflow check when increasing buffer

Serhiy Storchaka added the comment: Totally agreed with Martin. -- ___ Python tracker ___ ___

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Serhiy Storchaka added the comment: Could you add tests? -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue27497] csv module: Add return value to DictWriter.writeheader

Logan added the comment: @berker.peksag: Good catch, thank you. In my code base I'm using a slightly different implementation which does use an iterator, so I didn't even catch that the default django example was incorrect. @skip.montanaro: That is exactly the one-liner I'm currently using.

[issue27497] csv module: Add return value to DictWriter.writeheader

Skip Montanaro added the comment: I agree writeheader() should have returned the value of writerow(), but have no opinion on the more esoteric stuff you're discussing. I think you could argue that adding the "return" would be a bug fix. Personally, I long ago got in the habit of using the

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

Xiang Zhang added the comment: BTW, the code is also listed in PEP519. So maybe that also needs to be fixed. -- ___ Python tracker ___

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

New submission from Xiang Zhang: When any exception is raised inside __fspath__, operations involving it like os.fspath, open are certain to crash. >>> import os >>> class Test: ... def __fspath__(self): ... raise RuntimeError ... >>> os.fspath(Test()) Segmentation fault (core

[issue27511] Add PathLike objects support to BZ2File

Changes by Xiang Zhang : -- components: +Library (Lib) type: -> enhancement versions: +Python 3.6 ___ Python tracker ___

[issue27511] Add PathLike objects support to BZ2File

New submission from Xiang Zhang: Attach a patch to add PathLike objects support to BZ2File. -- files: add_PathLike_objects_support_to_BZ2File.patch keywords: patch messages: 270385 nosy: brett.cannon, ethan.furman, xiang.zhang priority: normal severity: normal status: open title: Add

[issue27509] Some tests breaks PGO build on Windows

Decorater added the comment: Have you tried the 3.6 branch maybe it was fixed there. -- ___ Python tracker ___

[issue27509] Some tests breaks PGO build on Windows

Charles G. added the comment: Tried with Visual Studio Community 2015 Update 3 with same result. -- ___ Python tracker ___

[issue18966] Threads within multiprocessing Process terminate early

Charles-François Natali added the comment: One reason for not calling sys.exit() is because on Linux, the default implementation uses fork(), hence the address space in the chilren is a clone of the parent: so all atexit handlers, for example, would be called multiple times. There's also the

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

Nick Coghlan added the comment: +1 for the more verbose version, since that will tend to nudge folks towards .__init__ as the likely culprit (and that does seem to be the most likely way for this particular double-import scenario to arise. Brett, does that resolution sound reasonable to you,

[issue27510] Found some Solution build missconfigurations.

New submission from Decorater: I went in and looked in the batch build list to find some missconfigurations So, I went in and selected the right ones that I can see currently. -- components: Build, Windows files: pcbuild.sln messages: 270380 nosy: Decorater, paul.moore, steve.dower,

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

Wolfgang Maier added the comment: A warning like this sounds good to me though I'd prefer it to be slightly more verbose, like: "RuntimeWarning: '' found in sys.modules after import of package '', but prior to execution of '' as '__main__'; this may result in unpredictable behaviour" or it

[issue27509] Some tests breaks PGO build on Windows

Charles G. added the comment: The compiler itself supports PGO in the Community Edition. I'm not sure about the IDE (not using it). Since I compiled python using the batch file (with msbuild) so it is not limited by the features of the IDE. -- ___

[issue27509] Some tests breaks PGO build on Windows

Charles G. added the comment: Community Edition. PGO is available in the Community Edition since at least VS 2012. -- ___ Python tracker ___

[issue27509] Some tests breaks PGO build on Windows

Decorater added the comment: What Edition of Visual Studio are you using? I am using Update 3 of 2015 Community and PGO is only (as far as I am aware of) in the Ultimate Edition of Visual Studio. -- nosy: +Decorater ___ Python tracker

[issue18966] Threads within multiprocessing Process terminate early

Changes by Antoine Pitrou : -- stage: -> needs patch type: behavior -> enhancement versions: -Python 2.7, Python 3.5 ___ Python tracker

[issue18966] Threads within multiprocessing Process terminate early

Antoine Pitrou added the comment: I agree with Tim. Regardless of what OS threads do, Python tries to enforce predictable semantics of its own. There's no reason (apart from historical baggage) to not join Python threads (and only Python threads, of course, not other OS threads) at the

[issue27509] Some tests breaks PGO build on Windows

New submission from Charles G.: Environment: Python 3.5.2 Visual Studio 2015 Update 2 Windows 7 amd64 I tried to build python with pgo (build.bat --pgo) but found that no python35!1.pgc or python!1.pgc was created. Then I run the tests one by one while checking the existence of

  1   2   >