[issue35440] Setup failed 0x80072f7d - Unspecified error

[Kamaal Khan]

New submission from Kamaal Khan :

I've been trying to install version 3.7.1 64-bit but it keeps on giving me that 
error. Tried fixing it by installing KB2999226, but to no avail. Been running 
the install file as admin too. Using Windows 7.
Install log is attached.

--
components: Windows
files: Python 3.7.1 (64-bit) log.txt
messages: 331375
nosy: DesignEngineer, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Setup failed 0x80072f7d - Unspecified error
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47981/Python 3.7.1 (64-bit) log.txt

___
Python tracker 

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

[issue35441] Dead (and buggy) code due to mishandling of PyList_SetItem() errors

[Zackery Spytz]

Change by Zackery Spytz :


--
components: Extension Modules
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Dead (and buggy) code due to mishandling of PyList_SetItem() errors
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8

___
Python tracker 

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

[issue35441] Dead (and buggy) code due to mishandling of PyList_SetItem() errors

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue35441] Dead (and buggy) code due to mishandling of PyList_SetItem() errors

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +10270
stage:  -> patch review

___
Python tracker 

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

[issue35435] Discourage external links to old docs.

[Julien Palard]

Julien Palard  added the comment:

> Without spending too much time on it, it seems to me there are s number of 
> issues here:
> 1. What URL schemes do we have and want to continue to support?
> 2. What things do we want to show up in search engine results?
> 3. How do we make that happen?
> 4. How do we maintain this going forward?

1. unchanged from today is good: let's not break things.
2. agree too: just the most current 3.x maintenance release
3. By adding links from old releases to new releases, go new releases get 
weight (from a search engine point of view) and should rank better. Also by 
checking if the canonical header is configured properly on all releases.
4. I don't think hiding old pages from search engine is a good idea, it's lying 
to them. I'd prefer the way of linking from old to new, which is both user 
friendly (a) and search engine friendly (b).

a) A nice text like "This is the documentation of an unmaintained version of 
Python, [switch to the latest version]" will not only help people landing from 
this old page from a search engine but also from favorites, links from 
articles, ...
b) Search engine compute the "weight" of a page by adding weights of pages 
linking to it. Our old pages are linked from a lot of articles and various 
sources, they have a huge weight. Linking from those pages to our new pages 
will forward a part of this weight to our new pages, ranking them a bit better. 
Which is I think better than hiding the old pages from them and loosing the 
weight they accumulated (risk: get old blogs articles rank better than new 
official documentation).

About the canonical, I'm having an issue opened indirectly about it 
(https://github.com/python/docsbuild-scripts/issues/51), by rebuilding old 
releases we could upgrade their headers and properly set a canonical link, 
typically from /3.4/ to /3/, like we're currently having from /3.5/ to /3/.

I have an opened issue about handling the /release/ directory from 
docsbuild-scripts instead of it being a manual step in the release process 
(https://github.com/python/docsbuild-scripts/issues/48).

I opened an issue in python-docs-theme about displaying a message pointing from 
old releases to new releases 
https://github.com/python/python-docs-theme/issues/24 mainly not to forgot 
about it.

--

___
Python tracker 

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

[issue34977] Release Windows Store app containing Python

[Paul Moore]

Paul Moore  added the comment:

> Yeah, and these are all essentially my fault (though I documented the 
> embeddable package relatively well, modulo a few uses I hadn't imagined). 
> Maybe my holiday writing project can be some better docs for choosing how to 
> install Python, especially since if/when this merges we'll finally have a 
> good answer for "installing from a build without the installer" (using the 
> PC/layout script, which *sigh* also needs a big fat manual).

Sorry about that - I wasn't trying to make you feel guilty! And yes,
the embeddable package docs are very good. The problem with that one
is mostly that people don't *read* the docs (but having them to point
to makes responding to pip issues much easier, so you have my
gratitude there :-)

> I feel like right now there's enough here that isn't quite locked down and I 
> don't want to guarantee it. For example, in a future release of Windows we 
> may be able to enable it to write to the actual %APPDATA% folder instead of 
> an app-private one - should we document the current paths and then "break" it 
> in the future? Or should we document that using the "Reset app" features will 
> clean up everything fully now, knowing that if we change the %APPDATA% 
> location later then _that_ will break?
>
> So for now, I want an unguaranteed store package that can be used but may 
> change over time (and I'll update the text on the page to reflect that). Now 
> is not the time to lock in all aspects of how it works, exactly as you say. 
> But please hold me accountable for adding specific docs for the first 3.8 
> release - hopefully it's clear by then (if not earlier) what behavior we're 
> happy with.

In which case, let's have a placeholder note in the docs, saying that
the Windows Store installer exists, but it's experimental and may have
unexpected interactions with other tools that expect a standard Python
install. Users trying the Windows Store installer should be prepared
for such issues, and we'd appreciate reports so that we can address
them. Add that to the release announcement as well for extra
visibility.

--

___
Python tracker 

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

[issue35330] When using mock to wrap an existing object, side_effect requires return_value

[Chris Withers]

Chris Withers  added the comment:


New changeset f05df0a4b679d0acfd0b1fe6187ba2d553b37afa by Chris Withers (Mario 
Corchero) in branch 'master':
bpo-35330:  Don't call the wrapped object if `side_effect` is set (GH10973)
https://github.com/python/cpython/commit/f05df0a4b679d0acfd0b1fe6187ba2d553b37afa


--

___
Python tracker 

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

[issue35330] When using mock to wrap an existing object, side_effect requires return_value

[miss-islington]

Change by miss-islington :


--
pull_requests: +10271

___
Python tracker 

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

[issue35330] When using mock to wrap an existing object, side_effect requires return_value

[miss-islington]

Change by miss-islington :


--
pull_requests: +10272

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[Anirudha Bose]

Change by Anirudha Bose :


--
keywords: +patch
pull_requests: +10273
stage: needs patch -> patch review

___
Python tracker 

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

[issue35330] When using mock to wrap an existing object, side_effect requires return_value

[Chris Withers]

Chris Withers  added the comment:


New changeset 12b9fb603eea9298c835bae5b8742db4fa52892e by Chris Withers (Miss 
Islington (bot)) in branch '3.6':
bpo-35330:  Don't call the wrapped object if `side_effect` is set (GH11034)
https://github.com/python/cpython/commit/12b9fb603eea9298c835bae5b8742db4fa52892e


--

___
Python tracker 

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

[issue35330] When using mock to wrap an existing object, side_effect requires return_value

[Chris Withers]

Chris Withers  added the comment:


New changeset ee2c5a8e2dcf662048dbcf4e49af9b4aaf81f7d3 by Chris Withers (Miss 
Islington (bot)) in branch '3.7':
bpo-35330:  Don't call the wrapped object if `side_effect` is set (GH11035)
https://github.com/python/cpython/commit/ee2c5a8e2dcf662048dbcf4e49af9b4aaf81f7d3


--

___
Python tracker 

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

[issue35330] When using mock to wrap an existing object, side_effect requires return_value

[Chris Withers]

Change by Chris Withers :


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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[pmpp]

pmpp  added the comment:

> and potentially other platforms?
strangely, it does not.


but adding a blocking read on first requests may ruin profiling data on any 
platform.

isn't http.server reserved for instrumentation and testing ?

--
nosy: +pmpp

___
Python tracker 

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

[issue35441] Dead (and buggy) code due to mishandling of PyList_SetItem() errors

[miss-islington]

Change by miss-islington :


--
pull_requests: +10274

___
Python tracker 

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

[issue35441] Dead (and buggy) code due to mishandling of PyList_SetItem() errors

[Serhiy Storchaka]

New submission from Serhiy Storchaka :


New changeset 99d56b53560b3867844472ae381fb3f858760621 by Serhiy Storchaka 
(Zackery Spytz) in branch 'master':
bpo-35441: Remove dead and buggy code related to PyList_SetItem(). (GH-11033)
https://github.com/python/cpython/commit/99d56b53560b3867844472ae381fb3f858760621


--

___
Python tracker 

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

[issue35441] Dead (and buggy) code due to mishandling of PyList_SetItem() errors

[miss-islington]

Change by miss-islington :


--
pull_requests: +10275

___
Python tracker 

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

[issue35441] Dead (and buggy) code due to mishandling of PyList_SetItem() errors

[miss-islington]

miss-islington  added the comment:


New changeset 8b7d8ac09cc0f736d0c3a39d838814d7ae253021 by Miss Islington (bot) 
in branch '3.7':
bpo-35441: Remove dead and buggy code related to PyList_SetItem(). (GH-11033)
https://github.com/python/cpython/commit/8b7d8ac09cc0f736d0c3a39d838814d7ae253021


--
nosy: +miss-islington

___
Python tracker 

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

[issue35441] Dead (and buggy) code due to mishandling of PyList_SetItem() errors

[miss-islington]

miss-islington  added the comment:


New changeset 2e0fbed15f809a247c7e16ab9d0a0088f806 by Miss Islington (bot) 
in branch '3.6':
bpo-35441: Remove dead and buggy code related to PyList_SetItem(). (GH-11033)
https://github.com/python/cpython/commit/2e0fbed15f809a247c7e16ab9d0a0088f806


--

___
Python tracker 

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

[issue31823] Opaque default value for close_fds argument in Popen.__init__

[Danish Prakash]

Change by Danish Prakash :


--
keywords: +patch
pull_requests: +10276
stage:  -> patch review

___
Python tracker 

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

[issue35440] Setup failed 0x80072f7d - Unspecified error

[Steve Dower]

Steve Dower  added the comment:

It looks like you're not able to download the debug symbol packages from your 
machine. This may be a network issue or perhaps a totally disconnected machine?

If you run setup with the "/layout [directory]" option on a machine with 
internet access it will give you all the possible installation files. Then you 
can transfer these to the other machine and install without needing network 
access.

Alternatively, deselect any install options that say "Download".

--

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[Steve Dower]

Steve Dower  added the comment:

Instrumentation is not the same thing as profiling, and this one is certainly 
not intended for performance. That said, simply importing it shouldn't impact 
anyone else's performance either, and since six imports this, fixing it will 
have a pretty broad impact.

Thanks for the PR - I'll look when I get a chance, but most of my time is going 
towards the next 3.7 release right now. Feel free to ping me on here in a week 
if nobody has had a look.

--

___
Python tracker 

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

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Steve Dower  added the comment:

> In which case, let's have a placeholder note in the docs, saying that
> the Windows Store installer exists, but it's experimental and may have
> unexpected interactions with other tools that expect a standard Python
> install. Users trying the Windows Store installer should be prepared
> for such issues, and we'd appreciate reports so that we can address
> them. Add that to the release announcement as well for extra
> visibility.

Sure, but first I need PR 11029 (and 11030 the backport) approved, so that I 
can rebase and work on redoing the other half of the change. Victor seems to 
have disappeared for the weekend, but I made all his requested changes.

--

___
Python tracker 

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

[issue35433] Correctly detect installed SDK versions

[Jeremy Kloth]

Jeremy Kloth  added the comment:

Not to be impatient or anything, but this change is keeping my buildbot from 
being useful.  Would it be possible for someone to merge as it has already been 
approved (msg331263).

--

___
Python tracker 

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

[issue35433] Correctly detect installed SDK versions

[Steve Dower]

Steve Dower  added the comment:

Did you see my comment about converting the version numbers to System.Version 
before comparing? (I didn't know it could be done the first time I looked :) )

--

___
Python tracker 

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

[issue34624] -W option and PYTHONWARNINGS env variable does not accept module regexes

[kernc]

Change by kernc :


--
nosy: +kernc

___
Python tracker 

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

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

[Maarten ter Huurne]

Maarten ter Huurne  added the comment:

I was working on what I thought would be an elegant solution to this problem: 
for non-qualified attributes, add the element's namespace before accessing the 
cache and strip the namespace prefix after accessing the cache if it's equal to 
the element's prefix.

However, this approach doesn't work: even though non-qualified attributes will 
be processed like they are the element's namespace, they are considered to have 
no namespace. This means  is considered valid XML, even 
though it effectively defines the same attribute twice.

https://www.w3.org/TR/REC-xml-names/#uniqAttrs

In my opinion the spec made a silly choice here, but that's probably not 
something that can fixed anymore.

I haven't decided yet whether I'll make another attempt at fixing this issue. 
In any case, I hope this tale of caution benefits someone.

--
nosy: +mthuurne

___
Python tracker 

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

[issue34977] Release Windows Store app containing Python

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy:  -terry.reedy

___
Python tracker 

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

[issue23874] Encrypted MSI fails to install with code 2755

[Terry J. Reedy]

Terry J. Reedy  added the comment:

For 3.x, this is out of date.  Since 3.5, Windows installers are .exe, not 
.msi. There will be no more 3.4 installers.

For 2.x, there should be at most 3 more releases.  But the .msi installer 
author has been inactive since before this was opened.  Given the rarity of the 
problem, the workaround of decrypting the file back to what we distribute, and 
the possibly of introducing a regression that only shows up after a release, I 
am confident that no one else wants to touch this.  So closing as won't fix.

--
nosy: +terry.reedy
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
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

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +rhettinger

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[pmpp]

pmpp  added the comment:

??? i never compared Instrumentation and profiling

and what getting delta timing about the script behind the first http request 
has to do with performance ? <= that's actually another question 

thefirst was : isn't http.server reserved for instrumentation and testing 
(because lazy loading seems a production feature to me ) ?

--

___
Python tracker 

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

[issue35442] Chain of several subcommands in argparse

[Victor Porton]

New submission from Victor Porton :

We should consider some way to implement argparse functionality asked here:

https://stackoverflow.com/q/53686523/856090

It is unclear how exactly to do this. This message is a call to discuss what 
should be the information format and API.

The awful thing is that I may need to write my own command line parser, as 
current argparse seems to be unable to provide this functionality.

I think, I will implement this for my program sooner or later but the idea to 
write my own analogue of argparse somehow terrifies me.

--
components: Library (Lib)
messages: 331393
nosy: porton
priority: normal
severity: normal
status: open
title: Chain of several subcommands in argparse
type: enhancement

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[Steve Dower]

Steve Dower  added the comment:

If you weren't conflating profiling and instrumentation then your original 
comment makes no sense.

--

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[Steve Dower]

Steve Dower  added the comment:

(Sorry, page submitted while I was still typing for some reason.)

... Instrumentation for everything other than time is unaffected, so if you 
didn't mean to conflate them, then no there is no impact on the documented use.

Yes, moving mimetypes.init to the first request will make the first request 
slower. However, it makes *import* faster, and there should not be a 
significant penalty just for importing this module.

You can trivially front-load the work in your app by calling mimetypes.init 
yourself, which will reduce the overhead on first request to a dict copy (I 
assume, haven't looked at the PR yet). Or just don't measure the first request 
- it's typical to do some warm-up loops when profiling.

--

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[pmpp]

pmpp  added the comment:

the PR as it is actually add a blocking read (and maybe exceptions or whatever 
mimetypes modules decide to do) in processing of the first request to server, 
which has nothing to do with the code serving that request.

I agree that makes no sense at all.

--

___
Python tracker 

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

[issue35440] Setup failed 0x80072f7d - Unspecified error

[Eryk Sun]

Eryk Sun  added the comment:

For what it's worth, 0x8007 indicates a Windows error, which in this case 
is ERROR_INTERNET_SECURITY_CHANNEL_ERROR (12157 or 0x2f7d) [1]: "the 
application experienced an internal error loading the SSL libraries".

[1]: https://docs.microsoft.com/en-us/windows/desktop/WinInet/wininet-errors

--
nosy: +eryksun

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[Steve Dower]

Steve Dower  added the comment:

> I agree that makes no sense at all.

I have to admit I have no idea what you're trying to argue or suggesting as an 
alternative. Could you try clearly explaining the change you'd rather see to 
fix the issue?

--

___
Python tracker 

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

[issue35267] reproducible deadlock with multiprocessing.Pool

[Windson Yang]

Windson Yang  added the comment:

As Jonathan Gossage said, I think it may break some code to fix this issue, 
maybe we could just add a warning on the document?

--

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> For what its worth, the colour I prefer for this bikeshed are 
> "comb" and "perm", which are the names used by the 
> HP 48GX calculator. Second choice would be to spell the names 
> out in full, "combinations" and "permutations".

+1 These would be my preferences as well :-)

--

___
Python tracker 

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

[issue35267] reproducible deadlock with multiprocessing.Pool

[Jonathan Gossage]

Jonathan Gossage  added the comment:

I think documentation is sufficient but I would like it to state the pitfalls 
available if apply_async is not synchronized correctly which will happen 
whenever the output does not fit the pipe buffer.

--

___
Python tracker 

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

[issue35325] imp.find_module() return value documentation discrepancy

[Windson Yang]

Change by Windson Yang :


--
keywords: +patch
pull_requests: +10277
stage:  -> patch review

___
Python tracker 

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

[issue35105] Document that CPython accepts "invalid" identifiers

[Windson Yang]

Windson Yang  added the comment:

Any ideas? Or I will create a PR in a week without 'CPython implementation 
detail'

--

___
Python tracker 

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

[issue35105] Document that CPython accepts "invalid" identifiers

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> Any ideas? Or I will create a PR in a week without 'CPython implementation 
> detail'

I don't think we want to give any stability guarantees for this. Perhaps 
we should explicitly state that this is not guaranteed behaviour and may 
change in the future.

I would be happy for it to be stated as an CPython implementation 
detail. If PyPy or any other implementation happen to duplicate it, 
we're not responsible for documenting that fact.

Please go ahead and make a PR.

--

___
Python tracker 

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

[issue22577] local variable changes lost after pdb jump command

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +10278
stage:  -> patch review

___
Python tracker 

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

[issue33725] Python crashes on macOS after fork with no exec

[Ned Deily]

Change by Ned Deily :


--
keywords: +patch
pull_requests: +10279
stage:  -> patch review

___
Python tracker 

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

[issue33725] Python crashes on macOS after fork with no exec

[miss-islington]

Change by miss-islington :


--
pull_requests: +10281

___
Python tracker 

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

[issue33725] Python crashes on macOS after fork with no exec

[Ned Deily]

Ned Deily  added the comment:


New changeset ac218bc5dbfabbd61c76ce8a17de088611e21981 by Ned Deily in branch 
'master':
bpo-33725: skip test_multiprocessing_fork on macOS (GH-11043)
https://github.com/python/cpython/commit/ac218bc5dbfabbd61c76ce8a17de088611e21981


--

___
Python tracker 

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

[issue33725] Python crashes on macOS after fork with no exec

[miss-islington]

Change by miss-islington :


--
pull_requests: +10280

___
Python tracker 

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

[issue33725] Python crashes on macOS after fork with no exec

[miss-islington]

miss-islington  added the comment:


New changeset d4bcf13e06d33b8ec66a68db20df34a029e66882 by Miss Islington (bot) 
in branch '3.7':
bpo-33725: skip test_multiprocessing_fork on macOS (GH-11043)
https://github.com/python/cpython/commit/d4bcf13e06d33b8ec66a68db20df34a029e66882


--
nosy: +miss-islington

___
Python tracker 

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

[issue35337] Check index in PyTuple_GET_ITEM/PyTuple_SET_ITEM in debug mode

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I think we can break this only after adding public API for accessing internal 
storage of a tuple: PyTuple_ITEMS().

And the same for lists.

--

___
Python tracker 

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

[issue33725] Python crashes on macOS after fork with no exec

[miss-islington]

miss-islington  added the comment:


New changeset df5d884defc8f1a94013ff9beb493f1428bd55b5 by Miss Islington (bot) 
in branch '3.6':
bpo-33725: skip test_multiprocessing_fork on macOS (GH-11043)
https://github.com/python/cpython/commit/df5d884defc8f1a94013ff9beb493f1428bd55b5


--

___
Python tracker 

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

[issue35337] Check index in PyTuple_GET_ITEM/PyTuple_SET_ITEM in debug mode

[Stefan Behnel]

Stefan Behnel  added the comment:

If this is really just about debugging, then I would suggest to not break 
existing code at all.

--
nosy: +scoder

___
Python tracker 

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

[issue33725] Python crashes on macOS after fork with no exec

[Ned Deily]

Ned Deily  added the comment:

Since it looks like multiprocessing_fork is not going to be fixable for macOS, 
the main issue remaining is how to help users avoid this trap (literally).  
Should we add a check and issues a warning or error at run time?  Or is a doc 
change sufficient?

In the meantime, I've merged changes to disable running 
test_multiprocessing_fork which will sometimes (but not always) segfault on 
10.14 Mojave.  I should apologize to Barry and others who have run into this.  
I did notice the occasional segfault when testing with Mojave just prior to its 
release but it wasn't always reproducible and I didn't follow up on it.  Now 
that the change in 10.14 behavior makes this existing problem with fork no exec 
more obvious, it's clear that the test segfaults are another manifestation of 
this.

--

___
Python tracker 

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

[issue34245] Python library should be installed writable

[Ned Deily]

Ned Deily  added the comment:


New changeset 25648d05ac3d74c436f951579bbb716372fb8cc7 by Ned Deily (jdemeyer) 
in branch 'master':
bpo-34245: install Python shared library with more standard 0755 mode (GH-8492)
https://github.com/python/cpython/commit/25648d05ac3d74c436f951579bbb716372fb8cc7


--
nosy: +ned.deily

___
Python tracker 

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

[issue34245] Python library should be installed writable

[Ned Deily]

Ned Deily  added the comment:

Thanks for the PR. I've merged it for release in 3.8.0.  As I commented on the 
PR, I don't think we should backport this; the current behavior has been around 
for many years and was working as designed so it's not really a bug.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[pmpp]

pmpp  added the comment:

sorry i was on my free time when enumerating profiling/instrumentation and 
testing. given now you pay attention i'll try to explain more.

instrumentation : what does that server actually support ? eg writing a test 
for a specific mimitype support eg https://bugs.python.org/issue35403 

profiling: i just want to time the first request to a service, ie without 
learning all the art of warming up a *one liner* http server with bare hands.

testing: i want to test the servicing code, not receive error because mimetypes 
module may have failed late and server should not have started *at all* since 
it is a critical component of it.




how to fix the issue ? as i said earlier, strangely "other platforms" don't 
have that issue so maybe the problem is in mimetypes module. 

So my position is "keep it that way" and investigate the slowdown at import on 
concerned platform.

--

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[Steve Dower]

Steve Dower  added the comment:

So, you're suggesting doing a lazy mimetypes.init() on Windows and not on the 
others? There's no reason to have such a semantic difference between platforms, 
and since the whole point of mimetypes.init() is to avoid initializing on 
import, it makes the most sense to avoid initializing on import.

In fact, it probably makes the *most* sense for http.server to have its own 
overrides, but otherwise fall back to the mimetypes function when needed. 
Bypassing the public API doesn't really add anything other than fragility.

--

___
Python tracker 

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