Given that it's now presumably preferred spelling is `str | None` in
Python 3.10, why would we not seek to deprecate `Optional[str]` instead
of inventing a replacement?
On Thu, 2022-06-30 at 17:15 +, nveric...@gmail.com wrote:
> I am aware this is clarified in the Python documentation for the
Thanks, Carl and Larry for the explanations.
On Sun, 2022-05-01 at 16:13 -0600, Carl Meyer wrote:
> Hi Paul,
>
> On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote:
> >
> > Can someone state what's currently unpalatable about 649? It seemed
> > to address the forward-re
Can someone state what's currently unpalatable about 649? It seemed to
address the forward-referencing issues, certainly all of the cases I
was expecting to encounter.
On Sun, 2022-05-01 at 15:35 -0600, Larry Hastings wrote:
>
> FWIW, I'm in agreement. My "forward class" proposal(s) were me
>
d pointers being 8 bytes nowadays).
I created objects in a tight loop, populating attributes, noting the
elapsed time.
> I agree that dicts are a use case to preserve.
>
> On Fri, Mar 18, 2022 at 08:59 Paul Bryan wrote:
> > You've proposed a "what", but I don't see
You've proposed a "what", but I don't see a "why".
Indeed, it will break some code.
I've been (currently legally) expressing __slots__ as sets, which is
arguably more consistent with its purpose, and in testing appeared to
perform better than tuples.
So, I would request that you amend the
"Exactly the same" between Python versions, or exactly the same as
previously reported?
On Sun, 2021-12-19 at 18:48 +, Tigran Aivazian wrote:
> To eliminate the possibility of being affected by the different
> versions of numpy I have just now upgraded numpy in Python 3.8
> environment to the
On Wed, 2021-11-10 at 17:16 +1100, Steven D'Aprano wrote:
> On Tue, Nov 09, 2021 at 10:01:35PM -0800, Christopher Barker wrote:
> > Maybe a stupid question:
> >
> > What are use cases for sorted dicts?
> >
> > I don’t think I’ve ever needed one.
>
> Good question :-)
It could be handy for
NoneType is just another type, and in type checking scenarios should be
expressed with `Optional[type]` or more preferably in the future `type
| None`; `None` is not a non-value. Assuming what I just wrote is true,
I don't get what the basis of this thread is; what am I missing?
On Mon,
The way I see it, the concurrency model to be used is selected by
developers. They can choose between multi-threading, multi-process, or
asyncio, or even a hybrid. If developers select multithreading, then
they carry the burden of ensuring mutual exclusion and avoiding race
conditions, dead locks,
The docs for __class_getitem__ are here:
>
> https://docs.python.org/3/reference/datamodel.html#emulating-generic-types
>
> I think the Data Model chapter is the right place for it.
>
> Cheers,
>
> Luciano
>
> On Thu, May 6, 2021 at 2:14 AM Paul Bryan wrote:
> &g
I'm looking through the documentation, and not finding any good
reference for type hints for __class_getitem__ in the collections.abc
module.
I do see some of it covered in the typing module documentation, but
those are deprecated, and some are somewhat cryptic (e.g. Coroutine).
Make sense to
I think one of the issues is that BZ2File accepts the filename as a
name or as a file-like object!
I don't see why it couldn't be enhanced to provide the filename though
(by pulling it from the fp). Meanwhile, the ugly way to get the
filename from a BZ2File object:
pbryan@dynamo:~$ python3
quack", "waddle")]`?
Paul
On Wed, 2021-04-21 at 16:13 -0700, Jelle Zijlstra wrote:
>
>
> El mié, 21 abr 2021 a las 15:30, Paul Bryan ()
> escribió:
> > As demonstrated, protocols don't get us there because duck typing
> > isn't a matter of having an object e
As demonstrated, protocols don't get us there because duck typing isn't
a matter of having an object exhibit all of the attributes of a duck,
but rather some subset of attributes to be used by the consumer. I want
this duck to quack; someone else will want it to waddle. I don't see
how type hints
I've been working on a similar framework, Fondat [1], that shares
similar objectives as Pydantic and FastAPI, albeit implementing in a
different manner.
I believe other frameworks will have to "run a gauntlet" (as I already
have) to deal with the affects of PEP 563. If anyone on these teams
are
https://docs.python.org/3/reference/datamodel.html
On Wed, 2021-04-14 at 22:56 +, Jim J. Jewett wrote:
> Paul Moore wrote:
> > What's wrong with Version(module.__version__)? And if the
> > __version__
> > attribute isn't a valid version, raise an exception?
>
> I don't have a deep answer,
Seems like this is something that should make its way into stdlib?
On Thu, 2021-04-15 at 00:15 +0200, Antoine Pitrou wrote:
> On Wed, 14 Apr 2021 22:23:44 +0100
> Paul Moore wrote:
> > On Wed, 14 Apr 2021 at 21:59, David Mertz wrote:
> > >
> > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore
> >
On Wed, 2021-04-14 at 22:42 +0200, Baptiste Carvello wrote:
> That's assuming the syntax in the annotations doesn't diverge too
> much
> from the Python syntax as far as brackets etc are concerned. I must
> say
> I'm not too worried about typing. But the hypothetic "def foo(prec:
> --precision
:47 AM Paul Bryan wrote:
> > I favour annotations for type hints; the writing's been on the wall
> > for some time. I think the necessary escape hatch for those using
> > it for other purposes should be Annotated[Any, ...] (or a similar,
> > nicer alternative).
> >
&
I favour annotations for type hints; the writing's been on the wall for
some time. I think the necessary escape hatch for those using it for
other purposes should be Annotated[Any, ...] (or a similar, nicer
alternative).
Guido, one of the difficulties I'm having is understanding the
direction
On Mon, 2021-04-12 at 19:52 -0700, Guido van Rossum wrote:
> Why not submit a PR that adds caching to get_type_hints(), rather
> than promote a paradigm shift?
A couple of reasons:
1. In reviewing the code, I didn't find an obvious way to store cached
values. Anything but a non-trivial change
On Tue, 2021-04-13 at 11:33 +0900, Inada Naoki wrote:
> On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan wrote:
> >
> > On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
> >
> > On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings
> > wrote:
> >
> >
&g
On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
> On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings
> wrote:
> > This is really the heart of the debate over PEP 649 vs PEP 563. If
> > you examine an annotation, and it references an undefined symbol,
> > should that throw an error? There is
On Sun, 2021-04-11 at 23:34 -0700, Larry Hastings wrote:
> Your example was valid, and I think your workaround should be fine.
> Do you have a use case for this, or is this question motivated purely
> by curiosity?
It took a few readings for me to understand the limitations in the PEP.
My
I'm in favour of the approach proposed in PEP 649.
Movie trailer: "In a world where annotations are arbitrary non-Python
syntax..."
It seems to me we could always have annotations evaluate to Python
expressions *and* support any arbitrary syntax (e.g. through
Annotated[...] or similar
I like! I really appreciate the work you've put into this to get it
this far.
Questions and comments:
> PEP 563 also requires using ``eval()`` or ``typing.get_type_hints()``
> to examine annotations. Code updated to work with PEP 563 that calls
> ``eval()`` directly would have to be updated
I suggest that SHA224 does not qualify as "SHA256 or better".
Truncating any hash should not be considered equivalent or better.
Reductio ad absurdum: truncate to 128 bits, 16 bits, 8 bits, or 1 bit.
On Mon, 2021-03-29 at 08:15 +, Theallredman via Python-Dev wrote:
> No need to be
I did learn something today!
On Fri, 2021-03-19 at 10:37 -0700, Guido van Rossum wrote:
> I was only talking about the two-argument version, iter(x, sentinel).
> Betcha you didn’t even know that existed. :-)
>
> On Fri, Mar 19, 2021 at 10:34 Paul Bryan wrote:
> > On Fri, 2
On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:
> I’m not convinced that we need aiter(x, sentinel) at all — for iter()
> it’s mostly a legacy compatibility API.
I'm feel like I'm going to learn something today. To date, the pattern
I've used for getting the first item from an
Sample size of 1: I have code calling __aiter__ and __anext__. It would
be nice to have representative functions—in some module—for the 3.10
release.
I would think the bar for inclusion in builtins should be quite high.
Looking at what's in the operator module, it does seem like a more
Google tells me...
From https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask
:
> We are then going to modify the file on both the master and slave
> repository and then merge the work.
This particular passage was also cited in GNOME developer discussions
regarding the usage of
I don't think it's particularly constructive, even as a strawman, to
imagine every conceivable way some word could be interpreted as
offensive. I submit that if the community consensus is that "chain"
becomes a derogatory term, then we should agree to change it too.
On Thu, 2021-03-11 at 08:23
On Thu, 2021-03-11 at 02:20 +1100, Chris Angelico wrote:
> It is NOT a general convention. It is a push by Microsoft (owners of
> GitHub). Outside of GitHub, the git command still uses "master" as
> the
> default name.
I agree, not yet. But I think the writing is on the wall that this will
be
While, I agree "master" is not and should not be considered a
derogatory term—it has demonstrable valid usage—unfortunately the broad
usage of "master/slave" terminology in technology muddies the waters.
If it's not changed, the debate about the continuing to use the term
will likely be ongoing.
Perhaps refine the packaging nomenclature to be "local development
mode"?
On Fri, 2021-02-26 at 18:34 +, Coyot Linden wrote:
> As of 3.7, there is now a python feature called Development Mode:
>
> https://docs.python.org/3/library/devmode.html#devmode
>
> Which has a confusingly similar and
I think it's a classic case of dependency hell.
OS packagers are rebundling Python packages as OS packages and
expressing their own OS-package dependency graphs. Then, you sudo pip
install something that has a conflicting dependency, it bypasses OS
packaging, and *boom*.
I find tools like pipx
:
> https://docs.python.org/dev/using/cmdline.html#environment-variables
>
> So I prefer PYTHONWARNDEFAULTENCODING env var and
> sys.flags.warn_default_encoding attribute names.
>
> Victor
>
> On Fri, Feb 19, 2021 at 9:48 AM Inada Naoki
> wrote:
> >
> > O
Let the bikeshedding begin. How about with the underscores in place?
More readable to my eyes.
On Mon, 2021-02-15 at 14:28 +0900, Inada Naoki wrote:
> I am updating PEP 597 to include discussions in the thread.
> Before finishing the PEP, I need to decide the option name.
>
> I used
I'm a +1 on using Annotated in this manner. Guido mentioned that it was
intended for only third-parties though. I'd like to know more about why
this isn't a good pattern for use by Python libraries.
On Sun, 2021-02-14 at 16:29 +0100, Adrian Freund wrote:
> Here's another suggestion:
>
> PEP 593
-13 at 10:58 +1300, Greg Ewing wrote:
> On 13/02/21 9:03 am, Paul Bryan wrote:
> > What if PSF were to undertake codifying a language specification?
>
> We have the Language Reference and Library Reference. Do they
> not count
What if PSF were to undertake codifying a language specification?
On Fri, 2021-02-12 at 11:57 -0800, Dan Stromberg wrote:
>
> On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev
> wrote:
> > How a standard by ANSI, ECMA and/or ISO is any better than a
> > standard by the PSF?
> >
>
>
>From my point of view, the process of standardizing through a formal
standards body is a tedious, verbose, laborious, bureaucratic and
often contentious process.
I'd really like to know quantitatively what the benefits would be of
running that gauntlet, as I'm not sure they would outweigh the
For what it's worth, I've increasingly considered creating a context in
a generator (sync or async) to be an antipattern. To this end, in my
case, I moved creation of the context outside of the generator. This
resulted in a more explicit contract, which actually simplified
reasoning about its
On Sat, 2021-02-06 at 22:05 -0300, Luciano Ramalho wrote:
> The initial pattern matching syntax and semantics with its many
> corner
> cases may be incompatible with a future way of doing pattern matching
> that is better.
Then that future incompatible way should be marked with __future__, not
On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
> A __future__ import would make clear to all that the feature is
> experimental, and maybe there could be __future__ imports for
> different parts of the proposal.
That's not my understanding. My understanding is __future__ is meant
for
I like.
On Wed, 2021-02-03 at 15:48 -0800, Guido van Rossum wrote:
> Anyone? I'm +1 on this PEP as it is, and I imagine a few other core
> devs are too (Brandt, Steven). If nobody responds before the end of
> the week I think we can say that there was no disagreement and
> Stefano can submit PEP
Would annotations() just access the dunder, like other builtins (and
then result in the descriptor resolving __co_annotations__ as
proposed), or would calling it be required to actually resolve
__co_annotations__? I think it should probably be the former.
On Sat, 2021-01-16 at 12:29 +1300, Greg
I knew I was missing something. Agree, annotations are not necessarily
type hints.
On Fri, 2021-01-15 at 10:56 -0800, Larry Hastings wrote:
>
> On 1/15/21 10:12 AM, Paul Bryan wrote:
>
> > I wonder if then the __co_annotations__ call and overwriting of
> > __annotations__
confronted with an exception raised within __co_annotations__.
On Fri, 2021-01-15 at 09:47 -0800, Larry Hastings wrote:
>
> On 1/11/21 6:34 PM, Paul Bryan wrote:
>
> On Mon, 2021-01-11 at 17:56 -0800, Larry Hastings wrote:
>
>
> > On 1/11/21 5:02 PM, Paul Bryan wrote:
>
On Tue, 2021-01-12 at 20:09 -0800, Guido van Rossum wrote:
> On Tue, Jan 12, 2021 at 8:00 PM Brett Cannon
> wrote:
> >
> > > * It turns a None annotation into type(None). Which means now
> > > you
> > > can't tell the difference between "None" and "type(None)".
> > >
> > Huh, I wasn't aware of
On Tue, 2021-01-12 at 09:54 -0800, Larry Hastings wrote:
> Note that this only works in the current version of the PEP /
> prototype, where annotations are strictly evaluated in module scope.
> If we start supporting closures, those need "cell" objects, which
> IIUC can't be marshalled.
Since the
Will do.
On Mon, 2021-01-11 at 20:55 -0800, Guido van Rossum wrote:
> On Mon, Jan 11, 2021 at 3:51 PM Larry Hastings
> wrote:
> > [...]
> > > This passage in PEP 563 appears not true in Python 3.9 with
> > > __future__ annotations, emphasis mine:
> > >
> > > > The get_type_hints() function
On Mon, 2021-01-11 at 17:56 -0800, Larry Hastings wrote:
> On 1/11/21 5:02 PM, Paul Bryan wrote:
>
> >
> > Some more questions...
> >
> > "Binding"," bound" and "unbound" code objects:
> > Is your use of "binding" te
ble in __annotations__, and use the descriptor to resolve it to
a dictionary and store it when it is accessed? It would be one less
dunder in the Python data model.
On Mon, 2021-01-11 at 15:46 -0800, Larry Hastings wrote:
>
> On 1/11/21 3:02 PM, Paul Bryan wrote:
>
> > PEP 563 do
On Mon, 2021-01-11 at 13:16 -0800, Larry Hastings wrote:
>
> Thanks for your feedback! I'll reply piecemeal.
>
> On 1/11/21 12:32 PM, Paul Bryan wrote:
>
> > 1. Backwards Compatibility
> >
> >
> > > PEP 563 changed the semantics of annota
I'm very much in favour of the this concept. A few points come to mind
right away:
1. Backwards Compatibility
> PEP 563 changed the semantics of annotations. When its semantics are
> active, annotations must assume they will be evaluated inmodule-level
> scope. They may no longer refer directly
My code pretty much does what you suggest at the end of your message:
On Mon, 2021-01-11 at 09:22 -0800, Larry Hastings wrote:
> Or code can just use inspect.get_type_hints(), which is tied to the
> Python version
> anyway and should always do the right thing.
So far, this has proven mostly[1]
I've now experienced an issue I believe that PEP 533 was intended to
address:
When an asynchronous context manager is created within an asynchronous
generator, if the generator is not iterated fully, the context manager
will not exit until the event loop cancels the task by raising a
Should this be considered a bug in the Enum implementation?
>>> class Foo(enum.Enum):
... A = True
... B = 1
... C = 0
... D = False
...
>>> Foo.A
>>> Foo(True)
>>> Foo(1)
Seems to me like it should store and compare both type and value.
Paul
ou'll see that they are completely runtime introspectable.
> (Believe me, it would have been much simpler to erase type parameters
> completely at runtime, but I personally wrote most of the
> implementation to make them available via attributes on the
> `types.GenericAlias` type
Per PEP 563:
> Most importantly, Guido van Rossum explicitly stated interest in
> gradually restricting the use of annotations to static typing (with
> an optional runtime component).
As I'm working on runtime type encoding and validation using type
annotations, this passage raises a bit of a
time.
On Tue, 2020-12-08 at 21:49 -0800, Guido van Rossum wrote:
> On Tue, Dec 8, 2020 at 8:58 PM Paul Bryan wrote:
> > My use case is to for type annotations to resolve type encoders,
> > decoders and validators at runtime.
> >
>
>
> What is the reason you can
assume "Boom" with that
> NameError again? (On a phone, can't try it now)
>
> I believe this isn't a problem get_type_hints() can ever solve.
>
> Code that does this isn't what I'd call "reasonably" structured for
> use with type hints.
>
> If anythin
n3.9/typing.py", line 254, in _eval_type
return t._evaluate(globalns, localns, recursive_guard)
File "/usr/lib/python3.9/typing.py", line 493, in _evaluate
eval(self.__forward_code__, globalns, localns),
File "", line 1, in
NameError: name 'B' is not defined
It appears that when from future import __annotations__, a type hint
annotation derived from a closure loses scope.
Simplistic example:
Python 3.9.0 (default, Oct 7 2020, 23:09:01)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def
Is this the expected behavior?
Python 3.9.0 (default, Oct 7 2020, 23:09:01)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import typing
>>> TD = typing.TypedDict("TD", {"a": str}, total=False)
>>> TD.__total__
False
>>> TD.__required_keys__
Per PEP 515:
> It is a SyntaxError to have a non-empty return statement in an
> asynchronous generator.
Synchronus generators can return values that include it in the
StopIteration exception. Why would a return value in an asynchronous
generator not do the same in the StopAsyncIteration?
67 matches
Mail list logo
