On Thu, Oct 21, 2021 at 5:24 PM Steven D'Aprano wrote:
> Runtime type checkers already have to deal with forward refs that are
> strings, as this is legal, and always will be:
>
> def function(arg:'Spam') -> Any: ...
>
> so we're not putting any extra burden on them. And we had already
> agre
On 10/21/21 1:17 AM, Steven D'Aprano wrote:
On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote:
In Python, if you evaluate an undefined name, Python raises a
NameError. This is so consistent I'm willing to call it a "rule".
Various folks have proposed an exception to this "rule":
On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote:
> In Python, if you evaluate an undefined name, Python raises a
> NameError. This is so consistent I'm willing to call it a "rule".
> Various folks have proposed an exception to this "rule": evaluating an
> undefined name in an P
I’ve just published the August steering council update, also included below:
https://github.com/python/steering-council/blob/main/updates/2021-08-steering-council-update.md
Just as a reminder, if you have any questions or concerns, feel free to
contact us or open an issue in the SC repo:
https://
Hey,
I would like to proposing adding a vendor configuration. You can find the
proposal in the link below.
https://gist.github.com/FFY00/625f65681fbcd7fc039dd4d727bb2c2f
It is essentially bpo-43976 + bpo-44982, and it is partly implemented in
GH-25718.
Cheers,
Filipe Laíns
signature.asc
Desc
It's certainly not my goal to be misleading. Here's my perspective.
In Python, if you evaluate an undefined name, Python raises a
NameError. This is so consistent I'm willing to call it a "rule".
Various folks have proposed an exception to this "rule": evaluating an
undefined name in an PE
> On 20 Oct 2021, at 15:18, Thomas Wouters wrote:
>
> (For visibility, posted both to python-dev and Discourse.)
Since this got split into Discourse and python-dev, I wrote my take on the
issue on the blog so that I could post it in both spaces with proper formatting
and everything:
https:/
On Thu, Oct 21, 2021 at 10:35 AM Larry Hastings wrote:
> .
>
> Your proposal is one of several suggesting that type annotations are
> special enough to break the rules. I don't like this idea. But you'll be
> pleased to know there are a lot of folks in the "suppress the NameError"
> faction, in
El jue, 21 oct 2021 a las 10:25, David Mertz, Ph.D. ()
escribió:
> I've moved this to python-ideas where it is more appropriate, as Chris
> notes
>
> On Thu, Oct 21, 2021, 8:42 PM Chris Angelico wrote:
>
>> On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
>> wrote:
>> >
>> > On Thu, Oct 21, 20
On Thu, Oct 21, 2021 at 12:06 PM Jelle Zijlstra
wrote:
> I would want this for my type checker, pyanalyze. I'd want to get the raw
> annotation and turn it into a type. For example, if the annotation is
> `List[SomeType]` and `SomeType` is imported in `if TYPE_CHECKING`, I'd at
> least still b
El jue, 21 oct 2021 a las 10:31, Carl Meyer () escribió:
> On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
> wrote:
> > Sorry for the naive question but why doesn't "TYPE_CHECKING" work under
> PEP 649?
> >
> > I think I've seen others mention this but as the code object isn't
> executed until inspe
On 10/21/21 5:42 PM, Damian Shaw wrote:
Sorry for the naive question but why doesn't "TYPE_CHECKING" work
under PEP 649?
I think I've seen others mention this but as the code object isn't
executed until inspected then if you are just using annotations for
type hints it should work fine?
Ye
On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
wrote:
> Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP
> 649?
>
> I think I've seen others mention this but as the code object isn't executed
> until inspected then if you are just using annotations for type hints it
> s
I've moved this to python-ideas where it is more appropriate, as Chris
notes
On Thu, Oct 21, 2021, 8:42 PM Chris Angelico wrote:
> On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
> wrote:
> >
> > On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano
> wrote:
> >>
> >> On Tue, Oct 19, 2021 at 05:0
Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP
649?
I think I've seen others mention this but as the code object isn't executed
until inspected then if you are just using annotations for type hints it
should work fine?
Is the use case wanting to use annotations for ty
On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
wrote:
>
> On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano wrote:
>>
>> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
>> > None and its ilk often conflate too many qualities. For example, is it
>> > missing because it doesn't exi
On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano wrote:
> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
> > None and its ilk often conflate too many qualities. For example, is it
> > missing because it doesn't exist, it never existed, or because we never
> > received a value, desp
Last year I opened the following issues, to implement
int PyObject_CopyToObject() and PyObject *PyObject_GetMemoryView(PyObject
*obj).
They were meant to be as part of PEP 3118, I wonder if they are worth an
effort now.
https://bugs.python.org/issue39835
https://bugs.python.org/issue39836
Joanna
On 10/21/21 5:01 AM, Henry Fredrick Schreiner wrote:
PEP 649 was about the same as the current performance, but PEP 563 was
significantly faster, since it doesn’t instantiate or deal with
objects at all, which both the current default and PEP 563 do.
I don't understand what you're saying abou
Well, I discussed this issue hundreds of times with Victor Stinner.
I believe that this is what we have to go even if there is a very
little minor performance issue, it will be not a big hurdle.
we can see the benchmark from https://speed.python.org/ and CPython become
faster and faster.
Convertin
On Wed, Oct 20, 2021 at 10:58 AM Petr Viktorin wrote:
> I think this info should be in the PEP.
Ok, we added (and completed) the list to the PEP:
https://www.python.org/dev/peps/pep-0670/#macros-converted-to-functions-since-python-3-8
> If the PEP is rejected, would all these previous changes ne
On Thu, Oct 21, 2021 at 10:49:35AM +0200, Baptiste Carvello wrote:
> > Versions of this that rely on catching AttributeError are simply wrong
> > and are an anti-pattern. They catch too much and silently turn
> > errors into silent wrong behaviour.
> >
> > PEP 505 does not fall into that trap.
On Thu, Oct 21, 2021 at 01:46:27PM +1100, Steven D'Aprano wrote:
> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
> > If the motivation for this operator is chained lookups, how about adding a
> > feature to the operator module, first? It seems natural to add a
> > keyword-only arg
Hello,
Le 21/10/2021 à 07:59, Steven D'Aprano a écrit :
>
> Versions of this that rely on catching AttributeError are simply wrong
> and are an anti-pattern. They catch too much and silently turn
> errors into silent wrong behaviour.
>
> PEP 505 does not fall into that trap.
This is not true
24 matches
Mail list logo
