Mailman 3 October 2018 - Python-ideas

Re: [Python-ideas] Trigonometry in degrees
by Hugh Fisher 08 May '19

08 May '19

> Date: Thu, 7 Jun 2018 12:33:29 +0000 > From: Robert Vanden Eynde <robertvandeneynde(a)hotmail.com> > To: python-ideas <python-ideas(a)python.org> > Subject: [Python-ideas] Trigonometry in degrees > Message-ID: > > > I suggest adding degrees version of the trigonometric functions in the math module. > > - Useful in Teaching and replacing calculators by python, importing something is seen by the young students much more easy than to define a function. I agree that degrees are useful for teaching. They are also very useful for graphics programming, especially with my favourite OpenGL API. But I think that the use of radians in programming language APIs is more prevalent, so the initial advantage of easy learning will be outweighed by the long term inconvenience of adjusting to what everyone else is doing. Writing degrees(x) and radians(x) is a little inconvenient, but it does make it clear what units are being used. And even if your proposal is adopted, there is still going to be a lot of code around that uses the older math routines. With the current API it is a least safe to assume that angles are radians unless stated otherwise. > - Special values could be treated, aka when the angle is a multiple of 90, young students are often surprise to see that cos(pi/2) != 0 > > Testing for a special value Isn't very costly (x % 90 == 0) but it could be pointed out that there is a small overhead using the "degrees" equivalent of trig function because of the radians to degrees conversion And the special values testing. Not just young students :-) I agree with this, but I would prefer the check to be in the implementation of the existing functions as well. Any sin/cos very close to 0 becomes 0, any close to 1 becomes 1. > - Standard names will be chosen so that everyone will use the same name convention. I suggest adding a "d" like sind, cosd, tand, acosd, asind, atand, atan2d. Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending "d" means "double precision". It's even sort of implied by the C math library which has sinf and friends for single precision. > > Creating a new package like 'from math.degrees import cos' however I would not recommend that because "cos" in the source code would mean to lookup the import to know if it's in degrees or radians (and that leads to very filthy bugs). Also "degrees" is already so the name would have to change the name of the package. Agree, not a good idea. -- cheers, Hugh Fisher

16 29

f-string "debug" conversion
by Eric V. Smith 03 May '19

03 May '19

This idea was proposed to me at the core sprints last month by Larry Hastings. I've discussed it with a few people, who seem generally positive about it, and we've tweaked it a little bit. I've spent some time implementing it, and I think it's doable. I thought I'd post it here for any additional feedback. Here’s the idea: for f-strings, we add a !d conversion operator, which is superficially similar to !s, !r, and !a. The meaning of !d is: produce the text of the expression (not its value!), followed by an equal sign, followed by the repr of the value of the expression. So: value = 10 s = 'a string!' print(f'{value!d}') print(f'next: {value+1!d}') print(f'{s!d}') produces: value=10 next: value+1=11 s='a string!' I’m not proposing this for str.format(). It would only really make sense for named arguments, and I don’t think print('{value!d}'.format(value=value) is much of a win. The result is a string, so if you really wanted to, you could use a string formatting spec. So: print(f'*{value!d:^20}*' would produce: * value=10 * Although I don’t think that would be very useful in general. The mnemonic is !d for “debugging”. I’d wanted to use !=, because there’s an equal sign involved in the result, but = is the one character that can’t be used after ! (it’s “not equal” in expressions, and f-strings look specifically for that case). I also mentioned !!, but I think I prefer !d as being less confusing. This would be used in debugging print statements, that currently end up looking like: print(f'value={value!r}') and would now be: print(f'{value!d}') There have been discussions about ways to specify str() vs. repr(), using characters other than '=', adding spaces, etc. But they all end up over-complicating what should be a simple tool, not a Swiss Army knife. Thoughts? Eric

12 36

Return for assignment blocks
by Calvin Spealman 20 Mar '19

20 Mar '19

I'd like to suggest what I think would be a simple addition to `def` and `class` blocks. I don't know if calling those "Assignment Blocks" is accurate, but I just mean to refer to block syntaxes that assign to a name. Anyway, I propose a combined return-def structure, and optionally also allowing a return-class version. Omitting the name would be allowable, as well. This would only apply to a `def` or `class` statement made as the last part of the function body, of course. def ignore_exc(exc_type): return def (func): @wraps(func) return def (*args, **kwargs): try: return func(*args, **kwargs) except exc_type: pass Thanks for considering and for any comments, thoughts, or feedback on the idea!

14 33

Support localization of unicode descriptions
by Pander 25 Feb '19

25 Feb '19

Dear all, Who might also be interested in setting up a project that supports localization for Unicode block description and character description. Translations are available from https://github.com/unicode-table/unicode-table-data/tree/master/loc <https://github.com/unicode-table/unicode-table-data/tree/master/loc> If possible, use a gettext approach similar to https://pypi.org/project/pycountry/ <https://pypi.org/project/pycountry/> Implementing this feature will allow users to read Unicode descriptions in their own language, other than English. For example, now is possible only in English: from unicodedata import name print(name('ß')) LATIN SMALL LETTER SHARP S So unicodedata could provide a way to translate LATIN SMALL LETTER SHARP S to e.g. German with: from unicodedata import name from unicodedata_l10n import LOCALED_DIR from gettext import translation german = translation('UnicodeData' LOCALED_DIR, languages=['de']) german.install() print(_(name('ß'))) LATEINISCHER KLEINBUCHSTABE SCHARFES S and something similar for unicodedata.category Best, Pander

5 8

Dart like multi line strings identation
by Marius Räsener 08 Feb '19

08 Feb '19

Hey List, this is my very first approach to suggest a Python improvement I'd think worth discussing. At some point, maybe with Dart 2.0 or a little earlier, Dart is now supporting multiline strings with "proper" identation (tried, but I can't find the according docs at the moment. probably due to the rather large changes related to dart 2.0 and outdated docs.) What I have in mind is probably best described with an Example: print(""" I am a multiline String. """) the closing quote defines the "margin indentation" - so in this example all lines would get reduces by their leading 4 spaces, resulting in a "clean" and unintended string. anyways, if dart or not, doesn't matter - I like the Idea and I think python3.x could benefit from it. If that's possible at all :) I could also imagine that this "indentation cleanup" only is applied if the last quotes are on their own line? Might be too complicated though, I can't estimated or understand this... thx for reading, Marius

23 47

Make None a subclass of int [alternative to iNaN]
by Ken Hilton 27 Nov '18

27 Nov '18

Hi all, Reading the iNaN discussion, most of the opposition seems to be that adding iNaN would add a new special value to integers and therefore add new complexity. I propose, instead, that we make None a subclass of int (or even a certain value of int) to represent iNaN. Therefore: >>> None + 1, None - 1, None * 2, None / 2, None // 2 (None, None, None, nan, None) # mathematical operations on NaN return NaN >>> None & 1, None | 1, None ^ 1 # I'm not sure about this one. The following could be plausible: (0, 1, 1) # or this might make more sense, as this *is* NaN we're talking about: (None, None, None) >>> isinstance(None, int) True # the whole point of this idea >>> issubclass(type(None), int) True # no matter whether None *is* an int or just a subclass, this will be true as issubclass(int, int) is True I know this is a crazy idea, but I thought it could have some merit, so why not throw it out here? Sharing, Ken Hilton;

3 2

Add "default" kwarg to list.pop()
by Giampaolo Rodola' 08 Nov '18

08 Nov '18

Sorry in advance if this has been proposed in the past but I couldn't find anything on python-ideas: >>> l = [] >>> l.pop(default=1) 1 FWIW my use case consists in reading entries from /proc/diskstats where lines can have a variable number of fields depending on the kernel version: https://github.com/giampaolo/psutil/issues/1354#issuecomment-434495870 https://github.com/giampaolo/psutil/blob/d8b05151e65f9348aff9b58da977abd8ca… As such it would be convenient to set missing fields to 0 as "reads = fields.pop(default=0)" instead of catching IndexError every time. Extra: for consistency set.pop() should probably have the same. Thoughts? -- Giampaolo - http://grodola.blogspot.com

18 41

Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae
by julien tayon 31 Oct '18

31 Oct '18

Hello :) the idea is described here:http://jul.github.io/cv/pres.html#printable Summary of the idea : Take a linear algebrae book, and implements all the rules as a TDD.https://github.com/jul/archery/blob/master/consistent_algebrae.py make it works based on abstract base class and sets of Mixins.https://archery.readthedocs.io/en/latest/ And see if we can make cos/__abs__/dot and if it gives naively the intended results ? (spoiler: yes) Making it work with dict, and "other" dictionary like counter by using ineritancehttps://archery.readthedocs.io/en/latest/#advanced-usage My idea is : wouldn't it be nice if we introduced geometries as sets of mixins for objects ? (Hilbertian algebrae could be nice too, and we could make MutableMapping behave like bra/kets). So I was proposing a soft discussion on : could we agree that it would be nice to consider operation overloading as a whole set of behaviours that could profit from being consistent in a categorized way ? (like the + of [] could be the + of "RecordAlgebrae") Meaning we could define sets of "expected behaviour consistent interaction between operators" as we defined the abc and call them algebrae? I offer the LinearAlgebrae Mixins as a POC, and was thinking of creating a unittest to qualify if an object is following the rules of linear algebrae. What are your opinions ? I don't actually see a lot of use case except it was funny to build. But maybe it can be of use. Cordialement -- Julien

8 12

gevent-like Coroutines in Python
by Ron Reiter 30 Oct '18

30 Oct '18

One of Golang's advantages is that goroutines act like gevent's coroutines instead of relying on an async/await syntax. In my opinion, it makes Golang code much more readable. I feel like having the await syntax trigger by default on any awaitable invocation in a coroutine context makes much more sense. I consider async/await syntax to be too complicated for the average developer since it opens up too many abilities whereas most developers would always mean they prefer to do this: result = [await fun(x) for fun in funcs] versus: result = [fun(x) for fun in funcs] await asyncio.gather(*result) Moreso, having it become the default makes statements like this: result = [await fun(x) for fun in funcs if await smth] Look like this: result = [fun(x) for fun in funcs if smth] Therefore, my suggestion is to create a new "async" definition which basically turns every function invocation into an "await" if a generator is returned. Instead of "async def" I propose the alternative "coroutine def" syntax. However, a better solution may be to imply the word "async" in every function definition given some sort of trigger (however I assume that this won't be the preferable approach as it is not something that can be implemented at the parsing level). For me, I believe that Python should aspire to be both concise and straightforward, which means no boilerplate code just because it's more "correct" but rather assume there's some logical default behavior going on in the back - and to me this logical behavior is that every invocation can trigger an await and go back to the main loop. Our assumption that a function invocation has to tie back to instant execution unless an "await" statement has been placed should be challenged in favor of readability, conciseness, and to always aim to appeal to novice developers (which I believe is the reason Python is on such a rise these days). I do have to admit I have not thought through what is the best syntax or the implications of this because I would like to see what is the general opinion on this idea first. - Ron

4 5

Add a way to test for a descriptor in Python Code
by Joy Diamond 30 Oct '18

30 Oct '18

Greetings, I am trying to emulate attribute lookup, and want to test if symbol found in __dict__ is an attribute or not in python code (i.e.: does its have a `tp_descr_get` slot?) Reading the documentation carefully, I am supposed to test if the attribute has a `.__get__` method; however, I see no way to test for this properly (easily). Currently the only way I know to test for this is (See code at end of this message): any('__get__' in m.__dict__ for m in type(v).__mro__) Which seems terribly inefficient. The documentation at: https://docs.python.org/2/howto/descriptor.html https://docs.python.org/3/howto/descriptor.html Both says: """ For classes, the machinery is in type.__getattribute__() which transforms B.x into B.__dict__['x'].__get__(None, B). In pure Python, it looks like: def __getattribute__(self, key): "Emulate type_getattro() in Objects/typeobject.c" v = object.__getattribute__(self, key) if hasattr(v, '__get__'): return v.__get__(None, self) return v """ However, the call to `hasattr(v, '__get__')` appears to me to be incorrect. The question is *NOT* whether 'v' has an attribute '__get__'; *BUT* whether `v` has a symbol `__get__` in any of the classes in it's method resolution order. Looking at `type_getattro` in "Objects/typeobject.c" here: https://github.com/python/cpython/blob/master/Objects/typeobject.c#L3177 Reads: meta_get = Py_TYPE(meta_attribute)->tp_descr_get So I really want to know if the `tp_descr_get` slot is set or not. (Which is a different question than whether `v` has a `__get__` attribute). The code below shows that: 1. The valid value of `Point.y` is <Not_A_Descriptor> 2. The valid value is returned by `Point.y`, `type.__getattribute__(Point, y)`, and `fixed__Type__getattribute` 3. The invalid value of `Point.y` is `2` as returned by the [emulated] `__getattribute__` documented https://docs.python.org/3/howto/descriptor.html So I am requesting: 1. An efficient python way to test for `tp_descr_get` slot (and other descriptor) slots. 2. Fix the documentation referenced above. Thanks, Joy Diamond. NOTE #1: This email describes the very subtle difference between whether an instance has a `__get__` symbol or not, which I believe is *NOT* the same question as whether `hasattr(instance, "__get__")` returns true or not. The first question is does it have the symbol `__get_` [Which python put in the `tp_descr_slot`] while `hasattr` answers the question does it have the `__get__` attribute. NOTE #2: Also using `hasattr(type(v), "__get__")` would not answer the question I want, because then it might find a `__get__` method in the meta-class of `type(v)` which again would return an incorrect answer. Example program that shows that using `hasattr(v, '__get__')` is not a valid way to test if something is a descriptor (works in python 2, python 3, and pypy): def get_1(self, a, b): return 1 def get_2(a, b): return 2 class Descriptor(object): __get__ = get_1 class Not_A_Descriptor(object): def __init__(self): self.__get__ = get_2 def __repr__(self): return '<Not_A_Descriptor instance>' class Point(object): __slots__ = (()) x = Descriptor() y = Not_A_Descriptor() # # Copied from https://docs.python.org/3/howto/descriptor.html # def __getattribute__(self, key): "Emulate type_getattro() in Objects/typeobject.c" v = object.__getattribute__(self, key) if hasattr(v, '__get__'): return v.__get__(None, self) return v # # My fixed version # def fixed__Type__getattribute(self, key): "FIXED: Emulate type_getattro() in Objects/typeobject.c" v = object.__getattribute__(self, key) if any('__get__' in m.__dict__ for m in type(v).__mro__): return v.__get__(None, self) return v print('Point.x: %s' % Point.x) print('Point.y: %s' % Point.y) print("type.__getattribute__(Point, 'x'): %s" % type.__getattribute__(Point, 'x')) print("type.__getattribute__(Point, 'y'): %s" % type.__getattribute__(Point, 'y')) print("__getattribute__(Point, 'x'): %s" % __getattribute__(Point, 'x')) print("__getattribute__(Point, 'y'): %s ***WRONG***" % __getattribute__(Point, 'y')) print("fixed__Type__getattribute(Point, 'x'): %s" % fixed__Type__getattribute(Point, 'x')) print("fixed__Type__getattribute(Point, 'y'): %s ***CORRECT***" % fixed__Type__getattribute(Point, 'y'))

2 2