Re: [Python-ideas] Problems (and solutions?) in writing decorators
Also: @something def fun(): ... Is exactly the same as: def fun() ... fun = something(fun) So you can’t make a distinction based whether a given usage is as a decoration. -CHB On Tue, Mar 19, 2019 at 12:26 PM Greg Ewing wrote: > Sylvain MARIE via Python-ideas wrote: > > `my_decorator(foo)` when foo is a callable will always look like > > `@my_decorator` applied to function foo, because that's how the language > is > > designed. > > I don't think it's worth doing anything to change that. Everywhere > else in the language, there's a very clear distinction between > 'foo' and 'foo()', and you confuse them at your peril. I don't see > why decorators should be any different. > > -- > Greg > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] True and False are singletons
On 18Mar2019 08:10, Eric Fahlgren wrote: On Mon, Mar 18, 2019 at 7:04 AM Rhodri James wrote: On 18/03/2019 12:19, Richard Damon wrote: > On 3/18/19 7:27 AM, Greg Ewing wrote: >> Juancarlo Añez wrote: >> >>> if settings[MY_KEY] is True: >>> ... >> >> If I saw code like this, it would take a really good argument to >> convince me that it shouldn't be just >> >> if settings[MY_KEY]: >> ... >> > That means something VERY different. The first asks if the item is > specifically the True value, while the second just asks if the value is > Truthy, it wold be satisfied also for values like 1. Yes. And the latter is what people almost always mean. No, it depends heavily on the context. In GUI code, Oleg's example (tri-state checkbox) is a pervasive idiom. There's lots of code that says "if x is True" or "if x is False" or "if x is None" and that's a very clear indicator that you are dealing with these "booleans that can also be 'unset'". Yeah, but on a personal basis I would generally write such an idiom as "if x is None: ... elif x: truthy-action else: falsey-action" i.e. only rely on a singleton for the "not set" sentinel (usually None, occasionally something else). Cheers, Cameron Simpson ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Sylvain MARIE via Python-ideas wrote: `my_decorator(foo)` when foo is a callable will always look like `@my_decorator` applied to function foo, because that's how the language is designed. I don't think it's worth doing anything to change that. Everywhere else in the language, there's a very clear distinction between 'foo' and 'foo()', and you confuse them at your peril. I don't see why decorators should be any different. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Antoine Pitrou wrote: You are being idealistic here. MyPy relies on typing hints being available, and sufficiently precise. Yes, but it doesn't require type hints for *everything*. Given enough starting points, it can figure out the rest. Mathematicians rely heavily on their readers being able to do the same thing. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] function annotation enhancement
Your proposed syntax is hard to implement, because it would require invasive syntax changes to the language itself. That's probably not worth it. However, there are other ways to achieve what you're looking for that don't require changing the language itself. This issue has some proposals: https://github.com/python/mypy/issues/1641. El mar., 19 mar. 2019 a las 14:25, Tim Mitchell (< tim.mitchell.c...@gmail.com>) escribió: > I would like to propose an enhancement to function annotations. Here is > the motivating use case: > When using callbacks I would like to declare the signature once as a type > alias and use it to type hint both the function accepting the callback and > the callbacks themselves. > > Currently I can declare the function signare > > CallbackType = Callable[[int, str], Any] > > and use it for the function/method accepting the callback > > def my_func(callabck: CallbackType): >pass > > however it does not work for the callback itself, I have to repeat myself > > def my_callback(a: int, b: str) -> None: > pass > > and if I change the signature in CallbackType the typechecker has to know > that my_callback will be passed to my_func in order to detect the error. > > I propose to add a new syntax that declares the type of the function after > the function name. > > def my_callback: CallbackType(a, b): > pass > > any further parameter annotations would be disallowed: > > def my_callback: CallbackType(a: int, b: str): # Syntax error - > duplicate annotations > pass > > > If the function parameters do not match the type signare, type hinters > would flag this as a type mismatch. > > def my_callback: CallbackType(a): # type mismatch > pass > > > My original thought was that if CallbackType was not a Callable this would > also be a type error. > However I have since realized this could be used for declaring the return > type of properties: > For example > > class MyClass(object): > @property > def my_prop: int(self) > return 10 > > c = MyClass() > Then c.my_prop would be type hinted as an integer. > > What do people think? > Cheers > Tim > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] function annotation enhancement
I would like to propose an enhancement to function annotations. Here is the motivating use case: When using callbacks I would like to declare the signature once as a type alias and use it to type hint both the function accepting the callback and the callbacks themselves. Currently I can declare the function signare CallbackType = Callable[[int, str], Any] and use it for the function/method accepting the callback def my_func(callabck: CallbackType): pass however it does not work for the callback itself, I have to repeat myself def my_callback(a: int, b: str) -> None: pass and if I change the signature in CallbackType the typechecker has to know that my_callback will be passed to my_func in order to detect the error. I propose to add a new syntax that declares the type of the function after the function name. def my_callback: CallbackType(a, b): pass any further parameter annotations would be disallowed: def my_callback: CallbackType(a: int, b: str): # Syntax error - duplicate annotations pass If the function parameters do not match the type signare, type hinters would flag this as a type mismatch. def my_callback: CallbackType(a): # type mismatch pass My original thought was that if CallbackType was not a Callable this would also be a type error. However I have since realized this could be used for declaring the return type of properties: For example class MyClass(object): @property def my_prop: int(self) return 10 c = MyClass() Then c.my_prop would be type hinted as an integer. What do people think? Cheers Tim ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
On Wed, Mar 20, 2019 at 12:37 AM Sylvain MARIE via Python-ideas wrote: > > Stephen > > > If the answer is "maybe", IMO PyPI is the right solution for distribution. > > Very wise words, I understand this point. > However as of today it is *not* possible to write such a library in a > complete way, without an additional tool from the language itself. Trust me, > I tried very hard :). Indeed `my_decorator(foo)` when foo is a callable will > always look like `@my_decorator` applied to function foo, because that's how > the language is designed. So there is always one remaining ambiguous case to > cover, and I have to rely on some ugly tricks such as asking users for a > custom disambiguator. > Fair point. Though the custom disambiguator could be as simple as using a keyword argument - "my_decorator(x=foo)" is not going to look like "@my_decorator \n def foo". ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Stephen > If the answer is "maybe", IMO PyPI is the right solution for distribution. Very wise words, I understand this point. However as of today it is *not* possible to write such a library in a complete way, without an additional tool from the language itself. Trust me, I tried very hard :). Indeed `my_decorator(foo)` when foo is a callable will always look like `@my_decorator` applied to function foo, because that's how the language is designed. So there is always one remaining ambiguous case to cover, and I have to rely on some ugly tricks such as asking users for a custom disambiguator. So if the decision is to let community-provided libraries like `decopatch` solve this problem, would you please consider providing us with the missing information? For example a new method in the `inspect` package could be `inspect.is_decorator_call(frame)`, that would return True if and only if the given frame is a decorator usage call as in `@my_decorator`. That piece would be enough - I would gladly take care of the rest in `decopatch`. Thanks for the feedback ! Sylvain -Message d'origine- De : Stephen J. Turnbull Envoyé : vendredi 15 mars 2019 04:56 À : Sylvain MARIE Cc : David Mertz ; python-ideas Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators [External email: Use caution with links and attachments] Sylvain MARIE via Python-ideas writes: > I totally understand your point of view. However on the other hand, > many > very popular open source projects out there have the opposite > point of > view and provide decorators that can seamlessly be used > with and without > arguments (pytest, attrs, click, etc.). So after a > while users get used > to this behavior and expect it from all > libraries. Making it easy to > implement is therefore something quite > important for developers not to > spend time on this useless > “feature”. That doesn't follow. You can also take it that "educating users to know the difference between a decorator and a decorator factory is therefore something quite important for developers not to spend time on this useless 'feature'." I'm not a fan of either position. I don't see why developers of libraries who want to provide this to their users shouldn't have "an easy way to do it", but I also don't see a good reason to encourage syntactic ambiguity by providing it in the standard library. I think this is a feature that belongs in the area of "you *could* do it, but *should* you?" If the answer is "maybe", IMO PyPI is the right solution for distribution. Steve -- Associate Professor Division of Policy and Planning Science https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturnbull.sk.tsukuba.ac.jp%2Fdata=02%7C01%7Csylvain.marie%40se.com%7C1c5b73f96ee240ef288608d6a8fa2030%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636882189569411152sdata=EcCuG%2Bad0oJoT1Fupd7086wkxHUPapCEKN2x3zDvCw0%3Dreserved=0 Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN __ This email has been scanned by the Symantec Email Security.cloud service. __ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
On Tue, 19 Mar 2019 10:49:41 +1300 Greg Ewing wrote: > Rémi Lapeyre wrote: > > > You can make "inferences from the way things are used". But the > > comparison with maths stops here, you don’t make such inferences because > > your > > object must be well defined before you start using it. > > In maths texts it's very common to see things like 'Let y = f(x)...' > where it's been made clear beforehand (either explicitly or implicitly) > what type f returns. It's made clear because, when f was defined, it's explicitly spelled out what are the source and destination domains (not sure that's the right terminology). That's part of how you define a function in maths. There's no such thing in Python, unless you enforce typing hints and/or comprehensive docstrings. > No, you don't, because most lines in most programs allow types to > be inferred. The reason that things like MyPy are possible and > useful is that Python programs in practice are usually well-typed. You are being idealistic here. MyPy relies on typing hints being available, and sufficiently precise. Regards Antoine. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] True and False are singletons
18.03.19 22:52, Wes Turner пише: >>> True = 1 File "", line 1 SyntaxError: can't assign to keyword The error message will be changed in 3.8. >>> True = 1 File "", line 1 SyntaxError: cannot assign to True ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] True and False are singletons
18.03.19 22:58, Greg Ewing пише: Oleg Broytman wrote: Three-way (tri state) checkbox. You have to distinguish False and None if the possible valuse are None, False and True. In that case the conventional way to write it would be if settings[MY_KEY] == True: ... It's not a major issue, but I get nervous when I see code that assumes True and False are unique, because things weren't always that way. "x == True" looks more dubious to me than "x is True". The latter can be intentional (see for example the JSON serializer), the former is likely was written by a newbie and contains a bug. For example, 1 and 1.0 will pass this test, but 2 and 1.2 will not. Python 3.8 will emit a syntax warning for "x is 1" but not for "x is True", because the latter is well defined and have valid use cases. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
