[issue25902] Fixed various refcount issues in ElementTree iteration

[Roundup Robot]

Roundup Robot added the comment:

New changeset 00b6a13cfd70 by Serhiy Storchaka in branch '3.5':
Issue #25902: Fixed various refcount issues in ElementTree iteration.
https://hg.python.org/cpython/rev/00b6a13cfd70

New changeset e09cb2af3092 by Serhiy Storchaka in branch 'default':
Issue #25902: Fixed various refcount issues in ElementTree iteration.
https://hg.python.org/cpython/rev/e09cb2af3092

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25911] Regression: os.walk now using os.scandir() breaks bytes filenames on windows

[Eryk Sun]

Eryk Sun added the comment:

The ANSI API is problematic because it returns a best-fit encoding to the 
system codepage. For example:

>>> os.listdir('.')
['ƠƨưƸǀLjǐǘǠǨǰǸ']

>>> os.listdir(b'.')
[b'O?u?|?iu?Kj?']

To somewhat work around this problem, listdir and scandir could return the 
cAlternateFilename of the WIN32_FIND_DATA struct if present. This is the 
classic 8.3 short name that Microsoft file systems create for MS-DOS 
compatibility. For NTFS it can be disabled in the registry, or per volume, but 
I assume whoever does that knows what to expect. 

Also, since Python wouldn't need the short name for a wide-character path, 
there's no point in asking for it. (For NTFS it's a separate entry in the MFT. 
If it exists, which is known ahead of time, finding the entry requires a second 
lookup.) In this case it's better to call FindFirstFileExW and request only 
FindExInfoBasic. Generally the difference is inconsequential, but in a 
contrived example with 1 similarly-named files from "ĀāĂă" to 
"ĀāĂă" and short names from "~1" to "~1", skipping the short name 
lookup shaved about 10% off the total time. For this test, I replaced the 
FindFirstFileW call in posix_scandir with the following call:

iterator->handle = FindFirstFileExW(path_strW,
FindExInfoBasic,
&iterator->file_data,
FindExSearchNameMatch,
NULL, 0);

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4709] Mingw-w64 and python on windows x64

[Henry Gomersall]

Henry Gomersall added the comment:

@carlkl right, but it's not really a seamless experience. I think my question 
is: What needs to still be done in order that a user with a fresh Python 
install in Windows (and no compiler installed) can do "pip install 
an_extension_that_needs_compiling" and it _just works_?

Is someone with a better understanding of the issues able to comment on this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25148] Windows registry PythonCore key changed inconsistent with other releases

[Mark Hammond]

Mark Hammond added the comment:

It appears bdist_wininst wasn't updated for this so installed created by 
distutils don't work in 32bit versions - is there a different bug open for 
that? (Or I'm doing something wrong, but the installer fails and a quick scan 
of the source doesn't seem to handle it)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25918] AssertionError in lib2to3 on 2.7.11 Windows

[Marc Schlaich]

New submission from Marc Schlaich:

This simple test case results in a lib2to3 crash with an AssertionError in 
2.7.11


source = '''

class Test(object):

tests = []


'''

from lib2to3.refactor import RefactoringTool


def main():
tool = RefactoringTool([])
tool.refactor_string(source, '')


Exception:

Traceback (most recent call last):
  File "test.py", line 21, in 
main()
  File "test.py", line 16, in main
tool.refactor_string(source, '')
  File "c:\Python27\Lib\lib2to3\refactor.py", line 380, in refactor_string
name, err.__class__.__name__, err)
  File "c:\Python27\Lib\lib2to3\refactor.py", line 377, in refactor_string
tree = self.driver.parse_string(data)
  File "c:\Python27\Lib\lib2to3\pgen2\driver.py", line 106, in parse_string
return self.parse_tokens(tokens, debug)
  File "c:\Python27\Lib\lib2to3\pgen2\driver.py", line 71, in parse_tokens
if p.addtoken(type, value, (prefix, start)):
  File "c:\Python27\Lib\lib2to3\pgen2\parse.py", line 127, in addtoken
assert t < 256
AssertionError

Pretty weird: A manually built Python 2.7.11 with VS 2008 doesn't show this 
issue.

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 256790
nosy: schlamar
priority: normal
severity: normal
status: open
title: AssertionError in lib2to3 on 2.7.11 Windows
type: crash
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25918] AssertionError in lib2to3 on 2.7.11 Windows

[Marc Schlaich]

Marc Schlaich added the comment:

The issue is in Grammar2.7.11.final.0.pickle or 
PatternGrammar2.7.11.final.0.pickle. I have copied these files to my manually 
built Python and getting the same issue in this case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25918] AssertionError in lib2to3 on 2.7.11 Windows

[Marc Schlaich]

Marc Schlaich added the comment:

I'm attaching those bad files.

--
Added file: http://bugs.python.org/file41378/PatternGrammar2.7.11.final.0.pickle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25918] AssertionError in lib2to3 on 2.7.11 Windows

[Marc Schlaich]

Changes by Marc Schlaich :


Added file: http://bugs.python.org/file41379/Grammar2.7.11.final.0.pickle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25918] AssertionError in lib2to3 on 2.7.11 Windows

[Marc Schlaich]

Marc Schlaich added the comment:

After deleting them, they are getting recreated and everything works now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25902] Fixed various refcount issues in ElementTree iteration

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Martin.

Actually this patch is for 3.5 only. In 3.6 the code will be rewrote 
(issue25873).

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25873] Faster ElementTree iterating

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5a5d5268afd5 by Serhiy Storchaka in branch 'default':
Issue #25873: Optimized iterating ElementTree.
https://hg.python.org/cpython/rev/5a5d5268afd5

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25869] Faster ElementTree deepcopying

[Roundup Robot]

Roundup Robot added the comment:

New changeset 090c3e3a648d by Serhiy Storchaka in branch 'default':
Issue #25869: Optimized deepcopying ElementTree; it is now 20 times faster.
https://hg.python.org/cpython/rev/090c3e3a648d

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23670] Modifications to support iOS as a cross-compilation target

[Nick Coghlan]

Nick Coghlan added the comment:

Mac OS X 10.5 was the last version to support PowerPC architectures, and 
according to https://en.wikipedia.org/wiki/Mac_OS_X_Leopard#Release_history, 
the final version of that was 10.5.8, released in August 2009.

While we don't have a section in https://www.python.org/dev/peps/pep-0011/ 
spelling out our support policy for Mac OS X the way we do for Windows, Ned is 
still making dual architecture binaries available for 2.7.x and 3.5.x as seen 
at https://www.python.org/downloads/release/python-2711/ and 
https://www.python.org/downloads/release/python-351/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25148] Windows registry PythonCore key changed inconsistent with other releases

[Steve Dower]

Steve Dower added the comment:

That's a possibility. I won't have a chance to check for a few days, but it 
should get another bug if it's wrong.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4709] Mingw-w64 and python on windows x64

[Steve Dower]

Steve Dower added the comment:

> What needs to still be done in order that a user with a fresh Python install 
> in Windows (and no compiler installed) can do "pip install 
> an_extension_that_needs_compiling" and it _just works_?

The package developer takes the time to build a wheel on Windows (presumably 
they are already testing on Windows...?) and publishes it. Problem solved.

Most of our efforts are (or should be) aimed at making it easier for the 
developers to do this, rather than trying to make a seamless build toolchain 
for the end user.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25900] unittest ignores the first ctrl-c when it shouldn't

[Michael Foord]

Michael Foord added the comment:

Suggested behaviour sounds good, patch looks sensible. Is it possible to add a 
test too?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4709] Mingw-w64 and python on windows x64

[Henry Gomersall]

Henry Gomersall added the comment:

@Steve Great, so what needs to be done so that I as a package developer can do 
`pip install windows-build-system`, `python setup.py bdist_wheel` and it 
actually creates a wheel? (which AFAICT is the same problem).

My interest is precisely as a package developer. I've spent far far too much 
time fighting compilers on Windows (many days) and I don't want to do that any 
more. Every time I come across a new machine, I need to re-establish the 
current way to do things, which invariably doesn't work properly because I 
can't find the SDK to download, or the SDK installation doesn't include things 
any more, or some other reason which I can't work out. On Linux, everything is 
basically wonderful - I notice no difference between pure python packages and 
extensions packages.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25869] Faster ElementTree deepcopying

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25873] Faster ElementTree iterating

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20440] Use Py_REPLACE/Py_XREPLACE macros

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

According to the results of recent poll [1], Py_SETREF is the most popular 
candidate. It was also one of leaders in previous poll [2], and this is a name 
used in original Antoine's proposition [3].

[1] http://comments.gmane.org/gmane.comp.python.devel/155654
[2] http://comments.gmane.org/gmane.comp.python.devel/145974
[3] https://mail.python.org/pipermail/python-dev/2008-May/079862.html

Hence there is a patch that introduces and uses the Py_SETREF macro.

--
assignee:  -> serhiy.storchaka
versions: +Python 2.7, Python 3.6
Added file: http://bugs.python.org/file41380/py_setref.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25918] AssertionError in lib2to3 on 2.7.11 Windows

[Zachary Ware]

Changes by Zachary Ware :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25848] Tkinter tests failed on Windows buildbots

[Zachary Ware]

Zachary Ware added the comment:

Larry: considering that 3.4 is now officially out of bugfix mode, how long do 
you want to keep the 3.4 buildbots around?  From a selfish buildmaster 
configurator perspective, axing the 3.4 bots simplifies a few things :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25911] Regression: os.walk now using os.scandir() breaks bytes filenames on windows

[Zachary Ware]

Zachary Ware added the comment:

I like Serhiy's suggestion to use the old walk implementation on Windows if the 
argument is bytes, with a DeprecationWarning (like all other bytes operations 
in os on Windows).  There was no warning that bytes paths would stop working 
with os.walk, so we should fix it and I'm bumping up the priority.

bytes filenames have been deprecated since Python 3.3 (#13374); I don't think 
scandir (new in 3.5) should support bytes.

--
priority: normal -> high

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4709] Mingw-w64 and python on windows x64

[Zachary Ware]

Changes by Zachary Ware :


--
nosy: +zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21579] Python 3.4: tempfile.close attribute does not work

[Марк Коренберг]

Марк Коренберг added the comment:

So, I'm required to re-implement NamedTemporaryFile by hand like that:


fd, name = tempfile.mkstemp(...)
try:
with io.open(fd, ...) as fff:
fff.write('hello')
fff.flush()
os.fdatasync(fff)
os.rename(name, ...)
except:
os.unlink(name)
raise


This is sad to see...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21579] Python 3.4: tempfile.close attribute does not work

[R. David Murray]

R. David Murray added the comment:

You'd have to do that anyway if we implemented a delete=False constructor 
argument, since you want it deleted if there are any errors, and that's not 
what a delete=False API would do.  

If it were me, I'd write it (untested)

  @contextlib.contextmanager
  def open_for_atomic_replace(fn):
try:
fd, name = tempfile.mkstemp()
with io.open(fd) as fff:
yield fff
fff.flush()
os.fdatasync(fff)
os.rename(name, fn)
except BaseException:
os.unlink(name)
raise

which would make your code simpler than it is now.

Naming it 'open_for_atomic_replace' reminded me of issue 8604, which is what 
you really want, not delete=False.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25827] Support ICC in configure

[Roundup Robot]

Roundup Robot added the comment:

New changeset d7b5c2f99a99 by Zachary Ware in branch '2.7':
Issue #25827: Add support for ICC to configure
https://hg.python.org/cpython/rev/d7b5c2f99a99

New changeset c5e419464585 by Zachary Ware in branch '3.5':
Issue #25827: Add support for ICC to configure
https://hg.python.org/cpython/rev/c5e419464585

New changeset 29ea3827cfaa by Zachary Ware in branch 'default':
Issue #25827: Merge with 3.5
https://hg.python.org/cpython/rev/29ea3827cfaa

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25919] htp.client PUT method ignores error responses sent immediatly after headers

[Wiktor Niesiobedzki]

New submission from Wiktor Niesiobedzki:

It looks like, when doing PUT together with a file-like object to send, 
http.client will try to send the whole file before analysing the response from 
the server.

If you do the following:
$ dd if=/dev/zero of=/tmp/300mb.zero bs=1M count=300

And then run following code in Python 3.4 (tested 3.4.3 on Linux and FreeBSD):
import http.client
conn = http.client.HTTPSConnection('api.onedrive.com')
req = conn.request(
method='PUT',
url='https://api.onedrive.com/v1.0/drives/me/root:/test.file:/content',
body=open("/tmp/300mb.zero", "rb"))
resp = conn.getresponse()

You'll notice the hang. After some time, it will aborted with BrokenPipeError: 
[Errno 32] Broken pipe. If you run the following code within pdb debugger, and 
interrupt, you'll probably interrupt somewhere within write loop. You can call 
self.read() and see, that HTTP 413 is waiting to be interpreted.

Doing similar action with curl:
$ $ curl -v -T /tmp/300mb.zero 
https://api.onedrive.com/v1.0/drives/me/root:/test.file:/content

Gives you immediate HTTP 413 error. Can we have the same behaviour in 
http.client library?

--
components: IO
messages: 256808
nosy: Wiktor Niesiobedzki
priority: normal
severity: normal
status: open
title: htp.client PUT method ignores error responses sent immediatly after 
headers
type: behavior
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25919] htp.client PUT method ignores error responses sent immediatly after headers

[R. David Murray]

R. David Murray added the comment:

Perhaps by doing non-blocking reads between the writes[*]? I suppose it is 
possible, but it might complicate the code considerably.

[*] or re-write it using asyncio, but that is definitely out of scope :)

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25919] htp.client PUT method ignores error responses sent immediatly after headers

[SilentGhost]

Changes by SilentGhost :


--
components: +Library (Lib) -IO
versions: +Python 3.5, Python 3.6 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4709] Mingw-w64 and python on windows x64

[Steve Dower]

Steve Dower added the comment:

As an occasional Linux user, I notice a huge difference between pure Python and 
extension packages there, but basically always have a compiler handy on my 
Windows machines. It's all about context and what you're used to :)

The advice has always been "Visual Studio X" is what is needed, and for 3.5 
onwards that becomes "Visual Studio 2015 or later". Unfortunately, the story 
isn't so simple for legacy Python and 3.3/3.4 because those versions of VS are 
not so easy to get (unless you're a professional Windows developer with an MSDN 
subscription, which is pretty common). It is possible to use some other 
installers to get the old compilers, but Python was not designed to work with 
those and so there are issues that we cannot fix at this stage.

It also doesn't help that older versions of VC weren't as standards compliant, 
so people wrote code that doesn't compile when ported. There are also many 
dependencies that don't work directly with MSVC (for the same reason, but in 
this case it wasn't the package author's fault).

If you follow distutils-sig, where this occasionally comes up, you'll see the 
direction for packaging generally is to avoid needing to build. The hope is 
that even setuptools becomes nonessential enough that it can be dropped from a 
default install, but package developers will install it or another build 
manager to produce their packages (on Windows at least, though there's work 
ongoing to make this possible on many Linux distros too).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13317] building with 2to3 generates wrong import paths because build_ext is run after build_py

[Éric Araujo]

Éric Araujo added the comment:

I’m not active in python-dev anymore.

The fix was noted in a previous comment:

build.sub_commands in distutils.command.build should list "build_ext" before 
"build_py".
lib2to3.fixes.fix_import will write global instead of local import statements 
else.

--
assignee: eric.araujo -> 
components:  -Distutils2
nosy: +dstufft
versions: +Python 3.5 -3rd party, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25911] Regression: os.walk now using os.scandir() breaks bytes filenames on windows

[STINNER Victor]

STINNER Victor added the comment:

Python 3.5.0 and 3.5.1 are out. I don't think that it's worth to add back
bytes support is os.walk() in 3.5.2. I would prefer to do the opposite and
really drop bytes support for all filenames in the whole stdlib in 3.6.

It's really a bad idea to use bytes on Windows. With Python 3, it becomes
possible and simple to handle filenames as Unicode on all platforms and in
all cases (see PEP 393 for undecodable filenames).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

[Alessandro Cucci]

Alessandro Cucci added the comment:

Uploaded a new patch after SilentGhost review comments.

As he told me, I've left out milliseconds and nanoseconds, but refactored both 
python and c code so we could easily add support for them when they will be 
available.

--
Added file: http://bugs.python.org/file41381/issue19475_v6.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25914] Fix OrderedDict.__sizeof__

[Eric Snow]

Eric Snow added the comment:

LGTM

Thanks for doing that.  It's definitely cleaner. :)

--
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25920] PyOS_AfterFork should reset socketmodule's lock

[A. Jesse Jiryu Davis]

New submission from A. Jesse Jiryu Davis:

On some platforms there's an exclusive lock in socketmodule, used for 
getaddrinfo, gethostbyname, gethostbyaddr. A thread can hold this lock while 
another forks, leaving it locked forever in the child process. Calls to these 
functions in the child process will hang.

(I wrote some more details here: 
https://emptysqua.re/blog/getaddrinfo-deadlock/ )

I propose that this is a bug, and that it can be fixed in PyOS_AfterFork, where 
a few similar locks are already reset.

--
messages: 256815
nosy: emptysquare
priority: normal
severity: normal
status: open
title: PyOS_AfterFork should reset socketmodule's lock

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25920] PyOS_AfterFork should reset socketmodule's lock

[Ionel Cristian Mărieș]

Changes by Ionel Cristian Mărieș :


--
nosy: +ionelmc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25920] PyOS_AfterFork should reset socketmodule's lock

[Yury Selivanov]

Changes by Yury Selivanov :


--
components: +Interpreter Core
nosy: +haypo, yselivanov
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21579] Python 3.4: tempfile.close attribute does not work

[Eryk Sun]

Eryk Sun added the comment:

> To extend support for this to Windows, we can add a 
> feature to mkstmp to not use O_TEMPORARY

O_TEMPORARY is only used for NamedTemporaryFile, not mkstemp. 

Regarding NamedTemporaryFile, that can be worked around to keep Windows from 
deleting the file. Just open a second handle with DELETE (0x0001) access 
before closing the first one. Then close the first handle. Finally, use the 
second handle to call SetFileInformationByHandle [1] to remove the delete 
disposition. 

Since using O_TEMPORARY opens the file with DELETE access, you have to open the 
new handle with delete sharing. Unfortunately the CRT only provides O_TEMPORARY 
for opening a file with delete access and delete sharing, so just call 
CreateFile [2] directly instead. For example:

>>> import os, tempfile, msvcrt, ctypes
>>> kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
>>> f1 = tempfile.NamedTemporaryFile()
>>> f1.write(b'spam')
4
>>> h = kernel32.CreateFileW(f1.name, 0xC001, 7,
...  None, 3, 0x80, None)
>>> f1.close()
>>> os.path.exists(f1.name) # really, it does exist
False
>>> info = (ctypes.c_int * 1)(0)
>>> kernel32.SetFileInformationByHandle(h, 4, info, 4)
1
>>> os.path.exists(f1.name)
True
>>> f2 = os.fdopen(msvcrt.open_osfhandle(h, os.O_RDWR), 'r+')
>>> f2.read()
'spam'

Notice that right after f1 is closed, os.path.exists(f1.name) lies, saying the 
file no longer exists. The problem is you can't stat the file at this point 
because you can't open a *new* handle to a file that's marked for deletion. But 
you can use the existing handle to remove the delete disposition, after which 
the file is resurrected.

Also note that the FILE_DISPOSITION_INFO [3] docs say "t]his member has no 
effect if the handle was opened with FILE_FLAG_DELETE_ON_CLOSE". That's 
referring literally to the handle passed to SetFileInformationByHandle. 

Microsoft publishes the source for the FAT filesystem, so I could provide links 
for how this is implemented. Basically every kernel file object has a context 
control block (CCB) that points at an underlying kernel filesystem structure 
such as a file control block (FCB) or NTFS link/stream control block (LCB / 
SCB). When the file object is closed, the delete-on-close flag in the CCB gets 
transferred over to the underlying control structure and the delete disposition 
is set. You can't remove the CCB flag from the kernel file object (as the 
documentation correctly notes), but as long as you have an open handle to a 
file object whose CCB does not have this flag, you can use this other file 
handle to remove the delete disposition and make the file permanent. Just make 
sure to first close all file objects that do have the CCB delete-on-close flag 
because otherwise they'll just set the delete disposition again when closed.

[1]: https://msdn.microsoft.com/en-us/library/aa365539
[2]: https://msdn.microsoft.com/en-us/library/aa363858
[3]: https://msdn.microsoft.com/en-us/library/aa364221

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25920] PyOS_AfterFork should reset socketmodule's lock

[Yury Selivanov]

Yury Selivanov added the comment:

Maybe instead of releasing the lock in the forked child process, we should try 
to acquire the lock in the os.fork() implementation, and then release it?

Otherwise, suppose that a call to getaddrinfo (call #1) takes a long amount of 
time.  In the middle of it we fork, and then immediately try to call 
getaddrinfo (call #2, and call #1 is still happening) for some other address. 
At this point, since getaddrinfo isn't threadsafe, something bad will happen.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25920] PyOS_AfterFork should reset socketmodule's lock

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21579] Python 3.4: tempfile.close attribute does not work

[R. David Murray]

R. David Murray added the comment:

Oh, you are right of course.  I thought I was looking at _mkstemp_inner but in 
fact my edit window was over NamedTemporaryFile...I just wasn't paying 
attention.

I have no opinion myself as to whether it is worth the effort/code complexity 
to implement this behavior cross platform.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25878] CPython on Windows builds with /W3, not /W4

[Alexander Riccio]

Alexander Riccio added the comment:

> This should be about a 2 line change, but the current patch is several 
> hundred lines of spam.

I agree, but wasn't immediately sure how to do so.

Unfortunately, I've been working on other things, and I'm not sure when I'll be 
able to finish this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25911] Regression: os.walk now using os.scandir() breaks bytes filenames on windows

[Ben Hoyt]

Ben Hoyt added the comment:

Just to clarify what Victor and Zachary mentioned: bytes filenames have been 
deprecated only *on Windows* since Python 3.3; bytes filenames are still fine 
on POSIX.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25878] CPython on Windows builds with /W3, not /W4

[Zachary Ware]

Zachary Ware added the comment:

That's alright, it'll be here whenever you come back to it, unless
somebody else takes it up :)

By the way, my wording was poor in my previous message.  My 'hundreds
of lines of spam' remark was not meant to disparage your patch, but
rather Visual Studio's project editing abilities.  Sorry about that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25827] Support ICC in configure

[Zachary Ware]

Zachary Ware added the comment:

The buildbots appear to be happy with this, so I'm closing the issue.  The 
intel-ubuntu-icc Non-Debug builders each had their first green build after this 
changeset.  The OSX ICC builder still has some issues, but they seem to be OSX 
specific (see issue25589).

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25921] project files for wininst-14.0*.exe don't exist

[Mark Hammond]

New submission from Mark Hammond:

Revision 34b35aa1967d pushed new versions of wininst-14.8*.exe, but didn't 
include the VS project files required to build it, thus meaning it can't 
reasonably be built from the source tree.

--
components: Build
messages: 256823
nosy: mhammond, steve.dower
priority: normal
severity: normal
status: open
title: project files for wininst-14.0*.exe don't exist

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25921] project files for wininst-14.0*.exe don't exist

[Zachary Ware]

Zachary Ware added the comment:

The project file was moved to PC/bdist_wininst/bdist_wininst.vcxproj.  See 
55e5be11264e.  It's still included in the build solution, but not in the 
project used for building from the command line.

--
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25921] project files for wininst-14.0*.exe don't exist

[Mark Hammond]

Mark Hammond added the comment:

Awesome, thanks, sorry I missed that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25848] Tkinter tests failed on Windows buildbots

[Larry Hastings]

Larry Hastings added the comment:

I hear your plea.  But isn't it almost as easy to just leave it alone?  3.4 
won't get many checkins from now on, so it won't actually kick off many tasks.  
But it would mean the "check the buildbots" step of making a release would be 
super easy, rather than the huge pain of requesting a manual build on the 
buildbots.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25914] Fix OrderedDict.__sizeof__

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0a2ea08fcebe by Serhiy Storchaka in branch '3.5':
Issue #25914: Fixed and simplified OrderedDict.__sizeof__.
https://hg.python.org/cpython/rev/0a2ea08fcebe

New changeset 624316fbb39d by Serhiy Storchaka in branch 'default':
Issue #25914: Fixed and simplified OrderedDict.__sizeof__.
https://hg.python.org/cpython/rev/624316fbb39d

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25914] Fix OrderedDict.__sizeof__

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4709] Mingw-w64 and python on windows x64

[Ralf Gommers]

Ralf Gommers added the comment:

> @Steve Great, so what needs to be done so that I as a package developer can 
> do `pip install windows-build-system`, `python setup.py bdist_wheel` and it 
> actually creates a wheel? (which AFAICT is the same problem).

Hi Henry, I expect progress on the mingw-w64 front within the next few months. 
There'll be a status update with some more concrete plans soon. Also, 
http://mingwpy.github.io/ has appeared last week - a few wheels have been set 
in motion.

> The advice has always been "Visual Studio X" is what is needed, and for 3.5 
> onwards that becomes "Visual Studio 2015 or later".

Hi Steve, that's actually not very useful advice for the scientific Python 
community. While things like C99 compliance are or could get better, there will 
always be a large Fortran-shaped hole in your suggestion. See my post above 
(from May 19) for more details.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25922] canceling a repair install breaks the ability to uninstall repair or re-install

[Kyle S (MrStonedOne)]

New submission from Kyle S (MrStonedOne):

Title says all.

It refuses to install from that point on, complaining that a reboot is needed.

--
components: Installation, Windows
messages: 256829
nosy: Kyle S (MrStonedOne), paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: canceling a repair install breaks the ability to uninstall repair or 
re-install
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25922] canceling a repair install breaks the ability to uninstall, repair, or re-install

[Kyle S (MrStonedOne)]

Changes by Kyle S (MrStonedOne) :


--
title: canceling a repair install breaks the ability to uninstall repair or 
re-install -> canceling a repair install breaks the ability to uninstall, 
repair, or re-install

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com