[issue44571] itertools: takedowhile()

[Tim Peters]

Tim Peters  added the comment:

I agree Raymond's `before_and_after()` looks like an elegant, efficient, and 
usable approach to this.

One minor nit: there's no need for the `iter()` call in:

yield from iter(transition)

Indeed, it confused me at first, because `yield from x` does its own `iter(x)` 
call under the covers, and since everyone knows that ;-) , I wondered what deep 
trickery calling it again was intended to pull off.

But I persuaded myself there was no such subtle intent - it's just redundant.

--
nosy: +tim.peters

___
Python tracker 

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

[issue42799] Please document fnmatch LRU cache size (256) and suggest alternatives

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I've put up the PR here: https://github.com/python/cpython/pull/27084/files

--

___
Python tracker 

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

[issue42799] Please document fnmatch LRU cache size (256) and suggest alternatives

[Andrei Kulakov]

Change by Andrei Kulakov :


--
keywords: +patch
nosy: +andrei.avk
nosy_count: 2.0 -> 3.0
pull_requests: +25632
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27084

___
Python tracker 

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

[issue44517] test__xxsubinterpreters: AMD64 Fedora Stable 3.x buildbot aborts at test_still_running

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
status: open -> pending

___
Python tracker 

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

[issue44517] test__xxsubinterpreters: AMD64 Fedora Stable 3.x buildbot aborts at test_still_running

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

FYI, this buildbot has been green after Victor's git clean adjustment in the 
buildbot repo.

I've been trying to reproduce the test_still_running failure on the buildbot, 
but have not been able to do so deterministically.

--

___
Python tracker 

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

[issue44594] AsyncExitStack.enter_async_context() is mishandling exception __context__

[David Hoyes]

Change by David Hoyes :


--
nosy: +David Hoyes

___
Python tracker 

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

[issue44589] Pattern Matching - duplicate keys in mapping patterns

[Brandt Bucher]

Change by Brandt Bucher :


--
assignee:  -> brandtbucher

___
Python tracker 

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

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[Christian Tanzer]

Christian Tanzer  added the comment:

Json keys *are strings*. 

That‘s why json.dump stringifies all keys. If you want to argue that this 
behavior is wrong I wouldn’t protest except for that it breaks extant code.

But arguing that sorting the stringified keys would violate user’s expectations 
or lead to problems down the line makes no sense. The user is asking for an 
object with string keys and they want the keys sorted. That is unambiguous and 
well defined.

Neither does adding a second argument make any sense, it would just increase 
the confusion.

My problem was that Python 3.x threw an exception about this for a complex json 
object in a context where it was not at all obvious what was going on. And the 
code in question had worked for years in Python 2.

This bug report is many, many years old and I don’t much care one way or 
another but I am very sad that 

 Practicality beats purity 

got utterly lost in and after the transition to Python 3.

Christian Tanzer

> On 10.07.2021, at 16:12, Andrei Kulakov  wrote:
> 
> Andrei Kulakov  added the comment:
> 
> Some observations:
> 
> - sort_keys arg does a deep sorting of nested dictionaries. It's a bit too 
> much to ask users to do this type of preprocessing manually before dumping to 
> json.
> 
> - the error doesn't seem too onerous to me. 'unorderable types: str() < 
> int()' If uncertain, a user can go to interactive shell and try `1 < "2"`, 
> and then the issue is obvious.
> 
> - to me, current behaviour seems preferable to silently guessing that users 
> wants stringified sorting, especially since it can surface as a problem way 
> down the line.
> 
> - what makes this issue interesting is that in roughly half of cases (I'm 
> guessing) the user will want object sorted and then cast to string and would 
> be surprised if the reverse happened, and in the other half cases the user 
> would want them stringified, then sorted, and would be surprised if that 
> didn't happen.
> 
> It depends on the perspective: you may think of the json as a representation 
> of a dict of objects, that just happen to be in json format; or you can think 
> of it as a json document with string keys (of course) that just happen to 
> come from a dict of objects. Both can be valid depending on the use case.
> 
> Given all of this, I propose keeping current behavior for the existing arg, 
> and adding another arg for 'stringify then sort' behavior. Then we'll have no 
> silent guessing and the "unorderable" type error message can point the user 
> directly to the new argument.
> 
> If the user reads the docs before using this method, they will see two clear 
> options with respective tradeoffs and decide which one to use.
> 
> So either by reading the docs or running into the error, the user will have a 
> clear explanation and a clear and convenient solution.
> 
> --
> nosy: +andrei.avk
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Some observations:

 - sort_keys arg does a deep sorting of nested dictionaries. It's a bit too 
much to ask users to do this type of preprocessing manually before dumping to 
json.

 - the error doesn't seem too onerous to me. 'unorderable types: str() < int()' 
If uncertain, a user can go to interactive shell and try `1 < "2"`, and then 
the issue is obvious.

 - to me, current behaviour seems preferable to silently guessing that users 
wants stringified sorting, especially since it can surface as a problem way 
down the line.

 - what makes this issue interesting is that in roughly half of cases (I'm 
guessing) the user will want object sorted and then cast to string and would be 
surprised if the reverse happened, and in the other half cases the user would 
want them stringified, then sorted, and would be surprised if that didn't 
happen.

It depends on the perspective: you may think of the json as a representation of 
a dict of objects, that just happen to be in json format; or you can think of 
it as a json document with string keys (of course) that just happen to come 
from a dict of objects. Both can be valid depending on the use case.

Given all of this, I propose keeping current behavior for the existing arg, and 
adding another arg for 'stringify then sort' behavior. Then we'll have no 
silent guessing and the "unorderable" type error message can point the user 
directly to the new argument.

If the user reads the docs before using this method, they will see two clear 
options with respective tradeoffs and decide which one to use.

So either by reading the docs or running into the error, the user will have a 
clear explanation and a clear and convenient solution.

--
nosy: +andrei.avk

___
Python tracker 

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

[issue43219] shutil.copy raises IsADirectoryError when the directory does not actually exist

[Gregory P. Smith]

Change by Gregory P. Smith :


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

[issue43838] There is a way to access an underlying mapping in MappingProxyType

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy: +gvanrossum

___
Python tracker 

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

[issue40897] Inheriting from class that defines __new__ causes inspect.signature to always return (*args, **kwargs) for constructor

[Mauricio Villegas]

Mauricio Villegas  added the comment:

I think this is affecting me or it is a new similar issue. And it is not only 
for python 3.9, but also from 3.6 up. I am working on making code configurable 
based on signatures (see 
https://jsonargparse.readthedocs.io/en/stable/#classes-methods-and-functions). 
Now we need this to work for datetime.timedelta which defines parameters in 
__new__ instead of __init__. The following happens:

>>> from datetime import timedelta
>>> import inspect
>>> inspect.signature(timedelta.__new__)

>>> inspect.signature(timedelta.__init__)

>>> inspect.signature(timedelta)
...
ValueError: no signature found for builtin type 

I am expecting to get parameters for days, seconds, microseconds, milliseconds, 
minutes, hours and weeks, see 
https://github.com/python/cpython/blob/bfe544d2f2c2e7a7c03a764bed3276a1e27a0f5c/Lib/datetime.py#L461-L462.

Hopefully this gives some insight into what should be done. Independent from 
the fix, I would like to know if currently there is any way I can get the 
signature for __new__ that I could use until there is a proper fix for it.

--
nosy: +mauvilsa

___
Python tracker 

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

[issue43124] [security] smtplib multiple CRLF injection

[Alireza Pourali]

Change by Alireza Pourali :


--
components:  -email
type: security -> performance
versions:  -Python 3.10, Python 3.6, Python 3.7, 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

[issue43299] pyclbr.readmodule_ex traversing "import __main__": dies with ValueError: __main__.__spec__ is None / is not set

[Robert]

Robert  added the comment:

You see the usecase from the stack trace: PythonWin (the IDE from pywin32 
package) uses pyclbr - to inspect arbitrary user code.  
(Neither code is from me)

I'm not inspecting __main__ explicitely. The problem seems to arise in newer 
Python versions (3.10+?) because the class browser now seems to parse imports 
somehow recursively (_readmodule() several times in the stack trace) and when 
user code somewhere contains e.g. "import __main__" ...


pyclbr should perhaps handle (not fail in) all legal cases w/o breaking: when 
some strange builtin/extension/artificial has .__spec__ as None or not set or 
no python code. (We cannot force any user code to monkey patch 
__main__.__spec__ or potential other modules.)

>>> mod = types.ModuleType('mymod')
>>> mod.__spec__
# (None)
>>> 

importlib.util._find_spec_from_path() has choosen to raise ValueError instead 
of an extra custom Error (or a special return value) for those cases and to 
return None for the similar case of 'not found') . Though those 3 cases are 
similiar in consequence here.  pyclbr also "cheaply abuses" ImportError / 
ModuleNotFound to translate one of those cases (None return value) for internal 
signaling. (There is never a real ImportError just remote linguistic similarity 
;-) ) 

Hence the simple pragmatic fix by kind of reunification of signaling the "end 
of the game" here - as the way of signaling here is anyway rather pragmatic and 
evolution style.

ValueError is often (ab)used to signal application level errors "cheaply" (to 
not define and distribute an extra Exception type) - and its a limited internal 
case here where mix-up with errors from something like "math.sqrt(-1)" is not 
possible w/o coding bugs (which are to be detected by tests)

But you may establish a more meticulous error / return value signaling system - 
which though will require changes / refactoring in several places and 
consideration for compatibility ...
(Think its hardly worth it)

--

___
Python tracker 

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

[issue44597] Poll returns POLLOUT on Pipe read endpoint on MacOS 10.14

[Sam Harding]

New submission from Sam Harding :

The behaviour of select.poll() is inconsistent across MacOS versions, on MacOS 
Mojave (10.14.6) registering and polling the receiving channel of 
mp.Pipe(duplex=False) returns the event POLLOUT (ready to write to). This is 
verified by a colleagues setup.

Whereas on MacOS 11 the same scenario will not have poll() return that the 
receiving channel is ready for writing to (POLLOUT). 

Example:
###
import select
import multiprocessing as mp
recv_end, send_end = mp.Pipe(duplex=False)
poll = select.poll()
poll.register(recv_end)
print(poll.poll(1000))
###

MacOS 10.14.6 Result: 
> [(3,4)]

MacOS 11.0.1 Result:
> []

I am assuming that the MacOS 11 behaviour is should be the expected behaviour, 
and that the recv connection from a Pipe should never return that it is 
writable.

This was tested with Python 3.9.4, and 3.7.6.

--
components: Extension Modules, macOS
messages: 397246
nosy: ned.deily, ronaldoussoren, samh42
priority: normal
severity: normal
status: open
title: Poll returns POLLOUT on Pipe read endpoint on MacOS 10.14
type: behavior
versions: Python 3.7, Python 3.9

___
Python tracker 

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

[issue43838] There is a way to access an underlying mapping in MappingProxyType

[Nick Coghlan]

Nick Coghlan  added the comment:

I stumbled across this independently in bpo-44596, but missed this existing 
report due to the specific word I was looking for (encapsulation).

In addition to the comparison operand coercion, there's now another access 
option through the `__ror__` method.

The bug in both cases arises from delegating a method/function implementation 
to the underlying mapping type in a way that invokes the full operand coercion 
dance. (PyObject_RichCompare in one case, PyNumber_Or in the other)

Delegating these operations to the underlying mapping does make sense, but it 
needs to be a lower level delegation that bypasses the operand coercion dance, 
so the other operand only ever sees the proxy object, not the underlying 
mapping.

--
nosy: +ncoghlan

___
Python tracker 

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

[issue43838] There is a way to access an underlying mapping in MappingProxyType

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Example of modifying a builtin type:

>>> class Sneaky:
... def __eq__(self, other):
... other['real'] = 42
... 
>>> int.__dict__ == Sneaky()
>>> (1).real
42

But it can also lead to crash (due to outdated type cache):

>>> class Sneaky:
... def __eq__(self, other):
... other['bit_length'] = 42
... 
>>> int.__dict__ == Sneaky()
>>> (1).bit_length
Segmentation fault (core dumped)

--

___
Python tracker 

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

[issue44596] Operand coercion breaks MappingProxyType encapsulation

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is a duplicate of issue43838.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> There is a way to access an underlying mapping in 
MappingProxyType

___
Python tracker 

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