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&q=orderedset&type=Code .
Sadly this search seems to count how my projects put their virtual
environment on GitHub
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 _PyThreadSta
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):
... def
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 exte
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):
... d
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
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 "p
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 lon
(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 quest
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 value
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__() implementat
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
the
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.
I
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, whet
[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 ab
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() doesn'
>
> [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 valu
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:
>
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
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 python-dev-
20 matches
Mail list logo
