[issue39028] ENH: Fix performance issue in keyword extraction

2019-12-12 Thread Inada Naoki


Change by Inada Naoki :


--
nosy: +inada.naoki

___
Python tracker 

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



[issue39029] TestMaildir.test_clean fails randomly under parallel tests

2019-12-12 Thread Karthikeyan Singaravelan


New submission from Karthikeyan Singaravelan :

I can reproduce frequently the failure of test_clean on my Mac machine. It 
checks for removal of foo_path. It's removed by Maildir.clean that removes 
files based on the access time as below. The test also does similar thing with 
os.utime(foo_path, (time.time() - 129600 - 2, foo_stat.st_mtime)) but I guess 
the file is not really deleted in some cases.

https://github.com/python/cpython/blob/7772b1af5ebc9d72d0cfc8332aea6b2143eafa27/Lib/mailbox.py#L482

def clean(self):
"""Delete old files in "tmp"."""
now = time.time()
for entry in os.listdir(os.path.join(self._path, 'tmp')):
path = os.path.join(self._path, 'tmp', entry)
if now - os.path.getatime(path) > 129600:   # 60 * 60 * 36
os.remove(path)

$ ./python.exe -Wall -m test -R 3:3 -j 4 test_mailbox -m test_clean
0:00:00 load avg: 2.12 Run tests in parallel using 4 child processes
0:00:00 load avg: 2.12 [1/1/1] test_mailbox failed
beginning 6 repetitions
123456
.test test_mailbox failed -- Traceback (most recent call last):
  File "/Users/kasingar/stuff/python/cpython/Lib/test/test_mailbox.py", line 
737, in test_clean
self.assertFalse(os.path.exists(foo_path))
AssertionError: True is not false

== Tests result: FAILURE ==

1 test failed:
test_mailbox

Total duration: 951 ms
Tests result: FAILURE

--
components: Tests
messages: 358295
nosy: barry, maxking, r.david.murray, xtreak
priority: normal
severity: normal
status: open
title: TestMaildir.test_clean fails randomly under parallel tests
type: behavior
versions: Python 3.9

___
Python tracker 

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



[issue39015] DeprecationWarnings of implicitly truncations by __int__ appearing in the standard library

2019-12-12 Thread Serhiy Storchaka


Change by Serhiy Storchaka :


--
status: open -> pending

___
Python tracker 

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



[issue39027] run_coroutine_threadsafe uses wrong TimeoutError

2019-12-12 Thread Kyle Stanley


Kyle Stanley  added the comment:

Thanks for letting us know, janust. I confirmed that `asyncio.TimeoutError` no 
longer works for the code example in 3.8 and that replacing it with 
`concurrent.futures.TimeoutError` works correctly.

Before moving forward with a PR to the docs, I think we should wait for 
feedback from Yury to check if this behavior is intentional for 
`run_coroutine_threadsafe()`, I'll add him to the nosy list.

To me, this seems more like a side effect of `asyncio.TimeoutError` being 
changed to BaseException rather than an intended consequence. The main purpose 
of that change was to ensure that TimeoutError wasn't unintentionally 
suppressed by generic try-except blocks. IMO, it seems rather counter-intuitive 
to have to specify `concurrent.futures.TimeoutError` when using a timeout for 
the future returned by `run_coroutine_threadsafe()`. I'm not certain that it 
can be avoided though, other than by changing it to return an instance of 
asyncio.Future instead of concurrent.futures.Future.

--
nosy: +aeros, yselivanov

___
Python tracker 

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



[issue39027] run_coroutine_threadsafe uses wrong TimeoutError

2019-12-12 Thread Andrew Svetlov


Andrew Svetlov  added the comment:

futures._chain_future() should convert exceptions.
Seems _convert_future_exc() does this work already but maybe it fails somehow.
We need to investigate more.

--
nosy: +asvetlov

___
Python tracker 

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



[issue6699] IDLE: Warn user about overwriting a file that has a newer version on filesystem

2019-12-12 Thread Zackery Spytz


Change by Zackery Spytz :


--
pull_requests: +17052
pull_request: https://github.com/python/cpython/pull/17578

___
Python tracker 

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



[issue6699] IDLE: Warn user about overwriting a file that has a newer version on filesystem

2019-12-12 Thread Zackery Spytz


Zackery Spytz  added the comment:

I have created a pull request for this issue.

--
nosy: +ZackerySpytz

___
Python tracker 

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



[issue39029] TestMaildir.test_clean fails randomly under parallel tests

2019-12-12 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

Should not parallel tests be ran in different directories?

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue39030] Ctypes unions with bitfield members that do not share memory

2019-12-12 Thread dankreso


New submission from dankreso :

I've found what looks like a corner case bug. Specifically, the behaviour that 
looks suspicious is when a ctypes union has bit field members, where the 
members have bit widths that are smaller than the size types:

class BitFieldUnion(Union):
_fields_ = [("a", c_uint32, 16), ("b", c_uint32, 16)]

buff = bytearray(4)

bitfield_union = BitFieldUnion.from_buffer(buff)
bitfield_union.a = 1
bitfield_union.b = 2

print("a is {}".format(bitfield_union.a)) # Prints "a is 1"
print("b is {}".format(bitfield_union.b)) # Prints "b is 2"
print("Buffer: {}".format(buff)) # Prints "Buffer: b'\x01\x00\x00\x00'".

(Example of this script can be found at https://rextester.com/XJFGAK37131. I've 
also tried it on my system which is Ubuntu 16.04.2 LTS with Python 3.6.)

Here I would expect both 'a' and 'b' to be set to 2, and for the buffer to look 
like '\x02\x00\x00\x00'. Here's the equivalent code in C which behaves as 
expected: https://rextester.com/HWDUMB56821.

If at least one of the bitwidths in the above example are changed from 16 to 
32, however, then 'a', 'b', and the buffer look as expected.

I've also attached some further examples of weird behaviour with unions with 
bitfield members - online version can be found at 
https://rextester.com/VZRB77320.

--
components: ctypes
files: bitfield_union.py
messages: 358300
nosy: dankreso
priority: normal
severity: normal
status: open
title: Ctypes unions with bitfield members that do not share memory
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48772/bitfield_union.py

___
Python tracker 

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



[issue39028] ENH: Fix performance issue in keyword extraction

2019-12-12 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
nosy: +pablogsal

___
Python tracker 

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



[issue19038] Fix sort order in Misc/ACKS.

2019-12-12 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Even though I was not nosy on this 6 year old issue, I just got the following 
email requesting that the attachments be removed.  I am not doing so because 
they seem to be needed to make sense of the issue.  But anyone else who wants 
to do so may.  I removed the OP from the nosy list to avoid prompting more 
responses.

"Please remove two attachments (ACKS and ACKS.diff) in a bug [1] I
reported in September 2013 (Georg Brandl closed this bug)."

--
nosy: +terry.reedy -taewong.seo

___
Python tracker 

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



[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

2019-12-12 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17053
pull_request: https://github.com/python/cpython/pull/17579

___
Python tracker 

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



[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

2019-12-12 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17055
pull_request: https://github.com/python/cpython/pull/17581

___
Python tracker 

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



[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

2019-12-12 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17054
pull_request: https://github.com/python/cpython/pull/17580

___
Python tracker 

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



[issue38449] regression - mimetypes guess_type is confused by ; in the filename

2019-12-12 Thread Dong-hee Na


Dong-hee Na  added the comment:

@ned.deily @maxking
I close this issue since all PRs were merged.
Thanks, everyone for actions for this issue :)

Have a warm and happy holiday and a hopeful new year.

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



[issue39030] Ctypes unions with bitfield members that do not share memory

2019-12-12 Thread Lewis Gaul


Change by Lewis Gaul :


--
nosy: +LewisGaul, belopolsky

___
Python tracker 

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



[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h

2019-12-12 Thread STINNER Victor


Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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



[issue39028] ENH: Fix performance issue in keyword extraction

2019-12-12 Thread Sebastian Berg


Sebastian Berg  added the comment:

Fair enough, we had code that does it the other way, so it seemed "too obvious" 
since the current check seems mainly useful with few kwargs. However, a single 
kwarg is super common in python, while many seem super rare (in any argument 
clinic function)

Which is why I had even trouble finding a function where it could make a 
difference, since it needs many kwargs.

With changes:

sebastian@seberg-x1 ~/python-dev/bin
 % ./python3 -m timeit -s 'i = 4' 'i.to_bytes(length=5, byteorder="big", 
signed=True)'
100 loops, best of 5: 205 nsec per loop
sebastian@seberg-x1 ~/python-dev/bin
 % ./python3 -m timeit -s 'i = 4' 'i.to_bytes(length=5, byteorder="big", 
signed=True)'
100 loops, best of 5: 207 nsec per loop

On master:

sebastian@seberg-x1 ~/python-dev/bin
 % ./python3 -m timeit -s 'i = 4' 'i.to_bytes(length=5, byteorder="big", 
signed=True)'
100 loops, best of 5: 221 nsec per loop
sebastian@seberg-x1 ~/python-dev/bin
 % ./python3 -m timeit -s 'i = 4' 'i.to_bytes(length=5, byteorder="big", 
signed=True)'
100 loops, best of 5: 218 nsec per loop

Which, at close to 5% is barely noticeable, I suppose with more kwargs it could 
start to make a difference. With less than 3, it just does not matter I guess. 
Also, I am currently not sure how likely non-interned strings could actually 
happen. But I am not sure it matters to optimize for them (unless PyArg_From* 
functions use them).

In any case, sorry if this was noise, happy to fix things up or just drop it if 
many kwargs are considered non-existing.

--

___
Python tracker 

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



[issue32730] Allow py launcher to launch other registered Pythons

2019-12-12 Thread Tzu-ping Chung


Change by Tzu-ping Chung :


--
nosy: +uranusjr

___
Python tracker 

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



[issue39031] Inconsistent lineno and col_offset info when parsing elif

2019-12-12 Thread Lysandros Nikolaou


New submission from Lysandros Nikolaou :

While working on pegen, we came across an inconsistency on how line number and 
column offset info is stored for (el)if nodes. When parsing a very simple 
if-elif construct like

if a:
pass
elif b:
pass

the following parse tree gets generated:

Module(
body=[
If(
test=Name(id="a", ctx=Load(), lineno=1, col_offset=3, end_lineno=1, 
end_col_offset=4),
body=[Pass(lineno=2, col_offset=4, end_lineno=2, end_col_offset=8)],
orelse=[
If(
test=Name(
id="b", ctx=Load(), lineno=3, col_offset=5, 
end_lineno=3, end_col_offset=6
),
body=[Pass(lineno=4, col_offset=4, end_lineno=4, 
end_col_offset=8)],
orelse=[],
lineno=3,
col_offset=5,
end_lineno=4,
end_col_offset=8,
)
],
lineno=1,
col_offset=0,
end_lineno=4,
end_col_offset=8,
)
],
type_ignores=[],
)

There is the inconsistency that the column offset for the if statement is 0, 
thus the if statement starts with the keyword if, whereas the column offset for 
elif if 5, which means that the elif keyword is skipped.

As Guido suggests over at 
https://github.com/gvanrossum/pegen/issues/107#issuecomment-565135047 we could 
very easily change Python/ast.c so that the elif statement start with the elif 
keyword as well.

I have a PR ready!

--
messages: 358304
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: Inconsistent lineno and col_offset info when parsing elif
type: behavior
versions: Python 3.8, Python 3.9

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Lysandros Nikolaou


Change by Lysandros Nikolaou :


--
title: Inconsistent lineno and col_offset info when parsing elif -> 
Inconsistency with lineno and col_offset info when parsing elif

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Lysandros Nikolaou


Change by Lysandros Nikolaou :


--
keywords: +patch
pull_requests: +17056
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17582

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
nosy: +pablogsal

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
components: +Interpreter Core

___
Python tracker 

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



[issue36144] Dictionary addition. (PEP 584)

2019-12-12 Thread Aaron Hall


Aaron Hall  added the comment:

Another obvious way to do it, but I'm +1 on it.

A small side point however - PEP 584 reads:

> To create a new dict containing the merged items of two (or more) dicts, one 
> can currently write:

> {**d1, **d2}

> but this is neither obvious nor easily discoverable. It is only guaranteed to 
> work if the keys are all strings. If the keys are not strings, it currently 
> works in CPython, but it may not work with other implementations, or future 
> versions of CPython[2].

...

> [2] Non-string keys: https://bugs.python.org/issue35105 and 
> https://mail.python.org/pipermail/python-dev/2018-October/155435.html

The references cited does not back this assertion up. Perhaps the intent is to 
reference the "cool/weird hack" dict(d1, **d2) (see 
https://mail.python.org/pipermail/python-dev/2010-April/099485.html and 
https://mail.python.org/pipermail/python-dev/2010-April/099459.html), which 
allowed any hashable keys in Python 2 but only strings in Python 3.

If I see {**d1, **d2}, my expectations are that this is the new generalized 
unpacking and I currently expect any keys to be allowed, and the PEP should be 
updated to accurately reflect this to prevent future misunderstandings.

--
nosy: +Aaron Hall

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread miss-islington


miss-islington  added the comment:


New changeset 025a602af7ee284d8db6955c26016f3f27d35536 by Miss Islington (bot) 
(Lysandros Nikolaou) in branch 'master':
bpo-39031: Include elif keyword when producing lineno/col-offset info for 
if_stmt (GH-17582)
https://github.com/python/cpython/commit/025a602af7ee284d8db6955c26016f3f27d35536


--
nosy: +miss-islington

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17057
pull_request: https://github.com/python/cpython/pull/17583

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
pull_requests: +17058
pull_request: https://github.com/python/cpython/pull/17584

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Lysandros Nikolaou


Change by Lysandros Nikolaou :


--
pull_requests: +17059
pull_request: https://github.com/python/cpython/pull/17585

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

The same thing happens with 3.8.

--

___
Python tracker 

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



[issue39032] wait_for and Condition.wait still not playing nicely

2019-12-12 Thread Chris


New submission from Chris :

This is related to https://bugs.python.org/issue22970, 
https://bugs.python.org/issue33638, and https://bugs.python.org/issue32751. 
I've replicated the issue on Python 3.6.9, 3.7.4, and 3.8.0. Looking at the 
source, I'm fairly sure the bug is still in master right now.

The problem is yet another case of wait_for returning early, before the child 
has been fully cancelled and terminated. The issue arises if wait_for itself is 
cancelled. Take the following minimal example:

cond = asyncio.Condition()
async def coro():
async with cond:
await asyncio.wait_for(cond.wait(), timeout=999)

If coro is cancelled a few seconds after being run, wait_for will cancel the 
cond.wait(), then immediately re-raise the CancelledError inside coro, leading 
to "RuntimeError: Lock is not acquired."

Relevant source code plucked from the 3.8 branch is as follows:

try:
# wait until the future completes or the timeout
try:
await waiter
except exceptions.CancelledError:
fut.remove_done_callback(cb)
fut.cancel()
raise

if fut.done():
return fut.result()
else:
fut.remove_done_callback(cb)
# We must ensure that the task is not running
# after wait_for() returns.
# See https://bugs.python.org/issue32751
await _cancel_and_wait(fut, loop=loop)
raise exceptions.TimeoutError()
finally:
timeout_handle.cancel()

Note how if the timeout occurs, the method waits for the future to complete 
before raising. If CancelledError is thrown, it doesn't.

A simple fix seems to be replacing the "fut.cancel()" with "await 
_cancel_and_wait(fut, loop=loop)" so the behaviour is the same in both cases, 
however I'm only superficially familiar with the code, and am unsure if this 
would cause other problems.

--
components: asyncio
messages: 358307
nosy: asvetlov, criches, yselivanov
priority: normal
severity: normal
status: open
title: wait_for and Condition.wait still not playing nicely
type: behavior
versions: 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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-12 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

Hmmm, there is some problem with the CI and the 3.7 branch. Seems like Travis 
CI is giving some problems again I will investigate or maybe ask Brett to 
make the check not required again (we still have Azure Pipelines, testing the 
same thing).

--

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-12 Thread Mihail Georgiev


New submission from Mihail Georgiev :

I think there's a "t" missing:

Lib/zipimport.py
609-
610-try:
611:_boostrap_external._validate_hash_pyc(
612-data, source_hash, fullname, exc_details)
613-except ImportError:
614-return None
615-else:
616-source_mtime, source_size = \
617-_get_mtime_and_size_of_source(self, fullpath)
618-
619-if source_mtime:

--
components: Library (Lib)
messages: 358310
nosy: misho88
priority: normal
severity: normal
status: open
title: zipimport raises NameError: name '_boostrap_external' is not defined
type: crash
versions: Python 3.8, Python 3.9

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-12 Thread Zachary Ware


Zachary Ware  added the comment:

Good catch!  Would you like to submit a pull request to fix it?  Ideally such a 
PR should also include a test to exercise this code.

--
nosy: +twouters, zach.ware

___
Python tracker 

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



[issue38999] Python launcher on Windows does not detect active venv

2019-12-12 Thread Eryk Sun


Eryk Sun  added the comment:

> I think supporting the shebang line in py.exe is a misfeature and 
> would prefer we'd never done it (though it predates my involvement). 

Do you mean all shebangs, including those with a native file path?
Or do you mean just virtual shebangs, and in particular those that search PATH 
via "/usr/bin/env"? It's not without controversy even in Unix. For example, see 
[1] and the rebuttal to it in the comments.

In the case of this issue, "env" is used to run a script in an active virtual 
environment. This doesn't rely on the user or system PATH, assuming the command 
can be found in the active scripts directory.

As an alternative to modifying the launcher, pip (via distlib) could be updated 
to transform "#!/usr/bin/env pythonX[.Y]" shebangs into "#!/usr/bin/env python" 
when installing scripts in Windows. pip and distlib are third-party tools, 
however, so that suggestion is beyond the scope of this issue tracker.

[1] https://jmmv.dev/2016/09/env-considered-harmful.html

--

___
Python tracker 

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



[issue38999] Python launcher on Windows does not detect active venv

2019-12-12 Thread Steve Dower


Steve Dower  added the comment:

> Do you mean all shebangs, including those with a native file path?

I like the idea as a whole, but ultimately end up disliking all the available 
options (in the context of py.exe, that is).

* Unix/virtual shebangs don't work reliably on Windows (as we can see :) )
* Native file path shebangs on Windows don't work on Unix

The scripts installed by pip &co. are their own executable wrappers, so the 
shebang shouldn't matter.

But, the python.org Windows installer associates .py files with py.exe, so it 
_does_ matter for double-click and PATHEXT scenarios.

Perhaps it is reasonable to redefine "/usr/bin/env python*" as "use 
%VIRTUALENV% python.exe if set" regardless of the specific version? I really 
don't want to add checks that require running Python - I'd rather bail out and 
recommend using "py" directly.

--

___
Python tracker 

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



[issue38947] dataclass defaults behave inconsistently for init=True/init=False when default is a descriptor

2019-12-12 Thread Jeong-Min Lee


Change by Jeong-Min Lee :


--
nosy: +falsetru

___
Python tracker 

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



[issue38815] test_ssl: test_min_max_version() fails on FreeBSD and Fedora

2019-12-12 Thread Kubilay Kocak


Kubilay Kocak  added the comment:

I had to rebuild the openssl (1.1.x) port on the worker that had test_ssl 
failing in order to bring it back to green, so as not to hide new test failures.

If/when someone is able to produce a fix for the failing test, I am happy to 
revert the openssl build to its prior (failing config) state at any time to 
verify the test fix.

--

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-12 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue32949] Simplify "with"-related opcodes

2019-12-12 Thread Cheryl Sabella


Cheryl Sabella  added the comment:

Should this be closed now that PR6641 has been merged?

--
nosy: +cheryl.sabella

___
Python tracker 

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



[issue32907] pathlib: test_resolve_common fails on Windows w/ longusername

2019-12-12 Thread Cheryl Sabella


Change by Cheryl Sabella :


--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Release Windows Store app containing Python

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-12 Thread Ma Lin


Ma Lin  added the comment:

Is it possible to scan stdlib to find similar bugs?

--
nosy: +Ma Lin

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-12 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

A possible test case to trigger this code path based on 
testUncheckedHashBasedPyc would be as below. check_hash_based_pycs can be 
patched to be "always" so that the hash is validated using 
_bootstrap_external._validate_hash_pyc. The difference between "state = old" 
for pyc and "state = new" in py would ensure the hashes are different to raise 
ImportError expected and the test picks up state = new as the updated source 
code. Without fixing the typo trying to make hash validation would throw 
NameError.


@unittest.mock.patch('_imp.check_hash_based_pycs', 'always')
def test_checked_hash_based_change_pyc(self):
source = b"state = 'old'"
source_hash = importlib.util.source_hash(source)
bytecode = importlib._bootstrap_external._code_to_hash_pyc(
compile(source, "???", "exec"),
source_hash,
False,
)
files = {TESTMOD + ".py": (NOW, "state = 'new'"),
 TESTMOD + ".pyc": (NOW - 20, bytecode)}
def check(mod):
self.assertEqual(mod.state, 'new')
self.doTest(None, files, TESTMOD, call=check)

--
nosy: +xtreak

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-12 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

Also since the fix involves modifying zipimport.py it would also require 
running "make regen-importlib && make -s" for changes to ensure the updated 
regen code is used.

--

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-12 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

Ma Lin, Running pylint/flake8 could possibly detect it but needs to be manually 
checked. issue36948 was a similar report I filed in the past using flake8 
regarding NameError.

pylint - Lib/zipimport.py:611:20: E0602: Undefined variable 
'_boostrap_external' (undefined-variable)
flake8 - Lib/zipimport.py:611:21: F821 undefined name '_boostrap_external'

--

___
Python tracker 

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



[issue39034] Documentation: Coroutines

2019-12-12 Thread Rustam Agakishiev

New submission from Rustam Agakishiev :

Here: https://docs.python.org/3/library/asyncio-task.html  
it says:"To actually run a coroutine, asyncio provides three main mechanisms:"

and a few pages down it gives you a fourth mechanism:
"awaitable asyncio.gather(*aws, loop=None, return_exceptions=False)
Run awaitable objects in the aws sequence concurrently."

And it really runs awaitables:
future = asyncio.gather(*awslist) # aws are run...
...   # some other heavy tasks
result = async future # collect results

Shouldn't it be added to docs?

--
assignee: docs@python
components: Documentation
messages: 358320
nosy: agarus, docs@python
priority: normal
severity: normal
status: open
title: Documentation: Coroutines
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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-12 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

Wince you has virtually written a patch, do you mind to create a PR Karthikeyan?

--

___
Python tracker 

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



[issue32949] Simplify "with"-related opcodes

2019-12-12 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

Sure.

--
resolution:  -> out of date
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



[issue39034] Documentation: Coroutines

2019-12-12 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
components: +asyncio
nosy: +asvetlov, yselivanov

___
Python tracker 

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