Finished creating 2 issues on the meanwhile:
bpo-39264 to fix UserDict.get().
bpo-39267 to fix dict.__missing__ & dict.get() documentation.
Both include a PR.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
Le mer. 8 janv. 2020 à 22:15, Nick Coghlan a écrit :
> The vectorcall convention places a significant emphasis on speed, so
> being able to do a single PyThreadState_Get() call on the initial
> transition from Python to C, and then pass the thread state explicitly
> after that would make a lot of
On Thu, 9 Jan 2020 at 01:49, Victor Stinner wrote:
> The question is now if we should "propagate" tstate to function calls
> in the latest VECTORCALL calling convention (which is currently
> private). Petr Viktorin plans to make VECTORCALL APIs public in Python
> 3.9, as planned in the PEP 590:
>
>
> [Bar Harel]
> > As for get(). Current implementation of UserDict returns the default
> value
> > for get() if __missing__() raises KeyError. Which sounds reasonable to
> me.
> > After all, you would logically expect __missing__ to be called for get()
> > as you tried to get a non-existing
On Wed, Jan 8, 2020 at 12:02 PM Ethan Furman wrote:
> I disagree. My understanding of the purpose behind get() is to get a value
> or return the default specified in the get() call, not to create a new key
> (which the default __missing__ does).
>
Right. For comparison, defaultdict.get()
[Bar Harel]:
I was just about to fix dict's get() to call __missing__ if a key doesn't
exist (before returning the default value) but realized that although small,
that patch can cause future issues. Right now there's an inconsistency:
The reason for this inconsistency is because the Mapping
Sounds good to me.
If you want a second opinion als Raymond Hettinger.
On Wed, Jan 8, 2020 at 11:09 Bar Harel wrote:
> Well it depends on the consensus for __missing__, and the consensus for
> get().
>
> I believe modifying get() is out of the question as it will lead to
> breakage. If so,
On Wed, Jan 08, 2020 at 12:26:39PM +0100, Musbur wrote:
> I'm experimenting with package development on different versions of Python
> in different virtualenvs. After running "make" I don't do "make install",
> but rather I set up virtualenvs by running /path/to/source/python -m venv
> env_dir.
Well it depends on the consensus for __missing__, and the consensus for
get().
I believe modifying get() is out of the question as it will lead to
breakage. If so, whether it's a quirk or not doesn't matter as we can't
change it. Adding a comment to the docs should suffice, along with updating
Hum, it looks like the UserDict.get() behavior is an accident due to the
way Mapping.get() is implemented. The comment there says
'D.get(k[,d]) -> D[k] if k in D, else d. d defaults to None.'
but the implementation just tries D[k] and catches KeyError. The
UserDict.__contains__()
Sorry for the double post then :-)
As for get(). Current implementation of UserDict returns the default value
for get() if __missing__() raises KeyError. Which sounds reasonable to me.
After all, you would logically expect __missing__ to be called for get() as
you tried to get a non-existing
(Note: We received your email twice.)
I don't think __missing__ should be called by get() -- get() already has a
way to deal with missing keys, and making it use two different mechanisms
would be weird (e.g. if get() calls __missing__, is the default value ever
used?).
To answer your second
On 08.01.2020 14:26, Musbur wrote:
Hello,
I'm experimenting with package development on different versions of Python in different virtualenvs. After running "make" I don't do "make
install", but rather I set up virtualenvs by running /path/to/source/python -m venv env_dir. This works for as
Hi,
I dislike python-config for multiple reasons
You may get the wrong information if you pick the wrong python-config script :-(
IMHO we should add a new module (problem: how should it be called?
pyconfig?) which could be used using "python3 -m xxx ...". There is a
similar discussion between
On 08Jan2020 0746, Victor Stinner wrote:
The question is now if we should "propagate" tstate to function calls
in the latest VECTORCALL calling convention (which is currently
private).
+1, for all the same reasons I'm +1 on passing it to C functions
explicitly. (In short, embedding can be very
Hey guys,
I was just about to fix dict's get() to call __missing__ if a key doesn't exist
(before returning the default value) but realized that although small, that
patch can cause future issues.
Right now there's an inconsistency:
>>> from collections import UserDict
>>> class A(dict):
...
Hello,
I'm experimenting with package development on different versions of
Python in different virtualenvs. After running "make" I don't do "make
install", but rather I set up virtualenvs by running
/path/to/source/python -m venv env_dir. This works for as long as I
don't need to compile
Hey guys,
I was just about to fix dict's get() to call __missing__ if a key doesn't
exist (before returning the default value) but realized that although
small, that patch can cause future issues.
Right now there's an inconsistency:
>>> from collections import UserDict
>>> class A(dict):
...
Hi,
I started to modify Python internals to pass explicitly the Python
thread state ("tstate") to internal C a functions:
https://vstinner.github.io/cpython-pass-tstate.html
Until subinterpreters will be fully implemented, it's unclear if
getting the current Python thread state using
Le mer. 8 janv. 2020 à 07:02, Kyle Stanley a écrit :
> A more generalized Python code search across GitHub of "orderedset" returns
> ~500k results: https://github.com/search?l=Python=orderedset=Code .
Sadly this search seems to count how my projects put their virtual
environment on GitHub.
20 matches
Mail list logo
