[issue24928] mock.patch.dict spoils order of items in collections.OrderedDict

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks @nekobon for the patch. I am triaging old mock related issues. I think 
dict insertion order is maintained from 3.6 and guaranteed with 3.7 and above. 
But it would be good to add the unit test in the patch as a PR. I ran the test 
on master and it passes.

--
nosy: +cjw296, mariocj89, xtreak
versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5

___
Python tracker 

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

[issue35257] Avoid leaking linker flags into distutils.

[Ned Deily]

Ned Deily  added the comment:

> Unfortunately, it appears this won't be resolved in time for 3.7.2rc1 and 
> 3.6.8rc1

An update: the cutoff for these releases has been extended until about 30 hours 
from now so there is perhaps a small chance that the PR for this could still be 
updated, reviewed, and merged in time.  If not, it can wait.

--

___
Python tracker 

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

[issue23078] unittest.mock patch autospec doesn't work on staticmethods

[Andrew Tennikoff]

Change by Andrew Tennikoff :


--
nosy: +atenni

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

I've added a PR for 3.6 using a different methodology for finding the available 
SDK.

Without some change, my buildbot will continue to stay in the red (for 3.6).  
It does not the the highest SDK currently (previously?) listed the hard-coded 
list.  It has the latest (17763), the latest for VS2015 (14393) and the 
baseline (10586).  I would like to see a working build for VS2015 on 3.6.  Once 
3.6 is wrapped, I'll update the buildbot to VS2017 as that is what is listed in 
the README for building 3.7+, whereas 3.6 lists VS2015.

--

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

Change by Jeremy Kloth :


--
pull_requests: +10294

___
Python tracker 

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

[issue33779] Error while installing python 3.6.5 on windows 10

[Steve Dower]

Steve Dower  added the comment:

Thanks for the extra info! I think the registration is put in there during 
install in case the PC restarts part way through, but it doesn't have to hang 
around after install is complete. Your explanation makes sense, and is a good 
reason to disable antivirus software while installing.

--

___
Python tracker 

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

[issue33779] Error while installing python 3.6.5 on windows 10

[BobClown]

BobClown  added the comment:

An addition to the record, as Google returns this issue as one of the top 
results for "python install \"Error 0x80070005: Failed to register bundle.\"":

In my case, I had removed access for all users on the HKCU/RunOnce key and was 
getting this error.  The purpose of removing access to that key is so Windows 
doesn't automatically relaunch all running programs on restart, as the setting 
to disable it does not exist in some earlier windows 10 patches.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

After restoring permission to my user, the package installed successfully. 
 During installation, it was observed that the path to a temporary copy of the 
installer executable was added as a string value under the RunOnce key, purpose 
unknown.  This string value was removed by the time installation was completed.

While I disallowed access to this key manually, I suspect that some anti* 
software may also block access.

Binary:
python-3.7.1-amd64.exe
SHA256 86E38B5F819F4141A7FA14DF39AB33E2AA97074E904A48AD498519AD3E69D017

--
nosy: +bobclown

___
Python tracker 

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

[issue35447] Redundant try-except block in urllib

[Martin Panter]

Martin Panter  added the comment:

That would not include the custom error message for the first two cases I 
listed. I suggest closing this.

--

___
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

[miss-islington]

miss-islington  added the comment:


New changeset c83ec055a09137e4b24f70e3bb5f887dc0ae6e8e by Miss Islington (bot) 
in branch '3.7':
bpo-35433: Properly detect installed SDK versions (GH-11009)
https://github.com/python/cpython/commit/c83ec055a09137e4b24f70e3bb5f887dc0ae6e8e


--
nosy: +miss-islington

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

Not making this change for Python 3.6, as that apparently breaks with the 
latest SDK (seen in the Pipelines build). So we'll leave 10.0.15063.0 as the 
maximum version for that - it's about to go into security mode anyway, and we 
don't rely on anything from the SDK with a security impact. (It's all import 
libraries, and the static libraries should be coming from the compiler toolset 
and not the platform SDK.)

--
versions:  -Python 3.6

___
Python tracker 

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

[issue35447] Redundant try-except block in urllib

[Shishmarev Pavel]

Shishmarev Pavel  added the comment:

https://github.com/python/cpython/blob/master/Lib/urllib/parse.py#L875
It's redundant to raise and then catch exception.

I mean:
if len(query) and not isinstance(query[0], tuple):
ty, va, tb = sys.exc_info()
raise TypeError("not a valid non-string sequence "
"or mapping object").with_traceback(tb)


Would be more clean.

--

___
Python tracker 

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

[issue35447] Redundant try-except block in urllib

[Martin Panter]

Martin Panter  added the comment:

Code in question:

try:
# non-sequence items should not work with len()
# non-empty strings will fail this
if len(query) and not isinstance(query[0], tuple):
raise TypeError
# [. . .]
except TypeError:
ty, va, tb = sys.exc_info()
raise TypeError("not a valid non-string sequence "
"or mapping object").with_traceback(tb)

It is not redundant if you want a specific error message. I think that is the 
point of the code, to indicate the problem to the programmer. So the message is 
meant to be useful. I can think of three cases:

>>> urlencode(None)  # Non-sequence
TypeError: not a valid non-string sequence or mapping object
>>> urlencode({'sized but not indexable'})
TypeError: not a valid non-string sequence or mapping object
>>> urlencode('item [0] not a tuple')
TypeError: not a valid non-string sequence or mapping object

--
nosy: +martin.panter

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

Thanks for being thorough. I've merged the change now.

--
assignee:  -> steve.dower
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

[issue35433] Correctly detect installed SDK versions

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +10293

___
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

[miss-islington]

Change by miss-islington :


--
pull_requests: +10292

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


New changeset f46eccd0ffe65333035c3820886295b71c41ab6e by Steve Dower (Jeremy 
Kloth) in branch 'master':
bpo-35433: Properly detect installed SDK versions (GH-11009)
https://github.com/python/cpython/commit/f46eccd0ffe65333035c3820886295b71c41ab6e


--

___
Python tracker 

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

[issue35449] documenting objects

[Stefan Seefeld]

Stefan Seefeld  added the comment:

On 2018-12-09 19:48, Karthikeyan Singaravelan wrote:
> There was a related proposal in 
> https://www.python.org/dev/peps/pep-0258/#attribute-docstrings

Right, but that was rejected (for unrelated reasons). The idea itself
was rejected by Guido
(https://www.python.org/dev/peps/pep-0224/#comments-from-our-bdfl), and
I'm not aware whether anyone has addressed his concerns by proposing a
different syntax.

It's sad, as right now there doesn't appear to be any way to address
this need...

Stefan

-- 

  ...ich hab' noch einen Koffer in Berlin...

--

___
Python tracker 

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

[issue23864] issubclass without registration only works for "one-trick pony" collections ABCs.

[Guido van Rossum]

Guido van Rossum  added the comment:

No, I consider this is a documentation problem. I don't recall why the docs say 
that (I don't even know if they still say that or whether Martijn misread 
them), but IMO this should not be changed.

--

___
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

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I think it make sense to disable this test; the only possible modification 
would be to only disable it for macOS <= 10.13.  AFAIK, that's the first 
version where core dumps were possible.  (Aside: I also saw these core dumps 
for a long time on 10.13 and never associated it with fork-without-exec in 
Python code.  Clearly, Apple has not done a good enough job of advertising this 
change.)

I think it is useful to help users on macOS avoid these problematic idioms, via 
documentation and defaults.  I think there's no way to predict when the core 
dumps will happen.  With internal cases, I've seen repeated invocations of the 
same code only core dump on the first run of the process, and not subsequent 
ones, for reasons I do not understand.  There seems to be a lot of mystery 
here, and without some explicit help from Apple, we're just doing our best to 
guess.

--

___
Python tracker 

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

[issue35449] documenting objects

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

There was a related proposal in 
https://www.python.org/dev/peps/pep-0258/#attribute-docstrings

--

___
Python tracker 

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

[issue35449] documenting objects

[Stefan Seefeld]

Stefan Seefeld  added the comment:

On 2018-12-09 18:35, Steven D'Aprano wrote:
> Steven D'Aprano  added the comment:
>
>> Is there any discussion concerning what syntax might be used for 
>> docstrings associated with objects ?
> I don't know about PyDoc in general, but I would expect help(obj) to 
> just use obj.__doc__ which will return the instance docstring if it 
> exists, and if not, the type docstring (if it exists). No new syntax is 
> required, the standard ``help(obj)`` is sufficient.

That's why I distinguished between points 1) and 2) in my original mail:
The syntax is about how certain tokens in the parse tree are associated
as "docstring" with a given object (i.e., point 1), while the pydoc's
behaviour (to either accept any `__doc__` attributes, or only those of
specific types of objects) is entirely orthogonal to that (thus point 2).

I now understand that the current `pydoc` behaviour is considered
erroneous, and it sounds like a fix would be simple and focused in scope.

>> (There seem to be some partial 
>> solutions added on top of the Python parser (I think `epydoc` offered 
>> one), but it would be nice to have a built-in solution to avoid having 
>> to re-invent wheels.
> Are you suggesting we need new syntax to automatically assign docstrings 
> to instances? I don't think we do.

No, I'm not suggesting that. I'm suggesting that within the current
syntax, some additional semantic rules might be required to bind
comments (or strings) to objects as "docstrings". For example:

```

foo = 123

"""This is foo's docstring"""

```

might be one convention to add a docstring to a variable.

```

foo = 123

# This is foo's docstring

```

might be another.

None of this is syntactically new, but the construction of the AST from
the parse tree is. (I have seen both of these conventions used in custom
tools to associate documentation to variables, which of course requires
hacking into the parser internals, to add the given docstring to the
object's `__doc__` attribute.

It would be great to establish a convention for this, so in the future
tools don't have to invent their own (non-portable) convention.

--

___
Python tracker 

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

[issue23864] issubclass without registration only works for "one-trick pony" collections ABCs.

[Géry]

Géry  added the comment:

Guido, could we add those missing __subclasshook__ for consistency?

--
nosy: +gvanrossum, maggyero

___
Python tracker 

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

[issue35449] documenting objects

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> Is there any discussion concerning what syntax might be used for 
> docstrings associated with objects ?

I don't know about PyDoc in general, but I would expect help(obj) to 
just use obj.__doc__ which will return the instance docstring if it 
exists, and if not, the type docstring (if it exists). No new syntax is 
required, the standard ``help(obj)`` is sufficient.

> (There seem to be some partial 
> solutions added on top of the Python parser (I think `epydoc` offered 
> one), but it would be nice to have a built-in solution to avoid having 
> to re-invent wheels.

Are you suggesting we need new syntax to automatically assign docstrings 
to instances? I don't think we do.

I expect that if you want to set a custom instance docstring, you would 
just say ``instance.__doc__ = "The doc string"`` after creating the 
instance, or ``self.__doc__ = "..."`` inside the __init__ method.

--

___
Python tracker 

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

[issue35449] documenting objects

[Stefan Seefeld]

Stefan Seefeld  added the comment:

Exactly ! I'm fully aware of the ubiquity of objects in Python, and it is for 
that reason that I had naively expected `pydoc` to simply DoTheRightThing when 
encountering an object containing a `__doc__` attribute. rather than only 
working for types and function objects.

OK, assuming that this is a recognized bug / limitation, it seems easy to 
address.

Is there any discussion concerning what syntax might be used for docstrings 
associated with objects ? (There seem to be some partial solutions added on top 
of the Python parser (I think `epydoc` offered one), but it would be nice to 
have a built-in solution to avoid having to re-invent wheels.

--

___
Python tracker 

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

[issue35122] Process not exiting on unhandled exception when using multiprocessing module

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
resolution:  -> not a bug
stage:  -> 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

[issue35449] documenting objects

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Minor note on terminology: classes and functions are themselves objects.

I think that help() (or in particular PyDoc in general) should support any 
instance with a __doc__ attribute. Its failure to do so is causing pain, see 
#12154.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue20239] Allow repeated deletion of unittest.mock.Mock attributes

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +10291
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

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

[tzickel]

tzickel  added the comment:

https://bugs.python.org/issue35267

--

___
Python tracker 

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

With Gregory's addition I think this issue can be considered fixed. Thank you 
Gregory.

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Serhiy: should this one be marked fixed?

--
assignee:  -> serhiy.storchaka
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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Gregory P. Smith]

Gregory P. Smith  added the comment:

It is fundamentally impossible for pickled data to magically cross the 2 and 3 
language boundary unscathed.

The basic str/bytes/unicode types in the language changed meaning.  Code must 
be written manually by the data owners to fix that up based on what the types 
and encodings should actually be in various places given the language version 
the data is being read into.

The code in the PRs for this bug appears to do that in the requisite required 
hacky manner for stored datetime instances.

This fact isn't new.  It happened 10 years ago with the release of Python 3.0.  
The documentation is not a contract.  I'm fixing it to mention this.

--

___
Python tracker 

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

[issue27004] Handle script shbang options

[Miro Hrončok]

Miro Hrončok  added the comment:

As a distro Python maintainer, I have to say that having yet another Python 
executable would no be accepted well by the other distro contributors or even 
users.

I'll try to work on a proper solution that would merge the options, hopefully 
soon (but most likely not before the end of the year).

--
nosy: +hroncok

___
Python tracker 

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[miss-islington]

miss-islington  added the comment:


New changeset 331bfa4f2c3026a35e111303df0f198d06b4e0c8 by Miss Islington (bot) 
in branch '3.7':
bpo-22005: Document the reality of pickle compatibility. (GH-11054)
https://github.com/python/cpython/commit/331bfa4f2c3026a35e111303df0f198d06b4e0c8


--
nosy: +miss-islington

___
Python tracker 

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[miss-islington]

Change by miss-islington :


--
pull_requests: +10290

___
Python tracker 

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset e328753d91379274b699b93decff45de07854617 by Gregory P. Smith in 
branch 'master':
bpo-22005: Document the reality of pickle compatibility. (GH-11054)
https://github.com/python/cpython/commit/e328753d91379274b699b93decff45de07854617


--

___
Python tracker 

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Gregory P. Smith]

Change by Gregory P. Smith :


--
pull_requests: +10289

___
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

[Henry Chen]

Change by Henry Chen :


--
nosy: +henry

___
Python tracker 

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

[issue35450] venv module doesn't create a copy of python binary by default

[Ned Deily]

Change by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue35450] venv module doesn't create a copy of python binary by default

[Marcin]

New submission from Marcin :

Hello,
from documentation:
https://docs.python.org/3/library/venv.html

"python3 -m venv /path/to/new/virtual/environment

Running this command creates the target directory (creating any parent 
directories that don’t exist already) and places a pyvenv.cfg file in it with a 
home key pointing to the Python installation from which the command was run. It 
also creates a bin (or Scripts on Windows) subdirectory containing **a copy** 
of the python binary (or binaries, in the case of Windows)."

This is not true. In my case it creates symlinks to python binary by default. 
This is quite different. Upgrading system's python version broke my virtual 
environment because I believed I'm having a static copy of python binary in my 
virtual environment.

--
assignee: docs@python
components: Documentation
messages: 331445
nosy: docs@python, mkkot
priority: normal
severity: normal
status: open
title: venv module doesn't create a copy of python binary by default
versions: Python 3.7

___
Python tracker 

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

[issue35448] ConfigParser .read() - handling of nonexistent files

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue35449] documenting objects

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Also, making tests that do not leak threads for this case is very difficult as 
if we go with weakrefs, the test *has* to leak a pool (the pool is dead but 
never calls join/close) to check that when you use the iterator the exception 
happens. Also, getting such test race-free is going to be challenging.

--

___
Python tracker 

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

[issue35449] documenting objects

[Stefan Seefeld]

New submission from Stefan Seefeld :

On multiple occasions I have wanted to add documentation not only to Python 
classes and functions, but also instance variables. This seems to involve (at 
least) two orthogonal questions:

1) what is the proper syntax to associate documentation (docstrings ?) to 
objects ?
2) what changes need to be applied to Python's infrastructure (e.g., the help 
system) to support it ?


I have attempted to work around 1) in my custom code by explicitly setting an 
object's `__doc__` attribute. However, calling `help()` on such an object would 
simply ignore that attribute, and instead list the documentation associated 
with the instance type.

Am I missing something here, i.e. am I approaching the problem the wrong way, 
or am I the first to want to use object-specific documentation ?

--
messages: 331443
nosy: stefan
priority: normal
severity: normal
status: open
title: documenting objects
type: enhancement

___
Python tracker 

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

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I am playing with weakreferences inside the iterator objects, but this may not 
be enough. For example, take the code of ApplyResult.get:

def get(self, timeout=None):
if self._pool() is None:
raise RuntimeError("The pool is dead!") <--- new code
self.wait(timeout)

It can be that the pool is alive when we check for it (self._pool() is None) 
but while the code is waiting with no timeout, the pool dies, effectively 
leaving the program deadlocked with no error.

--

___
Python tracker 

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

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I am playing with passing weakreferences into the iterator objects, but this 
may not be enough. For example, take the code of ApplyResult.get:

def get(self, timeout=None):
if self._pool() is None:
raise RuntimeError("The pool is dead!") <--- new code
self.wait(timeout)

It can be that the pool is alive when we check for it (self._pool() is None) 
but while the code is waiting with no timeout, the pool dies, effectively 
leaving the program deadlocked with no error.

--

___
Python tracker 

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

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
Removed message: https://bugs.python.org/msg331441

___
Python tracker 

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

[issue34079] Multiprocessing module fails to build on Solaris 11.3

[Clint Allen]

Clint Allen  added the comment:

Agreed, that is a better approach.
I have tested your patch successfully with gcc on Solaris 11.3.

--

___
Python tracker 

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

[issue35448] ConfigParser .read() - handling of nonexistent files

[Adrian Wielgosik]

New submission from Adrian Wielgosik :

Documentation of ConfigParser says:

> If a file named in filenames cannot be opened, that file will be ignored. 
> This is designed so that you can specify an iterable of potential 
> configuration file locations (for example, the current directory, the user’s 
> home directory, and some system-wide directory), and all existing 
> configuration files in the iterable will be read.

While this is a useful property, it can also be a footgun. The first read() 
example in the Quick Start section contains just a single file read:

>>> config.read('example.ini')

I would expect that this basic usage is very popular. If the file doesn't 
exist, the normal usage pattern fails in a confusing way:

 from configparser import ConfigParser
 config = ConfigParser()
 config.read('config.txt')
 value = config.getint('section', 'option')
---> configparser.NoSectionError: No section: 'section'

In my opinion, this error isn't very obvious to understand and debug, unless 
you have read that piece of .read() documentation.

This behavior did also bite me even more, with another usage pattern I've found 
in a project I maintain:
> config.read('global.txt')
> config.read('local.txt')
Here, both files are expected to exist, with the latter one extending or 
updating configuration from the first file. If one of the files doesn't exist 
(eg mistake during deployment), there's no obvious error, but the program will 
be configured in different way than intended.

Now, I'm aware that all of this can be avoided by simply using `read_file()`:
> with open('file.txt') as f:
>config.read_file(f)
But again, `.read()` is the one usually mentioned first in both the official 
documentation, and most independent guides, so it's easy to get wrong.

Due to this, I propose adding an extra parameter to .read():
read(filenames, encoding=None, check_exist=False)
that, when manually set to True, will throw exception if any of input files 
doesn't exist; and to use this parameter by default in Quick Start section of 
ConfigParser documentation.
If this is a reasonable idea, I could try and make a PR.

For comparison, the `toml` Python library has the following behavior:
- if argument is a single filename and file doesn't exist, it throws
- if argument is a list of filenames and none exist, it throws
- if argument is a list of filenames and at least one exists, it works, but 
prints a warning for each nonexistent file.

For the record, seems like this issue was also mentioned in 
https://bugs.python.org/issue490399

--
components: Library (Lib)
messages: 331439
nosy: Adrian Wielgosik
priority: normal
severity: normal
status: open
title: ConfigParser .read() - handling of nonexistent files
type: behavior

___
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

[Davin Potts]

Davin Potts  added the comment:

@ned.deily: Apologies, I misread what you wrote -- I would like to see the 
random segfaults that you were seeing on Mojave if you can still point me to a 
few.

--

___
Python tracker 

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

[issue35447] Redundant try-except block in urllib

[Shishmarev Pavel]

Change by Shishmarev Pavel :


--
pull_requests: +10288

___
Python tracker 

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

[issue35447] Redundant try-except block in urllib

[Shishmarev Pavel]

Change by Shishmarev Pavel :


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

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

Sorry for the delay, but I wanted to get an environment that still had an older 
VS2015 install to test against.  VS2015 prior to Update 3 use a different 
heuristic to determine the SDK version for building.

I've made the following changes:
- version checking uses System.Version,
- WindowsTargetPlatformVersion is set to the detected Win10 SDK (this is the 
offical setting anyway, but required for VS2015 prior to Update 3)
- added display of the detected SDK to ShowVersionInfo target (build.bat -V)

--

___
Python tracker 

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

[issue35447] Redundant try-except block in urllib

[Shishmarev Pavel]

New submission from Shishmarev Pavel :

https://github.com/python/cpython/blob/master/Lib/urllib/parse.py#L875
It's redundant to raise and then catch exception.

--
components: Library (Lib)
messages: 331436
nosy: PashaWNN
priority: normal
severity: normal
status: open
title: Redundant try-except block in urllib
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, 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

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

[Davin Potts]

Davin Potts  added the comment:

Do we really need to disable the running of test_multiprocessing_fork entirely 
on MacOS?

My understanding so far is that not *all* of the system libraries on the mac 
are spinning up threads and so we should expect that there are situations where 
fork alone may be permissible, but of course we don't yet know what those are.  
Pragmatically speaking, I have not yet seen a report of 
test_multiprocessing_fork tests triggering this problem but I would like to 
see/hear that when it is observed (that's my pitch for leaving the tests 
enabled).

--

___
Python tracker 

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

[issue20239] Allow repeated deletion of unittest.mock.Mock attributes

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I find this to be a reasonable behavior as with normal objects that support 
setting the attribute after deletion. It also seems to be an easy issue since 
@michael.foord has already attached the patch for this from the original 
report. The patch also also causes no test failure on master and a unit test 
can be added for the behavior once confirmed.

--
nosy: +cjw296, mariocj89, xtreak
versions: +Python 3.7, Python 3.8 -Python 3.3, Python 3.4

___
Python tracker 

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

[issue28054] Diff for visually comparing actual with expected in mock.assert_called_with.

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

It seems that TestCase in unittest.case accepts failureException attribute that 
is raised on assertion failure. My initial approach is to subclass TestCase and 
add a custom failure exception like MockException that is caught to add the 
diff to the original message. I am adding @cjw296 and @mariocj89 for feedback 
since I hope this can reuse unittest.case.TestCase implementation for diffs. I 
think this is better done with a flag like verbose=True to display the 
difference and defaulting to False since sometimes the message can be long 
depending on args and kwargs. Also I find args (tuple) comparison to be little 
distracting. Since this is an enhancement I am adding 3.8.

# Sample file

from unittest.mock import Mock

m = Mock()
m(1, 2, foo='bar', bar='baz')
m.assert_called_with(2, 3, bar='baz', foo='car')

# On 3.7

$ python3.7 /tmp/foo_4.py
Traceback (most recent call last):
  File "/tmp/foo_4.py", line 5, in 
m.assert_called_with(2, 3, bar='baz', foo='car')
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/mock.py",
 line 820, in assert_called_with
raise AssertionError(_error_message()) from cause
AssertionError: Expected call: mock(2, 3, bar='baz', foo='car')

# With patch

$ ./python.exe /tmp/foo_4.py
Traceback (most recent call last):
  File "/tmp/foo_4.py", line 5, in 
m.assert_called_with(2, 3, bar='baz', foo='car')
  File 
"/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", 
line 844, in assert_called_with
raise AssertionError(_error_message()) from cause
AssertionError: Expected call: mock(2, 3, bar='baz', foo='car')
Actual call: mock(1, 2, bar='baz', foo='bar')
args: Tuples differ: (2, 3) != (1, 2)

First differing element 0:
2
1

- (2, 3)
+ (1, 2)
kwargs: {'bar': 'baz', 'foo': 'car'} != {'foo': 'bar', 'bar': 'baz'}
- {'bar': 'baz', 'foo': 'car'}
?^

+ {'bar': 'baz', 'foo': 'bar'}
?^

--
keywords: +patch
nosy: +cjw296, mariocj89
versions: +Python 3.8 -Python 2.7, Python 3.7
Added file: https://bugs.python.org/file47982/issue28054.diff

___
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 think I have a good solution now, see the pull request for details. It does 
touch a lot of code, but I split all the changes into small consistent units, 
so it should be easier to verify whether they are correct.

--

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

Change by Maarten ter Huurne :


--
pull_requests: +10286
stage:  -> patch review

___
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 Krah]

Stefan Krah  added the comment:

If the feature is for the Python test suite itself, one solution would be to 
add -DPY_BOUNDS_CHECKS and use that on the buildbots.

I still think making all of the test suite Valgrind-ready (most of it is, 
except test_multiprocessing and a few others) would catch more.

--

___
Python tracker 

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

[issue26704] unittest.mock.patch: Double patching instance method: AttributeError: Mock object has no attribute '__name__'

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks @asottile for the patch. I think the original AttributeError is resolved 
with issue28919 where they were silenced. It seems similar to issue32153 though 
the exception occurs from mock instead of partial object as in issue32153. The 
fix was applied to 3.7+ and hence 3.6 was not fixed which enters security fix 
only mode shortly. The attached tests also pass on master and I think it will 
it be a good unittest addition to Lib/unittest/test/testmock/testwith.py 
(similar to issue32153) that has a couple of nested with statements for the 
same attribute. Adding cjw296 to the list.

--
nosy: +cjw296, xtreak

___
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 Krah]

Stefan Krah  added the comment:

Since this feature mainly helps when running a test suite using a debug build:

The same can be achieved by running the test suite under Valgrind, which 
catches invalid accesses and a lot more.

So I'd prefer to keep the macro in its current form.

--

___
Python tracker 

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

[issue35445] Do not ignore errors when create posix.environ

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue35446] incorrect example

[Alistsair Lenhard]

New submission from Alistsair Lenhard :

under: https://docs.python.org/3/tutorial/errors.html

Original it says:
"Note that if the except clauses were reversed (with except B first), it would 
have printed B, B, B — the first matching except clause is triggered."

It should read:
"Note that if the except clauses were reversed (with except B first), it would 
have printed D, D, D — the first matching except clause is triggered."
 
As D is the first expression in the print statement.
So if the expression is changed to "except B:"

class B(Exception):
pass

class C(B):
pass

class D(C):
pass

for cls in [B, C, D]:
try:
raise cls()
except B:
print("D")
except C:
print("C")
except B:
print("B")

Result is:
D
D
D

--
assignee: docs@python
components: Documentation
messages: 331428
nosy: Alistair, docs@python
priority: normal
severity: normal
status: open
title: incorrect example
versions: Python 3.7

___
Python tracker 

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

[issue20602] sys.flags and sys.float_info disappear at shutdown

[Zackery Spytz]

Zackery Spytz  added the comment:

Ping.

--

___
Python tracker 

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

[issue35445] Do not ignore errors when create posix.environ

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Currently most errors during creating posix.environ are ignored except an error 
of creating an empty dict.

The initial revision 85a5fbbdfea617f6cc8fae82c9e8c2b5c424436d contained the 
comment "XXX This part ignores errors". Later changes removed "XXX" from the 
comment and added explicit error clearing. Later the POSIX code was duplicated 
for Windows. It looks to me that that comment was not declared the intentional 
behavior, but just described existing code, and was left as a reminder for 
implementing error handling.

The proposed PR implements proper error handling in this code.

--
components: Extension Modules
messages: 331427
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Do not ignore errors when create posix.environ
type: enhancement
versions: Python 3.8

___
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 Krah]

Stefan Krah  added the comment:

I'm using _GET_ITEM(args, 0), so Serhiy's concern is not theoretical.

I think if people want the safe version they should use PyTuple_GetItem().

--
nosy: +skrah

___
Python tracker 

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

[issue35443] Add Tail Call Optimization

[Muhammed Alkan]

Change by Muhammed Alkan :


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

[issue17185] unittest mock create_autospec doesn't correctly replace mocksignature

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


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

___
Python tracker 

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

[issue35444] Unify and optimize the helper for getting a builtin object

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue35444] Unify and optimize the helper for getting a builtin object

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

_PyIter_GetBuiltin() was introduced in issue14288 
(31668b8f7a3efc7b17511bb08525b28e8ff5f23a). This was used for getting 
references to the builtin "iter" and "reverse". It was renamed to 
_PyObject_GetBuiltin() in a701388de1135241b5a8e4c970e06c0e83a66dc0.

There is other code that gets references to the builtin "getattr" using 
PyEval_GetBuiltins(). It is more efficient, but contains bugs.

The proposed PR unifies getting references to builtins:

* The prefix _PyObject_ is changed to _PyEval_, since this function has 
relation not to the object type but to the evaluation environment.

* It uses now the private _Py_Identifier API instead of a raw C string. This 
saves time by omitting the creation of a Unicode object on every call.

* It uses now fast PyEval_GetBuiltins() instead of slower PyImport_Import().

* Fixed errors handling in the code that used PyEval_GetBuiltins() before. It 
no longer swallows unexpected exceptions, no longer returns an error without 
setting an exception, and no longer causes raising a SystemError.

An example of an error in current code:

>>> import builtins
>>> del builtins.getattr
>>> int.bit_length.__reduce__()
Traceback (most recent call last):
  File "", line 1, in 
SystemError: NULL object passed to Py_BuildValue

--
components: Interpreter Core
messages: 331424
nosy: kristjan.jonsson, pitrou, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Unify and optimize the helper for getting a builtin object
versions: Python 3.8

___
Python tracker 

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

[issue35443] Add Tail Call Optimization

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Guido had some thoughts on Tail Recursion Optimization (TRE). 

http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html

--
nosy: +xtreak

___
Python tracker 

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

[issue35443] Add Tail Call Optimization

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> I see nothing wrong with adding Tail Call Optimization to Python.

That's nice. Is that supposed to be an argument that convinces us?

You are hardly the first person ever to suggest TCO for Python:

https://duckduckgo.com/?q=tail+call+optimization+site%3Ahttps%3A%2F%2Fmail.python.org


Unless you have a more convincing argument than the arguments previously made, 
and rejected, this ticket will be closed.

Even though this has been rejected in the past, the door is not quite closed. 
In a couple of weeks, Guido will be replaced as BDFL, and the new governor(s) 
may be more receptive to this idea. But you will probably need to write a PEP.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Christian Tanzer]

Christian Tanzer  added the comment:

Paul Ganssle wrote at Fri, 07 Dec 2018 17:22:36 +:

> > Gregory P. Smith (gregory.p.smith) 2017-03-02 18:57
> > TL;DR - Just one more example of why nobody should *ever* use pickle
> > under any circumstances.  It is useless for data that is not transient
> > for consumption by the same exact versions of all software that
> > created it.
>
> This *is* something that users can work around by not abusing pickle
> in this way and instead using a proper cross-platform serialization
> format. I realize that that makes it *more difficult* for some people
> to do so, but as Gregory points out, these people are doing dangerous
> stuff that will break in a way that we are not going to be willing or
> able to fix at some point *anyway*.

This is completely and utterly wrong, to put it mildly.

The official documentation of the pickle module states (I checked 2.7
and 3.7):

The pickle serialization format is guaranteed to be backwards
compatible across Python releases.

Considering that this issue is 4.5 years old, one would assume that the
pickle documentation would have been changed in the meantime if
Gregory's and Paul's view matched reality.

But my or your personal views about the usability of pickle don't
matter anyway. There are too many libraries and applications that have
been using pickle for many years.

I personally know about this kind of usage in applications since 1998.
In that particular case, the pickled information resides on machines
owned by the customers of the applications and **must** be readable by
any new version of the application no matter how old the file
containing the pickle is. Rewriting history by some Python developers
is not going to impress the companies involved!

Have a nice day!

--

___
Python tracker 

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

[issue35443] Add Tail Call Optimization

[Muhammed Alkan]

New submission from Muhammed Alkan :

I see nothing wrong with adding Tail Call Optimization to Python.

--
messages: 331420
nosy: midnio
priority: normal
severity: normal
status: open
title: Add Tail Call Optimization
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue35257] Avoid leaking linker flags into distutils.

[Ned Deily]

Ned Deily  added the comment:

Unfortunately, it appears this won't be resolved in time for 3.7.2rc1 and 
3.6.8rc1 and it would not be appropriate to merge something this potentially 
disruptive without prior exposure.  Since 3.6.8 is planned to be the final 
3.6.x bugfix release, unless some critical problem is discovered prior to their 
final releases it's likely this will not be fixed for 3.6.

--
nosy: +ned.deily
priority: normal -> critical

___
Python tracker 

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

[issue31354] Fixing a bug related to LTO only build

[Ned Deily]

Ned Deily  added the comment:

OK, I think we are in better shape for 3.6.8 now.  I've merged the backports to 
3.6 of Issue28015 / PR 9908 (LTO with clang) and Issue35351 / PR 10797 (prevent 
LTO CFLAGS leakage into distutils).  So, at the moment, master, 3.7, and 3.6 
should behave the same in this area, although I'm a little bit leery of having 
all this backporting just before 3.6 stops accepting bugfixes.  As far as I can 
tell, what remains is resolving Issue35257 (prevent LTO LDFLAGS leakage into 
distutils).

>Side note on your comment: The compiler used (CC) also seems to leak
>into distutils instead of the system default CC, on linux with
>'python3 setup.py build'.

Yes, it does by design as do many other of the common build Makefile / 
environment variables.  The point I was trying to make applies more to binary 
distributions of Python, like with the python.org macOS installer.  In cases 
like that, the binary distribution is designed to install and run on multiple 
OS versions and that means that the compiler, and OS version for that matter, 
used to build the python executable and standard library extension modules are 
often very different from those on the end user's system when building 
third-party extension modules.

--
priority: release blocker -> normal
resolution:  -> fixed
stage: needs patch -> 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

[issue35351] LTOFLAGS are passed to BASECFLAGS when using LTO

[Ned Deily]

Ned Deily  added the comment:

See also Issue28015, Issue31354, and Issue35257.

--
nosy: +ned.deily
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

___
Python tracker 

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

[issue35351] LTOFLAGS are passed to BASECFLAGS when using LTO

[miss-islington]

miss-islington  added the comment:


New changeset f2d2cb12f2d3bd68a13c4098311e725f776768ad by Miss Islington (bot) 
in branch '3.6':
bpo-35351: Pass link time optimization flags to CFLAGS_NODIST (GH-10797)
https://github.com/python/cpython/commit/f2d2cb12f2d3bd68a13c4098311e725f776768ad


--

___
Python tracker 

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

[issue35351] LTOFLAGS are passed to BASECFLAGS when using LTO

[miss-islington]

Change by miss-islington :


--
pull_requests: +10282

___
Python tracker 

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

[issue28015] configure --with-lto builds fail when CC=clang on Linux, requires gold linker

[Ned Deily]

Ned Deily  added the comment:

See also Issue31354, Issue35351, and Issue35257.

--
versions: +Python 3.6

___
Python tracker 

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

[issue28015] configure --with-lto builds fail when CC=clang on Linux, requires gold linker

[Ned Deily]

Ned Deily  added the comment:


New changeset f83ee476d48dbeb90ddf3526b04936a49a87973a by Ned Deily (stratakis) 
in branch '3.6':
bpo-28015: Support LTO build with clang (GH-9908) (GH-10922)
https://github.com/python/cpython/commit/f83ee476d48dbeb90ddf3526b04936a49a87973a


--
nosy: +ned.deily

___
Python tracker 

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