[issue35101] inspect.findsource breaks on class frame objects

[Aivar Annamaa]

Change by Aivar Annamaa :


--
nosy: +Aivar.Annamaa

___
Python tracker 

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

[issue34766] BaseProxy cache should be cleaned when Manager client is reconnected

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +davin, pitrou

___
Python tracker 

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

[issue35826] Typo in example for async with statement with condition

[Kevin Mai-Hsuan Chia]

Change by Kevin Mai-Hsuan Chia :


--
keywords: +patch, patch, patch, patch
pull_requests: +11511, 11512, 11513, 11514
stage:  -> patch review

___
Python tracker 

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

[issue35826] Typo in example for async with statement with condition

[Kevin Mai-Hsuan Chia]

Change by Kevin Mai-Hsuan Chia :


--
keywords: +patch, patch, patch
pull_requests: +11511, 11512, 11514
stage:  -> patch review

___
Python tracker 

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

[issue35826] Typo in example for async with statement with condition

[Kevin Mai-Hsuan Chia]

Change by Kevin Mai-Hsuan Chia :


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

___
Python tracker 

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

[issue35826] Typo in example for async with statement with condition

[Kevin Mai-Hsuan Chia]

Change by Kevin Mai-Hsuan Chia :


--
keywords: +patch, patch
pull_requests: +11511, 11512
stage:  -> patch review

___
Python tracker 

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

[issue35045] test_min_max_version (test.test_ssl.ContextTests) fails on Fedora 29+ and openssl 1.1.1

[Alan Huang]

Change by Alan Huang :


--
pull_requests: +11509, 11510

___
Python tracker 

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

[issue35045] test_min_max_version (test.test_ssl.ContextTests) fails on Fedora 29+ and openssl 1.1.1

[Alan Huang]

Change by Alan Huang :


--
pull_requests: +11509

___
Python tracker 

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

[issue35831] Format Spec example says limited to 3.1+ but works in 2.7

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

The 3.X docs generally don't refer to the 2.X series.

What that comment is pointing out is that leaving the field identifier out (the 
number inside the {...} placeholder syntax) was not in the 3.0, but added in 
3.1.

Unfortunately, I don't have a 3.0 interpreter available to show the exception 
that's raised.

No change is required.

--
nosy: +fdrake
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

[issue35831] Format Spec example says limited to 3.1+ but works in 2.7

[Mitchell L Model]

Change by Mitchell L Model :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python

___
Python tracker 

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

[issue35831] Format Spec example says limited to 3.1+ but works in 2.7

[Mitchell L Model]

New submission from Mitchell L Model :

https://docs.python.org/3/library/string.html#format-examples includes this 
line:

'{}, {}, {}'.format('a', 'b', 'c')  # 3.1+ only

This does in fact work in 2.7. I don't see anything special about this -- seems 
an entirely straightforward format.

--
messages: 334385
nosy: mlm
priority: normal
severity: normal
status: open
title: Format Spec example says limited to 3.1+ but works in 2.7
versions: 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

[issue35830] building multiple (binary) packages from a single project

[Éric Araujo]

Éric Araujo  added the comment:

The way to achieve this is to make sure your two components live in two 
separate directories, each with its setup.py.

This is the simple way that works with distutils/setuptools and pip 
install-from-vcs (you can install from a subdir of a repo).

--

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[Steve Dower]

Change by Steve Dower :


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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[Steve Dower]

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

[issue35830] building multiple (binary) packages from a single project

[Stefan Seefeld]

Stefan Seefeld  added the comment:

Yes. Depending on the answer to my question(s), the request either becomes: 
"please add support for this use-case", or "this use-case isn't documented 
properly", i.e. a feature request or a bug report. You choose. :-)

--

___
Python tracker 

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

[issue35830] building multiple (binary) packages from a single project

[Steven D'Aprano]

Steven D'Aprano  added the comment:

This is a bug tracker for reporting bugs and enhancement requests, not a help 
desk.

Do you have a *specific* feature request or a bug to report? If not, you should 
ask this on a community forum such as Stackoverflow, Reddit's r/learnpython, 
the Python-list mailing list or the Python IRC channel.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue35830] building multiple (binary) packages from a single project

[Stefan Seefeld]

New submission from Stefan Seefeld :

I'm working on a project that I'd like to split into multiple separately 
installable components. The main component is a command-line tool without any 
external dependencies. Another component is a GUI frontend that adds some 
third-party dependencies.
Therefore, I'd like to distribute the code in a single source package, but 
separate binary packages (so users can install only what they actually need).

I couldn't find any obvious way to support such a scenario with either 
`distutils` nor `setuptools`. Is there an easy solution to this ? (I'm 
currently thinking of adding two `setup()` calls to my `setup.py` script. That 
would then call all commands twice, so I'd need to override the `sdist` command 
to only build a single (joint) source package.
Is there a better way to achieve what I want ?

--
assignee: docs@python
components: Distutils, Documentation
messages: 334381
nosy: docs@python, dstufft, eric.araujo, stefan
priority: normal
severity: normal
status: open
title: building multiple (binary) packages from a single project
type: behavior

___
Python tracker 

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

[issue34691] _contextvars missing in xmaster branch Windows build?

[Carol Willing]

Change by Carol Willing :


--
nosy: +willingc

___
Python tracker 

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

[issue35826] Typo in example for async with statement with condition

[Carol Willing]

Change by Carol Willing :


--
nosy: +willingc

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[miss-islington]

miss-islington  added the comment:


New changeset a6a8524bb1c78c7425346ec20ecffc02d1d02a79 by Miss Islington (bot) 
in branch '3.7':
bpo-35811: Avoid propagating venv settings when launching via py.exe (GH-11677)
https://github.com/python/cpython/commit/a6a8524bb1c78c7425346ec20ecffc02d1d02a79


--
nosy: +miss-islington

___
Python tracker 

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

[issue35656] More matchers in unittest.mock

[Yash Aggarwal]

Yash Aggarwal  added the comment:

> due to floating-point inexactness
+1 Its not easy to predict when calculated value will not be equal to expected 
theoretical value. for example math.cos(radians(90)) is something like 6e-17 
rather than 0.
Testing for this exact value would be just awkward.
assertAlmostEqual() is already there in unittest for such comparisons so it 
wouldn't be completely nonsensical to have something like APPROX

--

___
Python tracker 

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

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

[rdb]

rdb  added the comment:

> > From a cursory glance at the RFC3339 spec it looks like the only other 
> > change needed to fully support RFC3339 would be to support an arbitrary 
> > number of sub-second digits, whereas fromisoformat() currently requires 
> > either exactly 3 or 6.
>
> There are other differences, for example a comma can be used in place of a 
> dot as the delimiter for fractional seconds. Looking at the grammar in the 
> RFC, it seems that it might also support datetimes like 2018-W03-D4, but I 
> don't see any mention of that in the text.

I think you're looking at the appendix, which collects the ABNF from
ISO 8601, but this is not part of RFC3339.  The grammar for RFC3339 is
purposefully very restrictive to make parsing it simple.  The comma
for delimiter is in though, good catch; also a trivial change.

> > So, I can bundle this together with a change making it more lenient about 
> > the number of decimal places for seconds, and we can change the docs for 
> > `fromisoformat()` to be "it accepts any RFC3339 timestamp, including those 
> > generated by isoformat()".
>
> No, because the isoformat outputs are not a subset of RFC 3339. For example, 
> 2015-01-01T00:00:00 is not a valid RFC 3339 datetime string, nor is 
> 2015-01-01Q00:00:00, but they are valid outputs of datetime.isoformat(). 
> datetime.fromisoformat() also supports fractional seconds on time zone 
> offsets, which is not part of ISO 8601.

Fair enough (though I'd say "isoformat()" is a misnomer then).  I was
just going by your option #2.  We would change the wording to imply
"supports RFC 3339 or anything produced by isoformat()"

>
> > Because what I'm trying to use it for technically falls outside the 
> > intended use, I say it would make the most sense to expand the intended use 
> > a bit.
>
> Is there a reason you can't use `dateutil.parser.isoparse`? The contract of 
> that function is to parse any valid ISO8601 datetime, and fromisoformat is 
> adapted from it.

It seems a little odd to need to pull in a third-party library for
this; it seems far more tempting for me to just do
"datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I
know my dates are produced by a JSON API.

I don't intend to get argumentative about whether supporting RFC3339
belongs in the standard library; that is clearly a decision for the
Python maintainers, and I'm not sure what criteria they follow on
this.  I just find it odd to point people to a third-party library for
parsing a simple but ubiquitous date standard when there are many
modules in the standard library for far more specific use cases.

FWIW, I do think that fromisoformat() is the right function to provide
RFC3339 support.  I don't think users would benefit from having to
choose between several different functions that parse similar but
subtly different date formats; this seems likely to cause confusion.

Thanks for your consideration!

--

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[miss-islington]

miss-islington  added the comment:


New changeset 6a9c0fca3f2f93681468b51929472f4433753f25 by Miss Islington (bot) 
in branch '3.7':
bpo-35797: Fix default executable used by the multiprocessing module (GH-11676)
https://github.com/python/cpython/commit/6a9c0fca3f2f93681468b51929472f4433753f25


--
nosy: +miss-islington

___
Python tracker 

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

[issue35826] Typo in example for async with statement with condition

[Yury Selivanov]

Yury Selivanov  added the comment:

Please submit a PR!

--
components: +asyncio -Documentation
keywords: +easy
nosy: +asvetlov, yselivanov

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[Steve Dower]

Steve Dower  added the comment:

I realised while doing the fix that changing sys.executable to point to the 
"real" python.exe would break scenarios that involve generating scripts. All of 
those have been relying on sys.executable launching the venv, which would break 
if we changed it there.

Instead, we now just load the direct executable name in multiprocessing as I 
posted earlier when we detect that __PYVENV_LAUNCHER__ was set on Windows. 
Having a "sys.base_executable" property might have been valuable here, but as 
we don't need it for all platforms I just used the _winapi module.

--

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[miss-islington]

Change by miss-islington :


--
pull_requests: +11503, 11504, 11505

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[miss-islington]

Change by miss-islington :


--
pull_requests: +11506, 11507, 11508

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[miss-islington]

Change by miss-islington :


--
pull_requests: +11503

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[miss-islington]

Change by miss-islington :


--
pull_requests: +11506

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[Steve Dower]

Steve Dower  added the comment:


New changeset 4e02f8f8b4baab63f927cfd87b401200ba2969e9 by Steve Dower in branch 
'master':
bpo-35797: Fix default executable used by the multiprocessing module (GH-11676)
https://github.com/python/cpython/commit/4e02f8f8b4baab63f927cfd87b401200ba2969e9


--

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[miss-islington]

Change by miss-islington :


--
pull_requests: +11506, 11507

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[Steve Dower]

Steve Dower  added the comment:


New changeset adad9e68013aac166c84ffe4e23f3a5464f41840 by Steve Dower in branch 
'master':
bpo-35811: Avoid propagating venv settings when launching via py.exe (GH-11677)
https://github.com/python/cpython/commit/adad9e68013aac166c84ffe4e23f3a5464f41840


--

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[miss-islington]

Change by miss-islington :


--
pull_requests: +11503, 11504

___
Python tracker 

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

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

[Paul Ganssle]

Paul Ganssle  added the comment:

>  I can see your point in not causing confusion about what this method is 
> meant to be used for.

In this case, making it easy to explain what it does is less important than 
making the scope and contract of the function clear so that we don't have to 
argue about what should and should not be supported. Having a narrowly-scoped 
function is also useful for other reasons:

1. The API is clearer - there are no options to configure on this function, if 
you start supporting a bunch of features, people will inevitably want to turn 
some of them *off*, because they only want to accept a subset of the valid 
inputs.

2. The interface to test is clear - we can exhaustively test the entire 
contract of the function if desired.

3. Development will not get stalled in decision-making about which features to 
support or how they might interfere with one another.

> From a cursory glance at the RFC3339 spec it looks like the only other change 
> needed to fully support RFC3339 would be to support an arbitrary number of 
> sub-second digits, whereas fromisoformat() currently requires either exactly 
> 3 or 6.

There are other differences, for example a comma can be used in place of a dot 
as the delimiter for fractional seconds. Looking at the grammar in the RFC, it 
seems that it might also support datetimes like 2018-W03-D4, but I don't see 
any mention of that in the text.

> So, I can bundle this together with a change making it more lenient about the 
> number of decimal places for seconds, and we can change the docs for 
> `fromisoformat()` to be "it accepts any RFC3339 timestamp, including those 
> generated by isoformat()".

No, because the isoformat outputs are not a subset of RFC 3339. For example, 
2015-01-01T00:00:00 is not a valid RFC 3339 datetime string, nor is 
2015-01-01Q00:00:00, but they are valid outputs of datetime.isoformat(). 
datetime.fromisoformat() also supports fractional seconds on time zone offsets, 
which is not part of ISO 8601.

> Because what I'm trying to use it for technically falls outside the intended 
> use, I say it would make the most sense to expand the intended use a bit. 

Is there a reason you can't use `dateutil.parser.isoparse`? The contract of 
that function is to parse any valid ISO8601 datetime, and fromisoformat is 
adapted from it.

--

___
Python tracker 

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

[issue35766] Merge typed_ast back into CPython

[Guido van Rossum]

Guido van Rossum  added the comment:

The PR is ready for reviews now.

--

___
Python tracker 

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

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

[rdb]

rdb  added the comment:

I'm a fan of "be lenient in what you accept" but I can see your point in not 
causing confusion about what this method is meant to be used for.

Because what I'm trying to use it for technically falls outside the intended 
use, I say it would make the most sense to expand the intended use a bit.  From 
a cursory glance at the RFC3339 spec it looks like the only other change needed 
to fully support RFC3339 would be to support an arbitrary number of sub-second 
digits, whereas fromisoformat() currently requires either exactly 3 or 6.

So, I can bundle this together with a change making it more lenient about the 
number of decimal places for seconds, and we can change the docs for 
`fromisoformat()` to be "it accepts any RFC3339 timestamp, including those 
generated by isoformat()".

Does this seem acceptable?  We can always expand further to allow any ISO 8601 
timestamp later, but RFC3339 would already make this function immensely more 
useful.  I really think that parsing RFC3339 dates is a feature Python needs to 
have in the standard library given their ubiquity on the web.

Alternatively I am happy to consider adding something like a utc=True flag to 
isoformat(), but I would personally feel reluctant to add any features that I 
can't think of a solid use case for.

--

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[Matej Cepl]

Matej Cepl  added the comment:

> Will this change be backported to 3.5 and 3.4? It applied cleanly on both 
> however on 3.4 there is a test failure:

It actually haven't applied cleanly to me on Python 3.4.6 (SLE-12 package). 
Apparently self->parser has to be changed into self_xp->parser. Then all tests 
passed for me.

If any Linux maintainer wants to take this patch.

--
nosy: +mcepl
Added file: 
https://bugs.python.org/file48077/CVE-2018-14647_XML_SetHashSalt-in_elementtree.patch

___
Python tracker 

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

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

[Paul Ganssle]

Paul Ganssle  added the comment:

You can see the discussion in bpo-15873 for the full rationale of why "Z" was 
omitted - to quote from https://bugs.python.org/issue15873#msg307607 :

> We can have further discussion later about what exactly should be supported 
> in Python 3.8,
> but even in the pre-release discussions I'm already seeing pushback about 
> some of the more
> unusual 8601 formats, and it's a *lot* easier to explain (in documentation) 
> that `fromisoformat()`
> is intended to be the inverse of `isoformat()` than it is to explain which 
> variations of ISO 8601
> are and are not supported (fractional minutes? if you're following the 
> standard, the separator has
> to be a T, so what other variations of the standard are allowed?)

With the current implementation, the contract of the function is very simple to 
explain: datetime.fromisoformat() is the inverse operation of 
datetime.isoformat(), which is to say that every valid input to 
datetime.fromisoformat() is a possible output of datetime.isoformat(), and 
every possible output of datetime.isoformat() is a valid input to 
datetime.fromisoformat().

With that as the background - fromisoformat() was designed to be a conservative 
API because scope is a one-way ratchet, and it's better to under-commit than 
over-commit. We do have the option going forward of widening the scope of the 
function in a backwards-compatible way. The main problem I see is that I think 
we should maintain the property that it should be dead simple to explain what a 
function does, and having to enumerate edge cases is a code smell. So "it is 
the inverse operation of fromisoformat(), but it also supports specifying using 
Z for UTC" fails that test in my opinion.

I see a few rational choices here:

1. Supports the full ISO 8601 datetime spec and all outputs from 
datetime.isoformat() (these inputs mostly but not completely overlap). We would 
then just have to decide on a simple policy for how to deal with the optional 
portions of the spec.

2. Support only the rfc3339 standard + the outputs of datetime.isoformat(), 
with the option to switch to #1 later.

3. Add the ability for `datetime.isoformat()` to output 'Z' instead of `00:00`, 
which would allow us to support it as an input and also keep the scope of 
`datetime.fromisoformat` unchanged.

4. Add a separate function (either a classmethod or a bare function) for 
parsing exactly the ISO 8601 standard, maybe `parse_iso8601`, so both 
`parse_iso8601` and `fromisoformat` have a clean, rational explanation for what 
they do.

5. Leave the current scope alone and don't add anything.

5a. Leave the current scope alone and point people in the direction of 
`dateutil.parser.isoparse` in the documentation.

--

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch, patch, patch
pull_requests: +11500, 11501, 11502
stage: test needed -> patch review

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +11500
stage: test needed -> patch review

___
Python tracker 

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

[issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment variable

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch, patch
pull_requests: +11500, 11501
stage: test needed -> patch review

___
Python tracker 

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

[issue35825] Py_UNICODE_SIZE=4 fails to link on Windows

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I think this falls in the category of "don't do that", because Windows does not 
support wide builds.  If so, this issue should be closed as 'not a bug'.  If 
not, some Windows expert should enlighten me.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue35798] duplicate SyntaxWarning: "is" with a literal

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I verified that master on Windows (which requires " instead of ')
> python -c "if object() is 42: pass"
results in the doubled messsage, and that after applying PR 11639 and 
recompiling, there is only 1 message.

We should test that exactly 1 warning is emitted.  The following fails on 
master and passes with the parch:

import unittest, warnings

class SyntaxWarningTest(unittest.TestCase):
def test_syntax_warning_once(self):
with warnings.catch_warnings(record=True) as w:
warnings.simplefilter("always")
compile('if object() is 42: pass\n', '', 'single')
self.assertEqual(len(w), 1)  # Not 2, see issue 35798

if __name__ == '__main__':
unittest.main()

The original patch added test_comparison_is_literal() in test_grammar.  The 
'with' block above could be added at the end.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch, patch, patch
pull_requests: +11497, 11498, 11499
stage: test needed -> patch review

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch, patch
pull_requests: +11497, 11498
stage: test needed -> patch review

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +11497
stage: test needed -> patch review

___
Python tracker 

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

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +belopolsky, p-ganssle

___
Python tracker 

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

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

[rdb]

New submission from rdb :

The fromisoformat() function added in 3.7 is a very welcome addition.  But one 
quite noticeable absence was the inability to parse Z instead of +00:00 as the 
timezone suffix.

Its absence is particularly noticeable given how ubiquitous use of Z is in ISO 
8601 timestamps on the web; it is also part of the RFC 3339 subset.  In 
particular, JavaScript produces it in its canonical ISO 8601 format and is 
therefore quite common in JSON APIs; this would be the only piece missing to 
parse ISO dates produced by JavaScript correctly.

I realise that the function was not intended to be able to parse *all* 
timestamps.  But given the triviality of this change, the ubiquity of this 
particular formatting feature, and the fact that this change is designed in 
particular for operability with the widely-used JavaScript date format, I don't 
think this is a slippery slope, and I would personally see no harm in accepting 
a 'Z' instead of a timezone.

I am happy to follow up with a patch for this, but would first like 
confirmation that there is any chance that such a change would be accepted.  
Thanks for your consideration!

--
components: Library (Lib)
messages: 334365
nosy: rdb
priority: normal
severity: normal
status: open
title: datetime: parse "Z" timezone suffix in fromisoformat()
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

[issue35782] Missing whitespace after comma in randrange raise error

[Terry J. Reedy]

Terry J. Reedy  added the comment:

We usually don't backport exception message changes, for the reason given, 
unless the content is wrong or misleading.  Unless Raymond says otherwise, I 
think the backport should be closed as too trivial and this issue closed as 
fixed.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue35808] Let's retire pgen

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 

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

[issue35815] Able to instantiate a subclass with abstract methods from __init_subclass__ of the ABC

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +rhettinger, stutzbach

___
Python tracker 

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

[issue35800] remove smtpd.MailmanProxy

[Samuel Colvin]

Change by Samuel Colvin :


--
keywords: +patch, patch, patch
pull_requests: +11494, 11495, 11496
stage:  -> patch review

___
Python tracker 

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

[issue35800] remove smtpd.MailmanProxy

[Samuel Colvin]

Change by Samuel Colvin :


--
keywords: +patch, patch
pull_requests: +11494, 11495
stage:  -> patch review

___
Python tracker 

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

[issue35800] remove smtpd.MailmanProxy

[Samuel Colvin]

Change by Samuel Colvin :


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

___
Python tracker 

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

[issue35823] Use vfork() in subprocess on Linux

[Ronald Oussoren]

Ronald Oussoren  added the comment:

BTW. I hadn't noticed _close_open_fds_safe, that should be safe when using 
vfork(). 

Finally: I have no strong opinion on this patch, your explanation looks fine 
and I'm not up-to-speed w.r.t. implementation details of vfork and the like to 
feel comfortable about giving a proper review without spending a lot more time 
on it.

--

___
Python tracker 

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

[issue35707] time.sleep() should support objects with __float__

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
components: +Interpreter Core

___
Python tracker 

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

[issue35821] Clarify when logging events are propagated when propagate is true

[Chris Jerdonek]

Chris Jerdonek  added the comment:

I'm not sure which part of what I wrote you think is inaccurate. All of what 
you wrote matches what I was trying to convey.

For example, my saying "pass to the parent logger" corresponds to the "set 
current logger to parent" box in the diagram. And by "handled by the parent 
logger's handlers" I meant "directly offered to any handlers attached to 
ancestor loggers." And "only the propagate attribute determines whether the 
event is passed" matches your "until a logger is encountered where propagate is 
false."

--

___
Python tracker 

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

[issue35823] Use vfork() in subprocess on Linux

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11492, 11493

___
Python tracker 

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

[issue35823] Use vfork() in subprocess on Linux

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11492

___
Python tracker 

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

[issue30548] typo in documentation for create_autospec

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Mario is right that this isn't a typo.  Here's a code example to illustrate 
what he said:

>>> class MyClass:
... a = 3
... def foo(self): pass
...
>>> mock_class = create_autospec(MyClass)
>>> mock_class

>>> mock_class()

>>> mock_class.foo


>>> mock_instance = create_autospec(MyClass, instance=True)
>>> mock_instance

>>> mock_instance()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'NonCallableMagicMock' object is not callable
>>> mock_instance.foo


As per the docs, the instance object uses the class as the spec and it isn't 
callable, whereas the mock class is.  Would adding this example to the docs 
help or would a different code example help make this less misleading?

--
nosy: +cheryl.sabella

___
Python tracker 

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

[issue35821] Clarify when logging events are propagated when propagate is true

[Vinay Sajip]

Vinay Sajip  added the comment:

That isn't quite accurate. A logger's attached handlers will always be offered 
a chance to handle an event if the logger's level and filters allow. However, 
the event is not actually passed to ancestor loggers - it is directly offered 
to any handlers attached to ancestor loggers, until a logger is encountered 
where propagate is false - and that is the last logger whose handlers are 
offered the event. All handlers have their own levels and filters and may or 
may not process an event according to those levels and filters.

--

___
Python tracker 

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

[issue35828] test_multiprocessing_* tests - success versus fail varies over time

[Michael Felt]

New submission from Michael Felt :

Last August I started running a bot for AIX using xlc_r as the compiler, rather 
than gcc that the other AIX bot uses.

Initially, I had no issues with the test_multiprocess* tests, but of late (last 
two+ months I am guessing) I have been having regular issues when the bot 
builds, but not when I would run the tests (all 418) or individually - when run 
manually.

The last two weeks I have invested time - and have been repaid - in that I can 
now get a regular failure when running the tests.

Your assistance is appreciated. I'll continue to work on this when I have time.


Short version:

This looks like there is a statement "crafted" to cause a crash:
(dbx) where
PyDict_GetItem(op = 0x2002ddc8, key = 0x30061e68), line 1320 in "dictobject.c"
_PyDict_GetItemId(dp = 0xdbdbdbdb, key = 0xdbdbdbdb), line 3276 in 
"dictobject.c"
...

This is based on bot run that failed (Python 3.8.0a0 (heads/master:0785889468)).

The test message that comes back is:

test_multiprocessing_fork failed
Process Process-94:
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/process.py",
 line 302, in _bootstrap
self.run()
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/process.py",
 line 99, in run
self._target(*self._args, **self._kwargs)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/_test_multiprocessing.py",
 line 2847, in _putter
manager.connect()
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/managers.py",
 line 512, in connect
conn = Client(self._address, authkey=self._authkey)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py",
 line 796, in XmlClient
return ConnectionWrapper(Client(*args, **kwds), _xml_dumps, _xml_loads)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py",
 line 502, in Client
c = SocketClient(address)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py",
 line 629, in SocketClient
s.connect(address)
ConnectionRefusedError: [Errno 79] Connection refused
test test_multiprocessing_fork failed -- Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/_test_multiprocessing.py",
 line 2865, in test_rapid_restart
queue = manager.get_queue()
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/managers.py",
 line 701, in temp
token, exp = self._create(typeid, *args, **kwds)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/managers.py",
 line 584, in _create
conn = self._Client(self._address, authkey=self._authkey)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py",
 line 796, in XmlClient
return ConnectionWrapper(Client(*args, **kwds), _xml_dumps, _xml_loads)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py",
 line 502, in Client
c = SocketClient(address)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py",
 line 629, in SocketClient
s.connect(address)
ConnectionRefusedError: [Errno 79] Connection refused

I had a hard time finding anything - because I was looking for a permission 
issue in the Socket "domain", but what seems more likely is that the "server" 
thread/process is crashing with a segmentation fault and a "client" thread is 
getting "refused" because the server no longer exists and/or never got 
successfully started.

I finally managed to capture a core dump and I hope that this will help you 
help me with getting deeper and closer to a resolution/understanding on what is 
going on.

buildbot@x064:[/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue]area/coredumps/core.12582914.25123239
<
Type 'help' for help.
warning: The core file is not a fullcore. Some info may
not be available.
[using memory image in 
/home/buildbot/buildarea/coredumps/core.12582914.25123239]
reading symbolic information ...

Segmentation fault in PyDict_GetItem at line 1320 in file "Objects/dictobject.c"
 1320   if (!PyDict_Check(op))
(dbx) where
PyDict_GetItem(op = 0x2002ddc8, key = 0x30061e68), line 1320 in "dictobject.c"

>From other data about the program I expect the segmentation error is caused by 
>the key value. Unless the program has done a mmap/shmap request for memory 
>allocation (something not done by default) the address 0x3000-0x3fff 
>is not a valid address.

Summary:

This looks like there is a statement "crafted" to cause a crash:
(dbx) where
PyDict_GetItem(op = 0x2002ddc8, key = 0x30061e68), line 1320 in "dictobject.c"
_PyDict_GetItemId(dp = 0xdbdbdbdb, key = 0xdbdbdbdb), line 3276 in 
"dictobject.c"
...

Gory details:

[issue35224] PEP 572: Assignment Expressions

[STINNER Victor]

STINNER Victor  added the comment:

Note: I checked and 3.x buildbots are back to green (ignoring the ones which 
already failed previously). Good.

--

___
Python tracker 

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

[issue34134] multiprocessing memory huge usage

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This is basically fixed, except that I'll let the Release Manager choose 
whether 3.6 gets the fix as well. Thanks!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue34134] multiprocessing memory huge usage

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset c2674bf11036af1e06c1be739f0eebcc72dfbf7a by Antoine Pitrou (Miss 
Islington (bot)) in branch '3.7':
bpo-34134: Advise to use imap or imap_unordered when handling long iterables. 
(gh-8324) (gh-11673)
https://github.com/python/cpython/commit/c2674bf11036af1e06c1be739f0eebcc72dfbf7a


--

___
Python tracker 

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

[issue35827] C API dictionary views type checkers are not documented

[Ori Avtalion]

New submission from Ori Avtalion :

dictobject.h defines several helpers to ease checking of dictionary view types. 
If they are meant to be part of the API, they should be documented.

PyDictKeys_Check
PyDictItems_Check
PyDictValues_Check
PyDictViewSet_Check

Should they be added to dict.rst, or a separate file?

--
assignee: docs@python
components: Documentation
messages: 334355
nosy: docs@python, salty-horse
priority: normal
severity: normal
status: open
title: C API dictionary views type checkers are not documented
type: enhancement
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

[issue34134] multiprocessing memory huge usage

[miss-islington]

Change by miss-islington :


--
pull_requests: +11489, 11490, 11491

___
Python tracker 

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

[issue34134] multiprocessing memory huge usage

[miss-islington]

Change by miss-islington :


--
pull_requests: +11489, 11490

___
Python tracker 

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

[issue34134] multiprocessing memory huge usage

[miss-islington]

Change by miss-islington :


--
pull_requests: +11489

___
Python tracker 

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

[issue34134] multiprocessing memory huge usage

[miss-islington]

Change by miss-islington :


--
pull_requests: +11487, 11488

___
Python tracker 

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

[issue34134] multiprocessing memory huge usage

[miss-islington]

Change by miss-islington :


--
pull_requests: +11487

___
Python tracker 

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

[issue34134] multiprocessing memory huge usage

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 3bab40db96efda2e127ef84e6501fda0cdc4f5b8 by Antoine Pitrou 
(Windson yang) in branch 'master':
bpo-34134: Advise to use imap or imap_unordered when handling long iterables. 
(gh-8324)
https://github.com/python/cpython/commit/3bab40db96efda2e127ef84e6501fda0cdc4f5b8


--

___
Python tracker 

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

[issue35823] Use vfork() in subprocess on Linux

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

> W.r.t. closing all file descriptors > 2: posix_spawn_file_actions_addclose 
> can do this when using posix_spawn. That would have a performance cost, you'd 
> basically have to resort to closing all possible file descriptors and cannot 
> use the smarter logic used in _posixsubprocess.

This is costly to the point of people reporting bugs: bpo-35757. If that really 
causes 0.1s delay like the reporter said, it would defeat the purpose of using 
posix_spawn() in the first place.

> However, the smarter closing code in _posixsubprocess is not safe w.r.t. 
> vfork according to the comment above _close_open_fds_maybe_unsafe: that 
> function uses some functions that aren't async-safe and one of those calls 
> malloc.

No, it's not so on Linux: 
https://github.com/python/cpython/blob/62c35a8a8ff5854ed470b1c16a7a14f3bb80368c/Modules/_posixsubprocess.c#L314

Moreover, as I already argued in msg332235, using malloc() after vfork() should 
be *safer* than after fork() for a simple reason: all memory-based locks will 
still work as though the child is merely a thread in the parent process. This 
is true even for things like futex(FUTEX_WAKE_PRIVATE), despite that this 
operation is mistakenly documented as "process-private" in man pages. It's 
actually more like "private to tasks sharing the same address space".

This is in contrast with fork(): if it's called while another thread is holding 
some mutex in malloc(), nobody would unlock it in the child unless the C 
library has precautions against that.

--

___
Python tracker 

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

[issue35823] Use vfork() in subprocess on Linux

[Kubilay Kocak]

Change by Kubilay Kocak :


--
nosy: +koobs

___
Python tracker 

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

[issue31171] multiprocessing.BoundedSemaphore of 32-bit python could not work while cross compiling on linux platform

[Barry Davis]

Barry Davis  added the comment:

The behaviour I saw (32-bit only) was a python process getting stuck.

I got this from strace:
...
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily 
unavailable)
...

And this from gdb:
(gdb) bt
#0  0xb76fbc5d in __kernel_vsyscall ()
#1  0xb74af2a4 in sem_wait () from /lib/libpthread.so.0
#2  0xb69a5429 in ?? () from /usr/lib/python2.7/lib-dynload/_multiprocessing.so
#3  0xb75a262e in call_function (oparg=, pp_stack=0xbfb7f038) at 
Python/ceval.c:4033
#4  PyEval_EvalFrameEx (f=, throwflag=) at 
Python/ceval.c:2679
#5  0xb75a2f7d in PyEval_EvalCodeEx (co=, globals=
{'Queue': , 'atexit': , 'Semaphore': , 'Empty': , 'Full': , 'SimpleQueue': , 'assert_spawning': , 
'__all__': ['Queue', 'SimpleQueue', 'JoinableQueue'], '_multiprocessing': 
, '_sentinel': , 
'__package__': 'multiprocessing', 'collections': , 
'__doc__': None, 'Condition': , 'JoinableQueue': 
, '__builtins__': {'bytearray': , 'IndexError': , 'all': , 'help': <_Helper at remote 0xb71f824c>, 'vars': , 'SyntaxError': , 'unicode': , 'UnicodeDecodeError': , 
'memoryview': , 'isinstance...(truncated), locals=0x0, args=0xb535f5cc, 
argcount=2, kws=0xb535f5d4, kwcount=0, defs=0xb69b6058, defcount=2, 
closure=0x0) at Python/ceval.c:3265
#6  0xb75a0f3d in fast_function (nk=0, na=, n=2, 
pp_stack=0xbfb7f178, func=) at 
Python/ceval.c:4129
#7  call_function (oparg=, pp_stack=0xbfb7f178) at 
Python/ceval.c:4054
#8  PyEval_EvalFrameEx (f=, throwflag=) at 
Python/ceval.c:2679
...
(gdb) py-bt
#4 Frame 0xb536602c, for file /usr/lib/python2.7/multiprocessing/queues.py, 
line 101, in put (self=, _recv=, _thread=None, _sem=, 
acquire=, _semlock=<_multiprocessing.SemLock at remote 0xb53427c0>) at 
remote 0xb53425cc>, _buffer=, 
_closed=False, _send=, _jointhread=None, _reader=None, _opid=3752, 
_rlock=, acquire=, 
_semlock=<_multiprocessing.SemLock at remote 0xb53424
 20>) at remote 0xb534240c>, _...(truncated)
...

--

___
Python tracker 

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

[issue31171] multiprocessing.BoundedSemaphore of 32-bit python could not work while cross compiling on linux platform

[Barry Davis]

Barry Davis  added the comment:

I've just hit this issue using Python-2.7.9, gcc-8.1.0, glibc-2.23.

The patch I made to fix the issue based on comments in this issue:

--- Python-2.7.9/setup.py   2019-01-25 09:30:39.049501423 +
+++ Python-2.7.9/setup.py   2019-01-25 09:30:55.369609646 +
@@ -1670,7 +1670,7 @@

 else:   # Linux and other unices
 macros = dict()
-libraries = ['rt']
+libraries = ['rt', 'pthread']

 if host_platform == 'win32':
 multiprocessing_srcs = [ '_multiprocessing/multiprocessing.c',
@@ -1690,6 +1690,7 @@

 if sysconfig.get_config_var('WITH_THREAD'):
 exts.append ( Extension('_multiprocessing', multiprocessing_srcs,
+libraries = libraries,
 define_macros=macros.items(),
 include_dirs=["Modules/_multiprocessing"]))
 else:

--
nosy: +Barry Davis

___
Python tracker 

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

[issue35826] Typo in example for async with statement with condition

[Kevin Mai-Hsuan Chia]

Kevin Mai-Hsuan Chia  added the comment:

In the 
[example](https://docs.python.org/3.8/library/asyncio-sync.html#asyncio.Condition)
 of the equivalent code to the `async with` statement:
```python
cond = asyncio.Condition()

# ... later
await lock.acquire()
try:
await cond.wait()
finally:
lock.release()
```

`lock.acquire()` should be replaced by `cond.acquire()`, and `lock.release()` 
replaced by `cond.release()`. So the resulting code snippet becomes:

```python
cond = asyncio.Condition()

# ... later
await cond.acquire()
try:
await cond.wait()
finally:
cond.release()
```

--

___
Python tracker 

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

[issue35826] Typo in example for async with statement with condition

[Kevin Mai-Hsuan Chia]

New submission from Kevin Mai-Hsuan Chia :

In the 
[example](https://docs.python.org/3.8/library/asyncio-sync.html#asyncio.Condition)
 of the equivalent code to the `async with statement`:
```python
cond = asyncio.Condition()

# ... later
await lock.acquire()
try:
await cond.wait()
finally:
lock.release()
```

`lock.acquire()` should be replaced by `cond.acquire()`, and `lock.release()` 
replaced by `cond.release()`. So the resulting code snippet becomes:

```python
cond = asyncio.Condition()

# ... later
await cond.acquire()
try:
await cond.wait()
finally:
cond.release()
```

--
assignee: docs@python
components: Documentation
messages: 334349
nosy: docs@python, mhchia
priority: normal
severity: normal
status: open
title: Typo in example for async with statement with condition
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

[issue35825] Py_UNICODE_SIZE=4 fails to link on Windows

[Kristof Niederholtmeyer]

New submission from Kristof Niederholtmeyer 
:

When I change Py_UNICODE_SIZE from 2 (default) to 4 in PC/pyconfig.h, msvc-14 
gives the following error:
  _winreg.obj : error LNK2001: unresolved external symbol PyUnicode_DecodeMBCS 
[e:\kristof\SDR\sdrsandbox\w64\msvc140\Python-2.7.15\PCbuild\pythoncore.vcxproj]
  
e:\kristof\SDR\sdrsandbox\w64\msvc140\Python-2.7.15\PCBuild\\amd64\python27_snps_vp.dll
 : fatal error LNK1120: 1 unresolved externals 
[e:\kristof\SDR\sdrsandbox\w64\msvc140\Python-2.7.15\PCbuild\pythoncore.vcxproj]

The problem appears to be that the missing function gets disabled in 
unicodeobject.c with
#if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T)
...
#endif

while _winreg.c does not check the availability of this function.

Thanks,
Kristof

--
components: Build, Windows
messages: 334348
nosy: kristof, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Py_UNICODE_SIZE=4 fails to link on Windows
type: compile error
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

[issue35810] Object Initialization Bug with Heap-allocated Types

[Stefan Behnel]

Stefan Behnel  added the comment:

It seems right that a heap allocate object owns a reference to its (non-static) 
type. But the mere fact that you had to adapt stdlib code makes it obvious that 
this will also break existing user code out there. And such breakage is very 
likely to remain undetected for a while, since leaking types is unlikely to 
have a big enough memory impact in most application to be easily detected.

This is a tough call. Any ideas for reducing the chance of breakage or 
increasing the chance of detecting it in user code would help.

--
nosy: +scoder

___
Python tracker 

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