[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

Hello, On Tue, 19 Jan 2021 14:31:49 +1300 Greg Ewing wrote: > On 19/01/21 1:13 pm, Inada Naoki wrote: > > I don't want to import modules used only in type hints. I don't want > > to import even "typing". > > How about having a pseudo-module called __typing__ that is > ignored by the compiler:

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 5:53 PM, Ethan Furman wrote: `__prepare__` returns a dict-like namespace that is used as is.  `EnumMeta` uses `__prepare__` to return an instance of `_EnumDict`. When `type.__new__` is called, whatever the namespace used to be is then converted into a normal Python dict, and a mapp

[Python-Dev] Re: Should python installation modify /etc/paths.d on Mac OS X?

Ned Deily writes: > On Jan 14, 2021, at 09:22, Peng Yu wrote: >> The /etc/paths.d directory on Mac OS X contains the following >> directory. Some packages have their PATH variables set there. >> >> For Python, I have to set the PATH manually in my ~/.bashrc. Should >> the Python developers cons

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 5:33 PM, Guido van Rossum wrote: There's a secret though. `cls.__dict__` is not actually a dict -- is a mappingproxy. The proxy exists because we want to be able to intercept changes to class attributes such as `__add__` or `__getattribute__` in order to manipulate the C-level wrappe

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 19/01/21 1:13 pm, Inada Naoki wrote: I don't want to import modules used only in type hints. I don't want to import even "typing". How about having a pseudo-module called __typing__ that is ignored by the compiler: from __typing__ import ... would be compiled to a no-op, but recognised by

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Mon, Jan 18, 2021 at 4:34 PM Larry Hastings wrote: > > On 1/18/21 2:39 PM, Guido van Rossum wrote: > > Hm. It's unfortunate that this would break code using what is *currently* > the best practice. > > I can't figure out how to avoid it. The problem is, current best practice > sidesteps the c

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 2:39 PM, Guido van Rossum wrote: Hm. It's unfortunate that this would break code using what is *currently* the best practice. I can't figure out how to avoid it.  The problem is, current best practice sidesteps the class and goes straight to the dict.  How do we intercept that and

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On Tue, Jan 19, 2021 at 8:54 AM Larry Hastings wrote: > > On 1/18/21 3:42 PM, Inada Naoki wrote: > > Many type hinting use cases don't need type objects in runtime. > So I think PEP 563 is better for type hinting user experience. > > You mean, in situations where the user doesn't want to import th

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/18/21 3:42 PM, Inada Naoki wrote: Many type hinting use cases don't need type objects in runtime. So I think PEP 563 is better for type hinting user experience. You mean, in situations where the user doesn't want to import the types, because of heavyweight imports or circular imports? 

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On Tue, Jan 19, 2021 at 6:02 AM Larry Hastings wrote: > > > Oh, okay. I haven't used the static type checkers, so it's not clear to me > what powers they do and don't have. It was only a minor suggestion anyway. > Perhaps PEP 649 will be slightly inconvenient to people exploring their code >

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

Hm. It's unfortunate that this would break code using what is *currently* the best practice. The saving grace seems that for *many* use cases the best practice is to call typing.get_type_hints(). This is particularly useful for classes because it includes annotations from base classes. Also, for

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 12:16 PM, Guido van Rossum wrote: I do worry about the best practice getting worse if your PEP 649 is accepted. A good part of what motivated me to start this second thread ("Let's Fix ...") was how much worse best practice would become if PEP 649 is accepted.  But if we accept P

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/18/21 12:24 PM, Guido van Rossum wrote: On Sun, Jan 17, 2021 at 7:33 AM Larry Hastings > wrote: If your imports are complicated, you could always hide them in a function.  I just tried this and it seems to work fine: def my_imports():    

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On Mon, Nov 23, 2020 at 8:20 AM Brian Coleman wrote: > Take as an example a function designed to process a tree of nodes similar > to that which might be output by a JSON parser. There are 4 types of node: > > - A node representing JSON strings > - A node representing JSON numbers > - A node repr

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On Sun, Jan 17, 2021 at 7:33 AM Larry Hastings wrote: > If your imports are complicated, you could always hide them in a > function. I just tried this and it seems to work fine: > > def my_imports(): > global other_mod > import other_mod > > So, you could put all your imports in such a f

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Sat, Jan 16, 2021 at 3:32 PM Larry Hastings wrote: > [...] If anybody distinguished between "annotations are unset" and > "annotations are set to an empty dict", that code would fail, but I expect > nobody ever does that. > I agree, since I can't think of differing semantics. Given that `__an

[Python-Dev] Re: Should python installation modify /etc/paths.d on Mac OS X?

On Jan 18, 2021, at 08:24, Barry Scott wrote: > One of the things that I wish the python macOS installed would stop doing is > editing my .bashrc/.zshrc etc. > > After each python install I have to undo the edits to .bashrc or .zshrc that > break > my environment. > > I understand the motivatio

[Python-Dev] Re: Unification of the Mac builds?

Thanks Ronald, This is really helpful. -CHB On Fri, Jan 15, 2021 at 5:43 AM Ronald Oussoren wrote: > > > On 14 Jan 2021, at 23:03, Chris Barker via Python-Dev < > python-dev@python.org> wrote: > > Ned, > > Thanks -- I'll take further discussion to the python-mac list. > > Ronald: > > That’s a

[Python-Dev] Re: Should python installation modify /etc/paths.d on Mac OS X?

> On 14 Jan 2021, at 14:22, Peng Yu wrote: > > Hi, > > The /etc/paths.d directory on Mac OS X contains the following > directory. Some packages have their PATH variables set there. > > For Python, I have to set the PATH manually in my ~/.bashrc. Should > the Python developers consider settin