[issue32319] re fullmatch error with non greedy modifier

[Daniel Hrisca]

New submission from Daniel Hrisca :

Consider this code snippet:


from re import match, fullmatch

pattern = '".+?"'
string = '"hello" "again"'

print(match(pattern, string))
print(fullmatch(pattern, string))


Which prints:
<_sre.SRE_Match object; span=(0, 7), match='"hello"'>
<_sre.SRE_Match object; span=(0, 15), match='"hello" "again"'>

The fullmatch function seems to ignore the non-greedy modifier.

>From the fullmatch docstring I expected that fullmatch is equivalent to:

def fullmatch(pattern, string):
match = re.match(pattern, string)
if match:
if match.start() == 0 and match.end() == len(string):
return match
else:
return None
else:
return None

--
components: Library (Lib)
messages: 308278
nosy: danielhrisca
priority: normal
severity: normal
status: open
title: re fullmatch error with non greedy modifier
type: behavior
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

[issue29469] AST-level Constant folding

[INADA Naoki]

Change by INADA Naoki :


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

[issue29469] AST-level Constant folding

[INADA Naoki]

INADA Naoki  added the comment:


New changeset 7ea143ae795a9fd57eaccf490d316bdc13ee9065 by INADA Naoki in branch 
'master':
bpo-29469: Move constant folding to AST optimizer (GH-2858)
https://github.com/python/cpython/commit/7ea143ae795a9fd57eaccf490d316bdc13ee9065


--

___
Python tracker 

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

[issue32318] Remove "globals()" call from "socket.accept()"

[STINNER Victor]

STINNER Victor  added the comment:

IMHO we should add a private mask constant, see:
https://github.com/python/cpython/pull/4231#issuecomment-351622381

--

___
Python tracker 

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

[issue32228] truncate() changes current stream position

[Nitish]

Change by Nitish :


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

___
Python tracker 

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

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

[Nathaniel Smith]

Nathaniel Smith  added the comment:

> In any case, in my opinion, it doesn't matter.  `sys.set_coroutine_wrapper` 
> controls a single thread-local setting, 
> `sys.set_unawaited_coroutine_tracking` *also* controls a single thread-local 
> setting.  Both of them have the exact same problem when there's more than one 
> user of the API.  So we can't consider this as a strong argument in favour of 
> the 'set_unawaited_coroutine_tracking' API.
[...]
> With that all in mind, my question is: have you guys tried to write a wrapper 
> object in C for coroutines (or you can use Cython to get an idea)?

This is a fair point; we probably should try that :-).

I do think that there's more of a difference than you're realizing between 
set_coroutine_wrapper and set_unawaited_coroutine_tracking WRT their behavior 
around conflicts.

For set_unawaited_coroutine_tracking, the whole idea that makes it useful is if 
you have a single central piece of code that has a global view of what your 
program is doing, and can use that to figure out specific points where there 
should be no unawaited coroutines, plus has some strategy for reporting errors. 
For pytest-asyncio, it wants to check for these at the end of each test and 
then if found, fail that test. (Oh, I should mention that I did actually talk 
to the pytest-asyncio author about this and they do want to use it, this isn't 
hypothetical :-).) For trio, we have a more subtle rule like "check at each 
schedule point or catch-all exception handler, UNLESS it is in a task that is 
hosting asyncio code through our translation layer", and the reporting is more 
complicated too. But the point I want to make is that here, it's simpliy 
intrinsic in the design that whatever system is doing this has to have some 
pretty solid global knowledge, and it doesn't make sense to have two o
 f these at once; no matter how we implemented this, two libraries trying to 
use it at the same time would necessarily need to coordinate somehow.

OTOH, for set_coroutine_wrapper, it's such a catch-all that it is plausible to 
have two different libraries that both want to use it at the same time, for two 
things that in principle don't conflict at all.

And not only is this plausible, it's what actually happens :-). If everyone 
uses set_coroutine_wrapper, then pytest-asyncio and asyncio will actually 
collide, and trio and asyncio will actually collide. But if we have 
set_unawaited_coroutine_tracking + set_coroutine_wrapper, then that's enough to 
prevent all the actual collisions we know about.

--

___
Python tracker 

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

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

[Yury Selivanov]

Yury Selivanov  added the comment:

> So first... that's not how nursery.start_soon works :-). It actually takes an 
> async function, not a coroutine object. [..]

Interesting, and I think I like it.  I definitely understand the motivation to 
not tell users the difference between coroutine functions and coroutine 
objects, but yeah, the ship has sailed for asyncio/curio/twisted.

Anyways, I'm not saying we shouldn't implement your proposal, even if it is 
only going to be used by Trio.  I'm saying that we need to consider all 
alternatives, and for that, I'd like to see what happens if we implement a 
tiny coro wrapper in Trio.  Maybe the runtime overhead of it will be 
negligible.

--

___
Python tracker 

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

[issue32318] Remove "globals()" call from "socket.accept()"

[Yury Selivanov]

Change by Yury Selivanov :


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

___
Python tracker 

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

[issue32318] Remove "globals()" call from "socket.accept()"

[Yury Selivanov]

New submission from Yury Selivanov :

socket.accept currently has this code:

type = self.type & ~globals().get("SOCK_NONBLOCK", 0)

which I believe is (a) bad Python style; (b) slows things down.

--
components: +Library (Lib)
nosy: +asvetlov, vstinner
type:  -> enhancement
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

[issue32318] Remove "globals()" call from "socket.accept()"

[Yury Selivanov]

Change by Yury Selivanov :


--
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Remove "globals()" call from "socket.accept()"

___
Python tracker 

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

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

[Nathaniel Smith]

Nathaniel Smith  added the comment:

> 1. How will trio handle situations like:
> 
> c = coro()
> await ...
> nursery.start_soon(c)
> 
> ?
[...]
> Maybe creating a coroutine and not immediately passing it to 'start_soon' or 
> similar API is an anti-pattern in Trio, but it is an OK thing to do in 
> asyncio/curio/twisted.

Yeah, for sure. This is sort of core to the overall motivation, so probably a 
good idea to make sure we're on the same page.

So first... that's not how nursery.start_soon works :-). It actually takes an 
async function, not a coroutine object. In fact, if you try doing 
'nursery.start_soon(c)' in trio v0.2.0, you get this error message (code I ran: 
https://gist.github.com/njsmith/87687ba5de1aeb5aa92336bd31891751):

> TypeError: trio was expecting an async function, but instead it got a 
> coroutine object 
> 
> Probably you did something like:
> 
>   trio.run(coro(...))# incorrect!
>   nursery.start_soon(coro(...))  # incorrect!
> 
> Instead, you want (notice the parentheses!):
> 
>   trio.run(coro, ...)# correct!
>   nursery.start_soon(coro, ...)  # correct!

(The 'coro' in my paste above isn't a placeholder, it's the actual name of your 
example async function that trio has interpolated into the error message, 
because I am a dorky perfectionist.)

There's a broader point here beyond showing off my dorkiness.

Trio is very careful to make sure that users don't need to know about the 
existence of coroutine objects *at all*. This is a *huge* win for teaching and 
understanding: I just tell people "async functions are a special class of 
functions; they're defined like 'async def func(): ...', and called like 'await 
func()', and btw you can only use 'await func()' inside an async function." and 
that is literally everything you need to know about async/await to use trio. I 
never use the word coroutine. It's way simpler, with no loss in expressivity, 
and part of why I can teach all of trio in a 30 minute talk and people are like 
"okay cool I know how to write concurrent programs now, why do people make such 
a big deal about it?".

Buuut... that's the happy path. What happens when people make minor syntax 
mistakes? Sometimes, we can catch it -- like the example above, when they 
accidentally write 'nursery.start_soon(func())' -- and give a nice helpful 
message to tell them what to fix, and it's fine. But unawaited coroutines are a 
problem: most people are going to forget an 'await' sooner or later. And when 
the happens, then you get messages like "coroutine was never awaited" or 
"coroutine object has no attribute '...'" which are completely incomprehensible 
if you don't know that there are such things as coroutine objects. (And never 
mind the cases where you don't get an error/warning at all!) So then my users 
are forced to learn a bunch of new concepts and async/await implementation 
details, *just* to understand this one error case.

So basically yeah, I am totally happy to prohibit 'c = coro(); await sleep(0); 
await c' because it's actually the key thing that makes the whole system 
simpler.

Of course the problem is how to do this in a way that works for both trio and 
asyncio :-).

--

___
Python tracker 

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

[issue29877] compileall hangs when accessing urandom even if number of workers is 1

[Dustin Spicuzza]

Change by Dustin Spicuzza :


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

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4744

___
Python tracker 

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

[issue30241] Add contextlib.AbstractAsyncContextManager

[Yury Selivanov]

Change by Yury Selivanov :


--
resolution:  -> fixed
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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b5fd9ad05e0f15f8272b8f1b829af22077230584 by Victor Stinner in 
branch 'master':
bpo-32030: Rewrite _PyMainInterpreterConfig (#4854)
https://github.com/python/cpython/commit/b5fd9ad05e0f15f8272b8f1b829af22077230584


--

___
Python tracker 

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

[issue30241] Add contextlib.AbstractAsyncContextManager

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 176baa326be4ec2dc70ca0c054b7e2ab7ca6a9cf by Yury Selivanov (Jelle 
Zijlstra) in branch 'master':
bpo-30241: implement contextlib.AbstractAsyncContextManager (#1412)
https://github.com/python/cpython/commit/176baa326be4ec2dc70ca0c054b7e2ab7ca6a9cf


--

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4743

___
Python tracker 

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

[issue32317] sys.exc_clear() clears exception in other stack frames

[Garrett Berg]

Garrett Berg  added the comment:

I found a workaround, and probably the reason this has not been detected before:

import sys

def doclear2()
try:
1/0
except ZeroDivisionError:
sys.exc_clear()

try:
1/0
except ZeroDivisionError:
exc = sys.exc_info()[0]
print("third exc (before doclear):", exc)
doclear2()
exc = sys.exc_info()[0]
print("third exc (after  doclear):", exc)
assert sys.exc_info()[0] is ZeroDivisionError

The above passes. It seems that being inside a local exception block allows for 
the spec to hold, only the "local exception" is cleared.

I still think this is a pretty major bug, but it is good to know what the 
workaround/reason it's "been working" is.

--

___
Python tracker 

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

[issue32316] [3.6] make regen-all fails on Travis CI on "python3.6" command

[STINNER Victor]

Change by STINNER Victor :


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

[issue32316] [3.6] make regen-all fails on Travis CI on "python3.6" command

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 1d2a387b9526ef5f4d694734d8022e739f7fd410 by Victor Stinner in 
branch '3.6':
bpo-32316: Travis CI: use PYTHON_FOR_REGEN=python3 (#4853)
https://github.com/python/cpython/commit/1d2a387b9526ef5f4d694734d8022e739f7fd410


--

___
Python tracker 

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

[issue32298] Email.quopriprime over-encodes characters

[Geoff Kuenning]

Geoff Kuenning  added the comment:

I should have read that part of RFC 2047 before I submitted.

I'd love to claim that I'm going to write a patch that would do as you suggest. 
 But the reality is that I'm unlikely to find the time, so I'm going to be wise 
for once and avoid promising what I can't deliver.

--

___
Python tracker 

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

[issue32300] print(os.environ.keys()) should only print the keys

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

shelve.Shelf is the example of such kind.

--

___
Python tracker 

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

[issue32317] sys.exc_clear() clears exception in other stack frames

[Garrett Berg]

New submission from Garrett Berg :

# Summary
In python (2 or 3) it should always be valid to have a bare *raise* statement 
in an exception block.

try:
do_something()
except SomeException:
do_cleanup()
raise # always reraises SomeException with original stack trace

You can see this in the python exception documentation:
https://docs.python.org/2.7/tutorial/errors.html#raising-exceptions


# Reproduction of Failure of invariants
Example python file where this doesn't work:

from __future__ import print_function

import sys

def doclear():
"""This should basically be a noop"""
sys.exc_clear()

try:
1/0
except ZeroDivisionError:
exc = sys.exc_info()[0]
print("first exc:", exc)
assert exc is ZeroDivisionError

try:
1/0
except ZeroDivisionError:
exc = sys.exc_info()[0]
print("second exc (before doclear):", exc)
doclear()
exc = sys.exc_info()[0]
print("second exc (after  doclear):", exc)
assert sys.exc_info()[0] is ZeroDivisionError  # fails


Running in python2.7 gives:

first exc: 
second exc (before doclear): 
second exc (after  doclear): None
Traceback (most recent call last):
  File "doclear.py", line 23, in 
assert sys.exc_info()[0] is ZeroDivisionError  # fails
AssertionError


# Conclusion
There seems to be a bug in python 2.7 where it doesn't follow it's own spec.
[sys.exc_clear()](https://docs.python.org/2/library/sys.html#sys.exc_clear)
states:

> This function clears all information relating to the current or last
> exception that occurred in the current thread. After calling this function,
> exc_info() will return three None values until another exception is raised in
> the current thread or *the execution stack returns to a frame where another
> exception is being handled*.

The above code is clear example where sys.exc_clear() is changing the value of
sys.exc_info() *in a different stack frame*, which is against what is stated in
the above docs.

This bug makes it impossible to reraise with a bare raise statement when doing
cleanup that could use sys.exc_clear(). In other words, calling into functions
can *change your local state* with regards to what exception is being handled.

--
components: Interpreter Core
messages: 308264
nosy: Garrett Berg
priority: normal
severity: normal
status: open
title: sys.exc_clear() clears exception in other stack frames
type: behavior
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

[issue32317] sys.exc_clear() clears exception in other stack frames

[Garrett Berg]

Garrett Berg  added the comment:

I forgot to post this:

python --version



Python 2.7.14

--

___
Python tracker 

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

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

[Yury Selivanov]

Yury Selivanov  added the comment:

Matthias,

Thanks a lot for such a detailed write-up!  I now better understand how you 
want to use the proposed API in Trio, and why the weakref approach isn't going 
to work (at least not in a straightforward way).

>> 2. What if another framework (say asyncio that you want to interoperate 
>> with) calls "sys.set_unawaited_coroutine_tracking(False)"?  

>> The API you propose has the *same* pitfall that 
>> 'sys.set_coroutine_wrapper()' has, when used by several frameworks 
>> simultaneously.

> As far as I understand you'll need to yield back to the other framework at 
> some
> point. Then it's IMHO to the author to make sure to save the state of
> `sys.collect_unawaited_coroutines()`, set
> `sys.set_unawaited_coroutine_tracking(enabled: bool)` to what the other
> framework expect, and  do the opposite when they get control back. 

Who do you refer to, when you say "author"?

In any case, in my opinion, it doesn't matter.  `sys.set_coroutine_wrapper` 
controls a single thread-local setting, `sys.set_unawaited_coroutine_tracking` 
*also* controls a single thread-local setting.  Both of them have the exact 
same problem when there's more than one user of the API.  So we can't consider 
this as a strong argument in favour of the 'set_unawaited_coroutine_tracking' 
API.

We can fix asyncio to manage coroutine wrappers more responsively.  Right now 
it will raise an error if there's a wrapper set by another framework.  Ideally, 
event loops should get the current wrapper, set their own, and then restore the 
original wrapper when they are done.

With that all in mind, my question is: have you guys tried to write a wrapper 
object in C for coroutines (or you can use Cython to get an idea)?  You can 
have a freelist of such objects to make their instantiation super cheap.  And 
you only need to proxy the '__await__' method (tp_as_async.am_await).

--

___
Python tracker 

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

[issue32143] os.statvfs lacks f_fsid

[Fred L. Drake, Jr.]

Change by Fred L. Drake, Jr. :


--
nosy: +fdrake

___
Python tracker 

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

[issue32316] [3.6] make regen-all fails on Travis CI on "python3.6" command

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue32316] [3.6] make regen-all fails on Travis CI on "python3.6" command

[STINNER Victor]

New submission from STINNER Victor :

The cpython job of Travis CI compiles Python with clang and then run "make 
regen-all" which fails.

"make regen-all" fails for example on regen-typeslots which runs 
"$(PYTHON_FOR_REGEN) ...". On Travis CI, $(PYTHON_FOR_REGEN) is "python3.6", 
but running python3.6 fails with:

"""
The `python3.6' command exists in these Python versions:
  3.6
  3.6.3
"""

Example of failed build:
https://travis-ci.org/python/cpython/jobs/315978517

--
components: Build
messages: 308262
nosy: brett.cannon, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: [3.6] make regen-all fails on Travis CI on "python3.6" command
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

[issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset bfbf04ef18c93ca8cab0453f76aeea1d8fc23fb1 by Yury Selivanov in 
branch 'master':
bpo-32296: Unbreak tests on Windows (#4850)
https://github.com/python/cpython/commit/bfbf04ef18c93ca8cab0453f76aeea1d8fc23fb1


--

___
Python tracker 

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

[issue32315] can't run any scripts with 2.7.x, 32 and 64-bit

[Martin]

New submission from Martin :

When I try to run a really simple script like:
def fun(a):
print a
return

I get this error:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 1541, in __call__
return self.func(*args)
  File "C:\Python27\lib\idlelib\MultiCall.py", line 166, in handler
r = l[i](event)
  File "C:\Python27\lib\idlelib\ScriptBinding.py", line 149, in run_module_event

if PyShell.use_subprocess:
AttributeError: 'module' object has no attribute 'use_subprocess'

It basically means Python is only usable by copy-pasting code into Shell, any 
kind of script fails with that error.

--
components: Library (Lib)
messages: 308260
nosy: DoctorEvil
priority: normal
severity: normal
status: open
title: can't run any scripts with 2.7.x, 32 and 64-bit
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

[issue32314] Implement asyncio.run()

[Yury Selivanov]

Yury Selivanov  added the comment:

I'll open a separate issue to improve Server's API.  AFAIK it's the main reason 
for having run_forever().

--

___
Python tracker 

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

[issue32314] Implement asyncio.run()

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I like avoiding run_forever() -- the function always was too cumbersome.

--

___
Python tracker 

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

[issue32312] Create Py_AtExitRegister C API

[Neil Schemenauer]

Neil Schemenauer  added the comment:

Private is fine.  We want to get the design correct before making it part of 
the official API.  My thought is that providing a handy atexit hook would be a 
good thing in that it could be an alternative to 3rd party code using __del__ 
to do cleanup.

One downside of atexit is that there is still a question of ordering the calls 
during shutdown.  I had the idea that maybe register() should take some sort of 
argument to specify when the function should be called.  That seems like 
leading down the road of madness maybe.  It would be useful to look at what 
other languages do, e.g. Java.  My understanding is that new versions of Java 
encourage finalizers like weakref callbacks and discourage or disallow 
finalizers like __del__.  I.e. you are not allowed to see the state of the 
object being finalized and cannot resurrect it.

Regarding m_traverse, maybe the list of finalizers should be stored somewhere 
in the interpreter state, not in the atexit module state.  That would make more 
sense to me.  atexit could merely be a way to manage it rather than actually 
holding it.

--

___
Python tracker 

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

[issue32314] Implement asyncio.run()

[Yury Selivanov]

Change by Yury Selivanov :


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

___
Python tracker 

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

[issue32313] Wrong inspect.getsource for datetime

[Aaron Meurer]

New submission from Aaron Meurer :

inspect.getsource(datetime) shows the Python source code for datetime, even 
when it is the C extension. This is very confusing. 

I believe it's because _datetime is used to override everything in datetime at 
the end of the file (here 
https://github.com/python/cpython/blob/11a247df88f15b51feff8a3c46005676bb29b96e/Lib/datetime.py#L2285),
 but __file__ is not imported.

--
messages: 308255
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: Wrong inspect.getsource for datetime

___
Python tracker 

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

[issue32314] Implement asyncio.run()

[Yury Selivanov]

New submission from Yury Selivanov :

There's a fairly extensive discussion here: 
https://github.com/python/asyncio/pull/465

In short, asyncio.run() is a pretty straightforward addition, so let's add it.

The discussion was more focused on the asyncio.run_forever() proposal.  I now 
think that it shouldn't be implemented in asyncio.  Instead we should fix cases 
where 'loop.run_forever' is usually required.  Mainly that's servers, and they 
are easily fixable by making "Server" an async context manager and implementing 
a "server.serve_forever()" method.  That way, with asyncio.run():

async def serve_something():
   async with asyncio.start_server(...) as server:
   await server.serve_forever()

asyncio.run(serve_something())  # No loop.run_forever()!

--
assignee: yselivanov
components: asyncio
messages: 308256
nosy: asvetlov, lukasz.langa, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio.run()
type: enhancement
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

[issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor

[STINNER Victor]

STINNER Victor  added the comment:

> Happy for someone else to do it. I won't have time this week - too much going 
> on at work.

Sure. I wrote a PR to fix the exact bug.

--

___
Python tracker 

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

[issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor

[STINNER Victor]

Change by STINNER Victor :


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

[issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C

[Yury Selivanov]

Yury Selivanov  added the comment:

Thanks Victor.  I've made a PR to fix this.

--

___
Python tracker 

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

[issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C

[Yury Selivanov]

Change by Yury Selivanov :


--
pull_requests: +4739
stage: resolved -> patch review

___
Python tracker 

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

[issue32312] Create Py_AtExitRegister C API

[STINNER Victor]

STINNER Victor  added the comment:

Oh by the way, if we decide to add a function, I would prefer to start with a 
private function. The C API is big enough. We can decide in the next version if 
the function becomes useful enough to justify to be added to the public API.

--

___
Python tracker 

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

[issue32300] print(os.environ.keys()) should only print the keys

[STINNER Victor]

STINNER Victor  added the comment:

> Don't make KeysView.__repr__ and ValuesView.__repr__ containing the lists of 
> all keys and values. This will make the repr of the view of a mapping which 
> is a proxy of an external DB containing the full content of that DB, which 
> can be gigabytes. See for example rejected issue21670.

The current implementation displays repr(self._mapping):

class MappingView(Sized):
...
def __repr__(self):
return '{0.__class__.__name__}({0._mapping!r})'.format(self)

For your proxy example: what is the proxy? The KeysView subtype, or the mapping?

repr(list), repr(dict) and repr(set) all render their full content in the 
result, no?

repr() on a list of 1 million of items *will* render all items, even if nobody 
wants to read such very long string :-)

If you want to get a smarter __repr__() than the default implementation: just 
override __repr__(), no?

I don't see why KeysView must be special.

--

___
Python tracker 

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

[issue32312] Create Py_AtExitRegister C API

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32312] Create Py_AtExitRegister C API

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Calling "atexit.register" using the C API isn't very difficult. The annoying 
part is to wrap a simple C function pointer in a callable PyObject (I don't 
think there is a simple C API for that).

--

___
Python tracker 

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

[issue32300] print(os.environ.keys()) should only print the keys

[Aaron Meurer]

Aaron Meurer  added the comment:

So the best fix is to just override keys() in the _Environ class, so that it 
returns an EnvironKeysView class that overrides __repr__?

--

___
Python tracker 

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

[issue32312] Create Py_AtExitRegister C API

[STINNER Victor]

STINNER Victor  added the comment:

See also:
[Python-Dev] PEP 489: module m_traverse called with NULL module state
https://mail.python.org/pipermail/python-dev/2017-December/151238.html

--

___
Python tracker 

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

[issue32312] Create Py_AtExitRegister C API

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +pitrou, vstinner

___
Python tracker 

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

[issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C

[STINNER Victor]

STINNER Victor  added the comment:

Hum, sometimes it's better to wait for AppVeyor :-) You broke all Windows 
buildbots! :-) Example:

http://buildbot.python.org/all/#/builders/40/builds/278

==
ERROR: test_get_event_loop_returns_running_loop 
(test.test_asyncio.test_events.TestCGetEventLoop)
--
Traceback (most recent call last):
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_events.py",
 line 2738, in setUp
watcher = asyncio.SafeChildWatcher()
AttributeError: module 'asyncio' has no attribute 'SafeChildWatcher'
==
ERROR: test_get_event_loop_returns_running_loop 
(test.test_asyncio.test_events.TestPyGetEventLoop)
--
Traceback (most recent call last):
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_events.py",
 line 2738, in setUp
watcher = asyncio.SafeChildWatcher()
AttributeError: module 'asyncio' has no attribute 'SafeChildWatcher'

--
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue32312] Create Py_AtExitRegister C API

[Neil Schemenauer]

New submission from Neil Schemenauer :

It would be handy to have a C API that registered an atexit function, similar 
to what calling atexit.register does.  This API could be used by C extension 
modules to register atexit functions.

I think the implementation would be fairly simple.  We need a function that 
calls atexit_register().  The tricky bit is that we need to make sure the 
atexit module has been initialized as atexit_register uses the module state.

This API is different from Py_AtExit in that atexit.register() calls the 
function early in the interpreter shutdown whereas Py_AtExit calls functions 
very late in the shutdown.

--
messages: 308246
nosy: nascheme
priority: low
severity: normal
stage: needs patch
status: open
title: Create Py_AtExitRegister C API
type: enhancement

___
Python tracker 

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

[issue32309] Implement asyncio.run_in_executor shortcut

[Andrew Svetlov]

Andrew Svetlov  added the comment:

https://bugs.python.org/issue32311 opened for create_task()

--

___
Python tracker 

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

[issue32310] Remove _Py_PyAtExit from Python.h

[Neil Schemenauer]

Change by Neil Schemenauer :


--
keywords: +patch
pull_requests: +4738

___
Python tracker 

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

[issue32311] Implement asyncio.create_task() shortcut

[Andrew Svetlov]

Change by Andrew Svetlov :


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

___
Python tracker 

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

[issue32300] print(os.environ.keys()) should only print the keys

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Don't make KeysView.__repr__ and ValuesView.__repr__ containing the lists of 
all keys and values. This will make the repr of the view of a mapping which is 
a proxy of an external DB containing the full content of that DB, which can be 
gigabytes. See for example rejected issue21670.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32309] Implement asyncio.run_in_executor shortcut

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Removed create_task() from title

--
title: Implement asyncio.create_task() and asyncio.run_in_executor shortcuts -> 
Implement asyncio.run_in_executor shortcut

___
Python tracker 

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

[issue32311] Implement asyncio.create_task() shortcut

[Andrew Svetlov]

Change by Andrew Svetlov :


--
components: Library (Lib), asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio.create_task() shortcut
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

[issue32309] Implement asyncio.create_task() and asyncio.run_in_executor shortcuts

[Andrew Svetlov]

Change by Andrew Svetlov :


--
assignee: docs@python -> 
nosy:  -docs@python

___
Python tracker 

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

[issue32310] Remove _Py_PyAtExit from Python.h

[Neil Schemenauer]

New submission from Neil Schemenauer :

_Py_PyAtExit only supports on callback function.  Its sole use it to be used by 
atexit.  IMHO, it should be removed from Python.h to prevent misuse.

--
components: Interpreter Core
messages: 308242
nosy: nascheme
priority: low
severity: normal
stage: patch review
status: open
title: Remove _Py_PyAtExit from Python.h
type: enhancement

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 11a247df88f15b51feff8a3c46005676bb29b96e by Victor Stinner in 
branch 'master':
bpo-32030: Add _PyPathConfig_ComputeArgv0() (#4845)
https://github.com/python/cpython/commit/11a247df88f15b51feff8a3c46005676bb29b96e


--

___
Python tracker 

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

[issue32300] print(os.environ.keys()) should only print the keys

[STINNER Victor]

STINNER Victor  added the comment:

Cheryl: would you like to work on a PR? If yes, tests are needed.

--

___
Python tracker 

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

[issue32309] Implement asyncio.create_task() and asyncio.run_in_executor shortcuts

[Yury Selivanov]

Yury Selivanov  added the comment:

I don't like the low-level API of run_in_executor.  "executor" being the first 
argument, the inability to pass **kwargs, etc.

I'd expect to see a more high-level API, perhaps the one that supports 'async 
with':

async with asyncio.ThreadPool() as pool:
f1 = pool.run(func1)
f2 = pool.run(func2)
r3 = await pool.run(func3)

r1 = f1.result()
r2 = f2.result()
print(r1, r2, r3)

I mean it's great that we can use 'concurrent.futures' in asyncio, but having 
native asyncio pools implementation would be way more convenient to the users.

In any case, can we focus this issue on the "run_in_executor" API, and open a 
new one for "create_task"?

--

___
Python tracker 

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

[issue32309] Implement asyncio.create_task() and asyncio.run_in_executor shortcuts

[Andrew Svetlov]

Change by Andrew Svetlov :


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

___
Python tracker 

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

[issue32309] Implement asyncio.create_task() and asyncio.run_in_executor shortcuts

[Andrew Svetlov]

New submission from Andrew Svetlov :

loop.create_task() and loop.run_in_executor are present very often in user 
code. But they are require a loop instance, actual call looks like

loop = asyncio.get_running_loop()
loop.create_task(coro())

The proposal adds create_task(coro) and run_in_executor(executor, func, *args) 
shortcuts for this.

--
assignee: docs@python
components: Documentation, asyncio
messages: 308238
nosy: asvetlov, docs@python, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio.create_task() and asyncio.run_in_executor shortcuts
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

[issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset a70232f28882d2fecb3ebe06643867701016070f by Yury Selivanov in 
branch 'master':
bpo-32296: Implement asyncio.get_event_loop and _get_running_loop in C. (#4827)
https://github.com/python/cpython/commit/a70232f28882d2fecb3ebe06643867701016070f


--

___
Python tracker 

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

[issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C

[Yury Selivanov]

Change by Yury Selivanov :


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

___
Python tracker 

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

[issue17852] Built-in module _io can lose data from buffered files at exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

I created a new PR which uses the atexit module instead of using _Py_PyAtExit.  
I think registering in io.py is okay.

I see that atexit is now implemented in C.  Rather than registering in io.py, 
we could create a C API to register callbacks (i.e. atexit_register).  That 
would perhaps be a bit cleaner.

--

___
Python tracker 

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

[issue17852] Built-in module _io can lose data from buffered files at exit

[Neil Schemenauer]

Change by Neil Schemenauer :


--
pull_requests: +4735
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

[issue26259] Memleak when repeated calls to asyncio.queue.Queue.get is performed, without push to queue.

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Duplicate of https://bugs.python.org/issue31620

--
nosy: +asvetlov
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> asyncio.Queue leaks memory if the queue is empty and consumers 
poll it frequently

___
Python tracker 

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

[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Sorry for late closing the issue, PR was merged a month ago.

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

[issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor

[Steve Dower]

Steve Dower  added the comment:

Happy for someone else to do it. I won't have time this week - too much going 
on at work.

--

___
Python tracker 

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

[issue32104] add method throw() to asyncio.Task

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I think the ship has sailed.
Now too many code is based on assumption that the only way to cancel a task 
from outer code is `task.cancel()`. Internally it is turned into 

try:
   await do_stuff()
except asyncio.CancelledError:
   do_task_cancellation() 

Raising *any* exception for cancellation breaks all existing code like this. 
Moreover figuring out if a task was cancelled from outside (by timeout for 
example) or exception was raised by inner code becomes impossible.

I suggest closing the issue with "wont fix" resolution.

--
nosy: +asvetlov

___
Python tracker 

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

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

[Matthias Bussonnier]

Matthias Bussonnier  added the comment:

Let me try to explain better, I'm pretty sure there is just a misunderstanding
from some of use in the vocabulary or presupposition we start from. I have the
impression that you feel like the API will automatically make coroutine raise
when they are not awaited, while I have the impression that in only provide a
tool for frameworks to detect unawaited coros and raise As soon as possible in
the right place.


We have the scheduler/eventloop that advance users tasks. Each time a user task
yield to the scheduler directly, or indirectly, the scheduler want to check that
since last time it was called in the same task no non-awaited coroutines are
pending, that is to say

await sleep(0) # yield to scheduler
c1 = coro() 
await c1

c2 = coro()

c3 = coro()
del c3
gc.collect()

await sleep(0) # yield again.


We want to make sure that between the two `sleep(0)` no coro is unawaited. Let's
assume `await coro()` does not itself yield to the scheduler for simplicity. In
above case you can see that c2 is not awaited, so according to Nathaniel
proposal, `sys.collect_unawaited_coroutines()` would returns `[c2, c3]`, So the
second sleep(0) can raise NonAwaitedCoroutineError, (and if tracemalloc is
enabled give more informations). 



You propose to use 
  weakref.ref(coro, trio._untrack_coro)

And I suppose you want us to do

  def _untrack_coro(self, ref):
  coro = ref()
  if inspect.getcoroutinestate(c) == 'CORO_STARTED'
.. do what's necessary for unawaited coroutine. 
  else:
# just discard from the tracked list.


Unfortunately:

> the weak reference object will be passed as the only parameter to the
> callback; *the referent will no longer be available*.

Thus we cannot check the state of the collected coroutine, according to my
understanding and experiments (Also we need to keep ref alive, but that's a
minor inconvenience). My guess is the referent is not around for users not to
suddenly add a ref to it...

So such a tracked list could only be use to know if coroutines where GC'd or
not.


If you are using wekrefs, you may also think about
`sys.collect_unawaited_coroutines()` returning weakref list, but that would lead
to `WeakRefList[c2]` because c3 was collected :-(. While we still raise because 
of
c2, a user logic only containing c3 would pass the "no unawaited coroutines".

To respond to your answer more specifically:

> 1. How will trio handle situations like:

>c = coro()
>await ...
>nursery.start_soon(c)


It depends what your `...` is, if its yielding to the trio scheduler, then the
scheduler will check unawaited coroutines, see that the list is non-empty and
raise a NonAwaitedCoroutineError at your `await ...`. In the case your `await
...` does not yield.. then nothing. 

> Maybe creating a coroutine and not immediately passing it to 'start_soon' or 
> similar API is an anti-pattern in Trio, but it is an OK thing to do in 
> asyncio/curio/twisted.

Yes, and the trio/curio/asyncio library is responsible to check
`sys.collect_unawaited_coroutines()`, and react appropriately. Trio will likely
decide to raise. Asyncio can just forget this option exists.

> 2. What if another framework (say asyncio that you want to interoperate with) 
> calls "sys.set_unawaited_coroutine_tracking(False)"?  

> The API you propose has the *same* pitfall that 'sys.set_coroutine_wrapper()' 
> has, when used by several frameworks simultaneously.

As far as I understand you'll need to yield back to the other framework at some
point. Then it's IMHO to the author to make sure to save the state of
`sys.collect_unawaited_coroutines()`, set
`sys.set_unawaited_coroutine_tracking(enabled: bool)` to what the other
framework expect, and  do the opposite when they get control back. 


> 3. Given (2), why don't you have a coroutine wrapper like this:

>  def trio_coroutine_wrapper(coro):
>  ref = weakref.ref(coro, trio._untrack_coro)
>  trio._track_coro(ref)
>  return coro

We can't use weakref (cf issue with c3/weakref above).


We could track all coroutines, with a normal container, which is exactly what we
do here[1], except now everytime you need to check
`inspect.getcoroutinestate(coro) == 'CORO_CREATED'` on every item. You can't
use weakref callback as you can't check the coro state in this case. The check
on all coro everytime does add potentially significant overhead, AND block the
GC of awaited couroutines in between checks. While we _do want_ to  block GC of
coroutine only if `sys.collect_unawaited_coroutines()` is set to true and
coroutine is not awaited.

Also we like to keep the actual non-awaited coro around for error messages, but
I guess we can do without. 

One alternative would be the ability to add a callback when coros change
states... But I though coroutines where one way to avoid callbacks...


Now you have way more understanding of core CPython than me, and I may 

[issue32292] Building fails on Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, I've decided to bite the bullet.  I uninstalled VS 2015 and installed VS 
2017 Community Edition.  Things seem to work now.  Thanks for the help!

--
resolution:  -> fixed
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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Currently re.sub() replaces empty matches only when not adjacent to a previous 
match. This makes it inconsistent with re.findall() and re.finditer() which 
finds empty matches adjacent to a previous non-empty match and with other RE 
engines.

Proposed PR makes all functions that makes repeated searching (re.split(), 
re.sub(), re.findall(), re.finditer()) mutually consistent.

The PR change the behavior of re.split() too, but this doesn't matter, since it 
already is different from the 3.6 behavior.

BDFL have approved this change.

This change doesn't break any stdlib code. It is expected that it will not 
break much third-party code, and even if it will break some code, it can be 
easily rewritten. For example replacing re.sub('(.*)', ...) (which now matches 
an empty string at the end of the string) with re.sub('(.+)', ...) is an 
obvious fix.

--
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
messages: 308229
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Replace empty matches adjacent to a previous non-empty match in re.sub()
type: enhancement
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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4733

___
Python tracker 

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

[issue32307] Bad assumption on thread stack size makes python crash with musl libc

[R. David Murray]

R. David Murray  added the comment:

Well, from our point of view it isn't a bad assumption, it's that muslc needs 
to be added to the list of exceptions.  (I know almost nothing about this...I 
assume there is some reason we can't determine the stack size programatically?)

Would you care to propose a PR?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue32236] open() shouldn't silently ignore buffering=1 in binary mode

[Antoine Pitrou]

Antoine Pitrou  added the comment:

After looking at the PR, I think it would be a bit too strong to raise an 
error. Perhaps emit a warning instead?

--

___
Python tracker 

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

[issue32307] Bad assumption on thread stack size makes python crash with musl libc

[Natanael Copa]

New submission from Natanael Copa :

Python assumes that the system default thread stack size is big enough for 
python, except for OSX and FreeBSD where stack size is explicitly set. With 
musl libc the system thread stack size is only 80k, which leads to hard crash 
before `sys.getrecursionlimit()` is hit.

See: https://github.com/python/cpython/blob/master/Python/thread_pthread.h#L22


Testcase:

import threading
import sys

def f(n=0):
try:
print(n)
f(n+1)
except Exception:
print("we hit recursion limit")
sys.exit(0)

t = threading.Thread(target=f)
t.start()


This can be pasted into:

  docker run --rm -it python:2.7-alpine
  docker run --rm -it python:3.6-alpine

--
components: Interpreter Core
messages: 308226
nosy: Natanael Copa
priority: normal
severity: normal
status: open
title: Bad assumption on thread stack size makes python crash with musl libc
type: crash
versions: Python 2.7, Python 3.6

___
Python tracker 

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

[issue32004] Allow specifying code packing order in audioop adpcm functions

[MosesofEgypt]

MosesofEgypt  added the comment:

Added serhiy.storchaka to nosy list as the issue has been open for over a month 
without response(not sure if I should have done this in the first place).

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

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

[Yury Selivanov]

Yury Selivanov  added the comment:

>   send_ping() # don't care about result, forgot await
>   # get collected
>   await something_that_will_trigger_check_coros_weakreaf() # oh no !

I don't understand what you are trying to say with this example.  What is 
"something_that_will_trigger_check_coros_weakreaf" supposed to do?

The point of my proposal that you will have a coroutine reported at the "get 
collected" point in CPython, or sometime later in PyPy.

> So if its weak-refd then you can't be sure you are actually preventing 
> non-awaited coros.

Sorry, I don't understand this sentence either.

--

___
Python tracker 

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

[issue32300] print(os.environ.keys()) should only print the keys

[R. David Murray]

R. David Murray  added the comment:

Agreed about the other classes if we change this.  Your solution looks 
reasonable to me.

--

___
Python tracker 

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

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

[Matthias Bussonnier]

Matthias Bussonnier  added the comment:

Your last description is about exactly what 
https://github.com/python-trio/trio/pull/176 is about (which I need to resurect)

There are some issue with weakref some that I don't remember, but one of them 
is (IIRC): what if a non-awaited coro get collected before being awaited and 
check by trio ? 

   send_ping() # don't care about result, forgot await
   # get collected
   await something_that_will_trigger_check_coros_weakreaf() # oh no !

   
So if its weak-refd then you can't be sure you are actually preventing 
non-awaited coros.

By default in trio we also would like to enforce immediate coro awaiting, but 
we of course would provide a convenience function to wrap coroutines you really 
do not want to await now. (Explicit is better than implicit) So you would write:

c = coro()
really_not_awaiting_now_leave_me_alone(c)
await ... #
nursery.start_soon(c)

What above PR does is check each time you enter the trio scheduler whether 
there is unawaited Coros (not marked as really_no_not_awaiting_now), and if so, 
next time you restart this task (or enter an cancellation point.. but details) 
raise a NonAwaitedCoroutineError. It does not raise _exactly_ where it was not 
awaited but narrow down where the non-awaited coro is (between two schedule 
point). And _if_ you enable tracemalloc the error message give you where the 
stack trace that created this coro.

--

___
Python tracker 

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

[issue32306] Clarify map API in concurrent.futures

[David Lukeš]

New submission from David Lukeš :

The docstring for `concurrent.futures.Executor.map` starts by stating that it 
is "Equivalent to map(func, *iterables)". In the case of Python 3, I would 
argue this is true only superficially: with `map`, the user expects 
memory-efficient processing, i.e. that the entire resulting collection will not 
be held in memory at once unless s/he requests so e.g. with `list(map(...))`. 
(In Python 2, the expectations are different of course.) On the other hand, 
while `Executor.map` superficially returns a generator, which seems to align 
with this expectation, what happens behind the scenes is that the call blocks 
until all results are computed and only then starts yielding them. In other 
words, they have to be stored in memory all at once at some point.

The lower-level multiprocessing module also describes 
`multiprocessing.pool.Pool.map` as "A parallel equivalent of the map() built-in 
function", but at least it immediately goes on to add that "It blocks until the 
result is ready.", which is a clear indication that all of the results will 
have to be stored somewhere before being yielded.

I can think of several ways the situation could be improved, listed here from 
most conservative to most progressive:

1. Add "It blocks until the result is ready." to the docstring of 
`Executor.map` as well, preferably somewhere at the beginning.
2. Reword the docstrings of both `Executor.map` and `Pool.map` so that they 
don't describe the functions as "equivalent" to built-in `map`, which raises 
the wrong expectations. ("Similar to map(...), but blocks until all results are 
collected and only then yields them.")
3. I would argue that the function that can be described as semantically 
equivalent to `map` is actually `Pool.imap`, which yields results as they're 
being computed. It would be really nice if this could be added to the 
higher-level `futures` API, along with `Pool.imap_unordered`. `Executor.map` 
simply doesn't work for very long streams of data.
4. Maybe instead of adding `imap` and `imap_unordered` methods to `Executor`, 
it would be a good idea to change the signature of `Executor.map(func, 
*iterables, timeout=None, chunksize=1)` to `Executor.map(func, *iterables, 
timeout=None, chunksize=1, block=True, ordered=True)`, in order to keep the API 
simple with good defaults while providing flexibility via keyword arguments.
5. I would go so far as to say that for me personally, the `block` argument to 
the version of `Executor.map` proposed in #4 above should be `False` by 
default, because that would make it behave most like built-in `map`, which is 
the least suprising behavior. But I've observed that for smaller work loads, 
`imap` tends to be slower than `map`, so I understand it might be a tradeoff 
between performance and semantics. Still, in a higher-level API meant for 
non-experts, I think semantics should be emphasized.

If the latter options seem much too radical, please consider at least something 
along the lines of #1 above, I think it would help people correct their 
expectations when they first encounter the API :)

--
components: Library (Lib)
messages: 308221
nosy: David Lukeš
priority: normal
severity: normal
status: open
title: Clarify map API in concurrent.futures
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

[issue32300] print(os.environ.keys()) should only print the keys

[STINNER Victor]

STINNER Victor  added the comment:

If we decide to change abc.KeysView.__repr__, IMHO we should also modify 
abc.ValuesView.__repr__, and maybe also abc.ItemsView.__repr__.

--

___
Python tracker 

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

[issue32300] print(os.environ.keys()) should only print the keys

[STINNER Victor]

STINNER Victor  added the comment:

Usually, I use print(sorted(os.environ)) since I prefer a sorted list and it 
prevents such issue :-)

David:
> I agree that the result is surprising, but there may not be a generic fix.

What about something like:

vstinner@apu$ ./python -c 'import os; print(os.environ.keys())'


vstinner@apu$ git diff
diff --git a/Lib/_collections_abc.py b/Lib/_collections_abc.py
index a5c7bfcda1..5e524dffbf 100644
--- a/Lib/_collections_abc.py
+++ b/Lib/_collections_abc.py
@@ -719,6 +719,9 @@ class KeysView(MappingView, Set):
 def __iter__(self):
 yield from self._mapping
 
+def __repr__(self):
+return '' % list(self)
+
 KeysView.register(dict_keys)
 
 

list(key_view) is valid. I mimicked dict views implementation:

static PyObject *
dictview_repr(_PyDictViewObject *dv)
{
PyObject *seq;
PyObject *result;

seq = PySequence_List((PyObject *)dv);
if (seq == NULL)
return NULL;

result = PyUnicode_FromFormat("%s(%R)", Py_TYPE(dv)->tp_name, seq);
Py_DECREF(seq);
return result;
}

--

___
Python tracker 

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

[issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor

[STINNER Victor]

STINNER Victor  added the comment:

@Steve: do you want to work on a fix?

--

___
Python tracker 

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

[issue29240] PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor  added the comment:

test_readline failed. It seems to be related to my commit:

http://buildbot.python.org/all/#/builders/87/builds/360

==
FAIL: test_nonascii (test.test_readline.TestReadline)
--
Traceback (most recent call last):
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_readline.py",
 line 219, in test_nonascii
self.assertIn(b"text 't\\xeb'\r\n", output)
AssertionError: b"text 't\\xeb'\r\n" not found in 
bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\\303\\257nserted]|t\x07\x08\x08\x08\x08\x08\x08\x08\x07\x07xrted]|t\x08\x08\x08\x08\x08\x08\x08\x07\r\nresult
 \'[\\xefnsexrted]|t\'\r\nhistory \'[\\xefnsexrted]|t\'\r\n")

--

___
Python tracker 

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

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

[Yury Selivanov]

Yury Selivanov  added the comment:

First, I've no questions about the proposed implementation.  It shouldn't have 
performance impact when unawaited coroutine tracking is off, which is the 
default.  It will cause minimal overhead when the tracking is on, which is 
fine.  Adding two extra pointers to coroutine objects should be OK too.

Back to the specification.  Few questions:

1. How will trio handle situations like:

c = coro()
await ...
nursery.start_soon(c)

?

There's a brief period of time when "c" is not being awaited, and thus it will 
be in the list that "sys.collect_unawaited_coroutines()" returns.  How exactly 
do you plan to use this new API in Trio?

Maybe creating a coroutine and not immediately passing it to 'start_soon' or 
similar API is an anti-pattern in Trio, but it is an OK thing to do in 
asyncio/curio/twisted.


2. What if another framework (say asyncio that you want to interoperate with) 
calls "sys.set_unawaited_coroutine_tracking(False)"?  

The API you propose has the *same* pitfall that 'sys.set_coroutine_wrapper()' 
has, when used by several frameworks simultaneously.


3. Given (2), why don't you have a coroutine wrapper like this:

   def trio_coroutine_wrapper(coro):
   ref = weakref.ref(coro, trio._untrack_coro)
   trio._track_coro(ref)
   return coro

This way:

- you don't introduce a lot of overhead, because there's no actual wrapper 
around a coroutine

- you can capture the file/lineno at the point where a coroutine was created, 
which is useful for reporting unawaited coroutines

--

___
Python tracker 

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

[issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor

[Steve Dower]

Steve Dower  added the comment:

This is the bit that needs fixing 
https://github.com/python/cpython/blob/master/Lib/distutils/command/bdist_wininst.py#L340

bv = '.'.join(CRT_ASSEMBLY_VERSION.split('.', 2)[:2])
if bv == '14.11':
# v141 and v140 are binary compatible,
# so keep using the 14.0 stub.
bv = '14.0'

AppVeyor has clearly gotten hold of 14.12, which should also be binary 
compatible (version numbers here are not strictly SemVer, but the 14 indicates 
binary compatibility).

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Mathieu Dupuy]

Mathieu Dupuy  added the comment:

I finally released my work. It looks like Paul's work is more comprehensive, 
but if you want to pick one thing or two in mine, feel free.

--

___
Python tracker 

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

[issue21332] subprocess bufsize=1 docs are misleading

[Alexey Izbyshev]

Change by Alexey Izbyshev :


--
pull_requests: +4732

___
Python tracker 

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

[issue32236] open() shouldn't silently ignore buffering=1 in binary mode

[Alexey Izbyshev]

Change by Alexey Izbyshev :


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

___
Python tracker 

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

[issue10344] codecs.open() buffering doc needs fix

[Alexey Izbyshev]

Change by Alexey Izbyshev :


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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset d5dda98fa80405db82e2eb36ac48671b4c8c0983 by Victor Stinner in 
branch 'master':
pymain_set_sys_argv() now copies argv (#4838)
https://github.com/python/cpython/commit/d5dda98fa80405db82e2eb36ac48671b4c8c0983


--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4729

___
Python tracker 

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

[issue29240] PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor  added the comment:


New changeset d5dda98fa80405db82e2eb36ac48671b4c8c0983 by Victor Stinner in 
branch 'master':
pymain_set_sys_argv() now copies argv (#4838)
https://github.com/python/cpython/commit/d5dda98fa80405db82e2eb36ac48671b4c8c0983


--

___
Python tracker 

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

[issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor

[STINNER Victor]

STINNER Victor  added the comment:

Oh, and the PATH:

os.environ[PATH]: 
C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
 Files\7-Zip;C:\Tools\GitVersion;C:\Tools\NuGet;C:\Program Files\Microsoft\Web 
Platform Installer\;C:\Tools\PsTools;C:\Program Files\Git LFS;C:\Program 
Files\Mercurial\;C:\Program Files 
(x86)\Subversion\bin;C:\Tools\WebDriver;C:\Tools\Coverity\bin;C:\Tools\MSpec;C:\Tools\NUnit\bin;C:\Tools\NUnit3;C:\Tools\xUnit;C:\Program
 Files\nodejs;C:\Program Files (x86)\iojs;C:\Program 
Files\iojs;C:\Users\appveyor\AppData\Roaming\npm;C:\Program Files\Microsoft SQL 
Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client 
SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL 
Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL 
Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL 
Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL 
Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\1
 30\Tools\Binn\;C:\Program Files\Microsoft SQL 
Server\130\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL 
Server\130\DTS\Binn\;C:\Program Files\Microsoft SQL 
Server\130\DTS\Binn\;C:\Program Files\Microsoft SQL Server\Client 
SDK\ODBC\130\Tools\Binn\;C:\Ruby193\bin;C:\go\bin;C:\Program 
Files\Java\jdk1.8.0\bin;C:\Program Files 
(x86)\Apache\Maven\bin;C:\Python27;C:\Python27\Scripts;C:\Program 
Files\erl8.3\bin;C:\Program Files (x86)\CMake\bin;C:\Tools\curl\bin;C:\Program 
Files\LLVM\bin;C:\Users\appveyor\.dnx\bin;C:\Program Files\Microsoft 
DNX\Dnvm\;C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\MSBuild\15.0\Bin;C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130;C:\Program 
Files\Amazon\AWSCLI\;C:\Program Files\dotnet\;C:\Tools\vcpkg;C:\Program Files 
(x86)\dotnet\;C:\Users\appveyor\AppData\Local\Microsoft\WindowsApps;C:\Users\appveyor\AppData\Local\Yarn\bin;C:\Users\appveyor\AppData\Roaming\npm;C:\Program
 Files\Docker
 ;C:\Program Files\Git\cmd;C:\Program Files\Microsoft Service 
Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service 
Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program 
Files\Git\usr\bin;C:\Program Files 
(x86)\Yarn\bin;C:\ProgramData\chocolatey\bin;C:\Program Files (x86)\Microsoft 
SQL Server\140\Tools\Binn\;C:\Program Files\Microsoft SQL 
Server\140\Tools\Binn\;C:\Program Files\Microsoft SQL 
Server\140\DTS\Binn\;C:\Program Files (x86)\nodejs\;C:\Program Files 
(x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\Extensions\TestPlatform;C:\Users\appveyor\AppData\Local\Microsoft\WindowsApps;C:\Users\appveyor\AppData\Local\Yarn\bin;C:\Users\appveyor\AppData\Roaming\npm;C:\Program
 Files\AppVeyor\BuildAgent\

--

___
Python tracker 

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

[issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor

[STINNER Victor]

STINNER Victor  added the comment:

Extract of pythoninfo of the failed build:

os.environ[VS110COMNTOOLS]: C:\Program Files (x86)\Microsoft Visual Studio 
11.0\Common7\Tools\
os.environ[VS120COMNTOOLS]: C:\Program Files (x86)\Microsoft Visual Studio 
12.0\Common7\Tools\
os.environ[VS140COMNTOOLS]: C:\Program Files (x86)\Microsoft Visual Studio 
14.0\Common7\Tools\

The build starts with:

Using "C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe"  (found in the PATH)

--

___
Python tracker 

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

[issue32292] Building fails on Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

It's a normal command prompt.  Here is the output of "set":
https://gist.github.com/pitrou/2baf9950b0ab2f68b39b4973355b2e79

--

___
Python tracker 

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

[issue32292] Building fails on Windows

[Steve Dower]

Steve Dower  added the comment:

Are you using a normal command prompt or the Visual Studio one? Totally clean 
environment should work fine these days, but I suspect there's an environment 
variable affecting something.

"set" to show everything that is set, remove any personal info and post or just 
email it to me if you'd like me to check.

--

___
Python tracker 

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