Mailman 3 December 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

Add regex pattern literal p""
by Ma Lin 02 Jan '19

02 Jan '19

We can use this literal to represent a compiled pattern, for example: >>> p"(?i)[a-z]".findall("a1B2c3") ['a', 'B', 'c'] >>> compiled = p"(?<=abc)def" >>> m = compiled.search('abcdef') >>> m.group(0) 'def' >>> rp'\W+'.split('Words, words, words.') ['Words', 'words', 'words', ''] This allows peephole optimizer to store compiled pattern in .pyc file, we can get performance optimization like replacing constant set by frozenset in .pyc file. Then such issue [1] can be solved perfectly. [1] Optimize base64.b16decode to use compiled regex [1] https://bugs.python.org/issue35559 Two shortcomings: 1, Elevating a class in a module (re.Pattern) to language level, this sounds not very natural. This makes Python looks like Perl. 2, We can't use regex module as a drop-in replacement: import regex as re IMHO, I would like to see regex module be adopted into stdlib after cutting off its "full case-folding" and "fuzzy matching" features. Related links: [2] Chris Angelico conceived of "compiled regexes be stored in .pyc file" in March 2013. [2] https://mail.python.org/pipermail/python-ideas/2013-March/020043.html [3] Ken Hilton conceived of "Give regex operations more sugar" in June 2018. [3] https://mail.python.org/pipermail/python-ideas/2018-June/051395.html

14 27

struct.unpack should support open files
by Drew Warwick 27 Dec '18

27 Dec '18

The struct unpack API is inconvenient to use with files. I must do: struct.unpack(fmt, file.read(struct.calcsize(fmt)) every time I want to read a struct from the file. I ended up having to create a utility function for this due to how frequently I was using struct.unpack with files: def unpackStruct(fmt, frm): if isinstance(frm, io.IOBase): return struct.unpack(fmt, frm.read(struct.calcsize(fmt))) else: return struct.unpack(fmt, frm) This seems like something that should be built into the default implementation -- struct.unpack already has all the information it needs with just the struct format and open binary file. Current behavior is an error since struct.unpack only supports bytes-like objects, so this should be backwards compatible except in the case where a developer is relying on that to error in a try block instead of verifying the buffer type beforehand. >

11 26

About the passing the function arguments in Keyword form.
by 李默 25 Dec '18

25 Dec '18

I am having an idea on loosing the argument validity check when passing the function arguments in keyword way. For example: ------------------------------- deff(x, y): print(x, y) defcall_f(): f(x=7, y=9, z=9) call_f() ------------------------------ In the current of python, the extra pass of 'z' would let the interpreter raise an exception and stop work. My idea is that the interpreter need not stop because all the needed args are completely provided. Of course for this toy example, 'f' can be define as f(x, y, **kwargs) to achieve the same goal. However, essentially it is reasonably to keep interpreter going as long as enough args are passed. And this modification can bring more freedom of programming. Think about the following situations: situation 1) there are many 'f's written by other people, and their args are very similar and your job is to run each of them to get some results. --------------------- ##########code by others: def f0(): ... def f1(x): ... def f2(x, y): ... def f3(x, y, z): ... #if passing extra args are valid, you can run all the functions in the following way, which is very compact and easy to read. def test_universal_call(): funcs = [f0, f1, f2, f3] args = {'x':1, 'y':5, 'z':8} for f in funcs: f(**args) ------------------ situation 2) there are several steps for make one product, each step is in an individual function and needs different args. ------------------ def make_oil(oil): ... def make_water( water): ... def make_powder(powder): ... ## if passing extra args are valid, you can run all the functions in the following way, which is very compact and easy to read. def dish(): procedures = [make_oil, make_water, make_powder] args = {'oil' : 1, 'water': 10, 'powder': 4} for f in procedures: f(**args) --------------- This idea is different from **kwargs. **kwargs are used when user wants to record all the keywords passed. This idea is that even if the user doesn’t want to record the arguments, that extra pass of keyword arguments wont’t cause an exception. Sorry for bothering you guys if this is a stupid idea. Happy to hear your suggestions. Li Mo

5 5

Use lazy loading with hashtable in python gettext module
by s-ball＠laposte.net 23 Dec '18

23 Dec '18

In a project of mine, I have used the gettext module from Python Standard Library. I have found that several tools could be used to generate the Machine Object (mo) file from the source Portable Object (one): pybabel ( http://babel.pocoo.org/en/latest/ ), msgfmt.py from Python tools or the original msgfmt from GNU gettext. I could find that only the original msgfmt was able to generate a hashtable, and that anyway the Python gettext module loaded everything in memory and did not use it. But I also find a TODO note saying # TODO: # - Lazy loading of .mo files. Currently the entire catalog is loaded into # memory, but that's probably bad for large translated programs. Instead, # the lexical sort of original strings in GNU .mo files should be exploited # to do binary searches and lazy initializations. Or you might want to use # the undocumented double-hash algorithm for .mo files with hash tables, but # you'll need to study the GNU gettext code to do this. I have studied GNU gettext code and found that implemententing the hashing algorithm in Python would not be that hard. The undocumented features required for implementation are: - the version number can safely stay to 0 when processing Python code - the size of the hash table is the first odd prime greater than or equal to 4 * n / 3 where n is the number of strings - the first hashing function uses a variant of PJW hash function described in https://en.wikipedia.org/wiki/PJW_hash_function, where the line h = h & ~ high is replaced with h = h ^ high, and using 32 bits integers. The index in the table in the result of the function modulus the size of the hash table - when there is a conflict (the slot given by the first hashing function is already used by another string) the following is used: - let h be the result of the PJW variant hash function and size be the size of the hash table, an increment value is set to 1 +( h % (size -2)) - that increment is repeatedly added to the index in the hash table (modulus the table size) until an empty slot is found (or the correct original string is found) For now, my (alpha) code is able to generate in pure Python the same mo file that GNU msgfmt generates, and use the hashtable to access the strings. Remaining problems: - I had to read GPL copyrighted code to find the undocumented features. I have of course wrote my own code from scratch, but may I use an Apache Free License 2.1 on it? - the current code for gettext loads everything from the mo file and immediately closes it. My own code keeps the file opened to be able to access it with the mmap module. There could be use case where first option is better - I should either rely on the current way (load everything in memory) or implement a binary search algo for the case where the hash table is not present (it is of course optional) - it would be an important change, and I think that options should be allow to choose between an eager or lazy access Before going further, I would like to know whether implementing lazy access through the hash table that way seems to be a interesting improvement or a dead end.

4 5

Fwd: [asyncio] Suggestion for a major PEP
by Christophe Bailly 16 Dec '18

16 Dec '18

Hello everybody, I thought I had sent this mail to everybody, so here was my answer to Nathaniel, Regards, Chris ---------- Forwarded message --------- From: Christophe Bailly <chbailly(a)gmail.com> Date: Sun, 16 Dec 2018 at 13:56 Subject: Re: [Python-ideas] [asyncio] Suggestion for a major PEP To: Nathaniel Smith <njs(a)pobox.com> Hello Nathaniel, After reading many papers, I understand that it is not as simple as I could imagine in my first thought. Sorry about that, I have learned something. Explicit vs implicit asynchronism is a complex topic. Regards, Chris On Sun, 16 Dec 2018 at 10:16, Nathaniel Smith <njs(a)pobox.com> wrote: > If you want this style of concurrency, you don't need to write a PEP, > just 'pip install gevent' :-) > > But unfortunately you're years too late to argue for making asyncio > work this way. This was discussed extensively at the time, and the > decision to use special syntax was made intentionally, and after > studying existing systems like gevent that made the other choice. > > This section of the trio docs explain why explicit async/await syntax > makes life easier for developers: > https://trio.readthedocs.io/en/latest/reference-core.html#checkpoints > > It's also awkward but very doable to support both sync and async mode > with a single code base: https://github.com/python-trio/unasync/ > > In fact, when doing this, the async/await syntax isn't really the hard > part – the hard part is that different libraries have very different > networking APIs. E.g., the stdlib socket API and the stdlib asyncio > API are totally different. > > -n > On Sun, Dec 16, 2018 at 12:21 AM Christophe Bailly <chbailly(a)gmail.com> > wrote: > > > > Hello, > > > > I copy paste the main idea from an article I have written: > > contextual async > > > > " > > > > Imagine you have some code written for monothread. And you want to > include your code in a multithread environment. Do you need to adapt all > your code which is what you do when you want to migrate to async code ? The > answer is no. > > > > Functionnally these constraints are not justified neither technically > > > > Do we have the tools to do this ? Yes because thanks to boost::context > we can switch context between tasks. When a task suspends, it just calls a > function (the event loop or reactor) to potentially switch to another task. > Just like threads switch contexts… > > > > Async/Await logic has introduced a symetric relation wich introduces > unnecessary contraints. We should just the same logic as thread logic. > > > > " > > > > Read the examples in the article I have developped a prototype in C++ > and everything works perfectly. > > > > My opinion is that sooner or later, it will have to switch to this logic > because chaining async/aswait is a huge contraints and does not make sense > in my opinion. > > > > Maybe I am missing something, > > > > Feel free to give me your feedback. > > > > Regards, > > > > > > Chris > > > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas(a)python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Nathaniel J. Smith -- https://vorpus.org >

1 0