Mailman 3 July 2018 - Python-ideas

Including the unparse module in the standard library
by Andre Roberge 17 Jul '18

17 Jul '18

In the cPython repository, there is an unparse module in the Tools section. https://github.com/python/cpython/blob/master/Tools/parser/unparse.py However, as it is not part of the standard library, it cannot be easily used; to do so, one needs to make a local copy in a place from where it can be imported. This module can be useful for people using the ast module to create and parse trees, modify them ... and who want to convert the result back into source code. Since it is obviously maintained to be compatible with the current Python version, would it be possible to include the unparse module in the standard library? André Roberge

4 3

Do not block threads when pickle/unpickle
by Martin Bammer 16 Jul '18

16 Jul '18

Hi, the old and slow python implementation of pickle didn't block background thread. But the newer C-implementation blocks other threads while dump/load is running. Wouldn't it be possible to allow other threads during this time? Especially could load/loads release the GIL, because Python objects are not available to the Python code until these functions have finished? Regards, Martin

3 4

Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names
by Robert Vanden Eynde 16 Jul '18

16 Jul '18

unicodedata.name<http://unicodedata.name> raises KeyError for a few unicode characters like '\0' or '\n', altough the documentation is very clear on the implementation, this is often not what people want, ie. a string describing the character. In Python 3.3, the name aliases became accepted in unicodedata.lookup('NULL') and '\N{NULL}' == '\N{NUL}'. One could expect that lookup(name(x)) == x for all unicode character but this property doesn't hold because of the few characters that do not have a name (mainly control characters). The use case where the KeyError is raised when a codepoint for a unused character or newest version of unicode is however still useful. In the NameAliases https://www.unicode.org/Public/6.3.0/ucd/NameAliases.txt one can see that some characters have multiple aliases, so there are multiple ways to map a character to a name. I propose adding a keyword argument, to unicodedata.name<http://unicodedata.name> that would implement one of some useful behavior when the value does not exist. In that case. One simple behavior would be to chose the name in the "abbreviation" list. Currently all characters except three only have one and only one abbreviation so that would be a good pick, so I'd imagine name('\x00', abbreviation=True) == 'NUL' The three characters in NameAlias.txt that have more than one abbreviation are : '\n' with ['LF', 'NL', 'EOL'] '\t' with ['HT', 'TAB'] '\ufeff' with ['BOM', 'ZWNBSP'] In case multiple abbreviations exist, one could take the first introduced to unicode (for backward compability with python versions). If this is a tie, one could take the first in the list. If it has no name and no abbreviation, unicodata.name<http://unicodata.name> raises an error or returns default as usual. lookup(name(x)) == x for all x is natural isn't it ?

5 11

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 15 Jul '18

15 Jul '18

On 2018-07-12 20:11, Steven D'Aprano wrote: > about 4.7 seconds to test 2**800 + 1; In SageMath: sage: n = 2**800+1; timeit('is_prime(n)') 625 loops, best of 3: 303 µs per loop That's 4 orders of magnitude faster...

7 11

Make import an expression
by Ken Hilton 14 Jul '18

14 Jul '18

Hi all, Just a curious idea I had. The subject says it all. "import" is currently a statement, which means it cannot be used inside anything else. Currently, the only way to import a module inside an expression is to use the __import__ function, which is both cumbersome and takes up more space (which is disadvantageous in things like code golf). I propose making "import" an expression, thus allowing the syntactic sugar of "import module" -> "__import__('module')" to be graduated to the expression level. Because of operator precedence, I suspect that in most cases one would need to surround the expression with parentheses. An additional effect that is not seen with using __import__ is that the module's name is bound to the current scope the way it is with a normal import statement. Examples of where this could be used: Importing on the fly to generate one value: secret = (import random).randint(1, 100) Quick use of itertools in generator expressions: (i * i for i in (import itertools).accumulate(generate_numbers())) Re-using a function from a module after importing it in an expression: b = a * (import math).tan(math.radians(45)) #math.radians is valid because (import math) binds "math" to the current scope What are your thoughts? Sharing, Ken Hilton;

5 4

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 14 Jul '18

14 Jul '18

On 2018-07-13 14:11, Steven D'Aprano wrote: > What it *actually* does is: > > is_almost_certainly_prime_except_for_a_ludicrously_microscopic_chance_of_error_thousands_of_times_less_likely_than_a_stray_cosmic_ray_flipping_a_bit_in_memory_and_causing_the_wrong_result_to_be_returned() That's just a long variant of is_probable_prime() > If your bank is satisfied with "mere probable prime number" to transfer > billions of dollars around the world, then I'm sure that the users of > Python's std library should be too. That's besides the point. I agree that probable primes are good enough, just don't call them "prime".

6 5

Fwd: grouping / dict of lists
by David Mertz 13 Jul '18

13 Jul '18

Steven: You've misunderstood part of the discussion. There are two different signatures being discussed/proposed for a grouping() function. The one you show we might call grouping_michael(). The alternate API we might call grouping_chris(). These two calls will produce the same result (the first output you show) grouping_michael(words, keyfunc=len) grouping_chris((len(word), word) for word in words) I happen to prefer grouping_michael(), but recognize they each make slightly different things obvious. Absolutely no one wants the behavior in your second output. On Tue, Jul 3, 2018, 9:32 PM Steven D'Aprano <steve(a)pearwood.info> wrote: > Of course you can prepare the sequence any way you like, but these are > not equivalent: > > grouping(words, keyfunc=len) > grouping((len(word), word) for word in words) > > The first groups words by their length; the second groups pairs of > (length, word) tuples by equality. > > py> grouping("a bb ccc d ee fff".split(), keyfunc=len) > {1: ['a', 'd'], 2: ['bb', 'ee'], 3: ['ccc', 'fff']} > > py> grouping((len(w), w) for w in "a bb ccc d ee fff".split()) > {(3, 'ccc'): [(3, 'ccc')], (1, 'd'): [(1, 'd')], (2, 'ee'): [(2, 'ee')], > (3, 'fff'): [(3, 'fff')], (1, 'a'): [(1, 'a')], (2, 'bb'): [(2, ' >

5 11

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 13 Jul '18

13 Jul '18

On 2018-07-13 04:02, Chris Angelico wrote: > Haha. Okay. I'm not familiar with every possible primality test, so I > had no idea that they ALL have the same failure mode :) There exist guaranteed primality tests, but those are much slower and more complicated. The state of the art is ECPP: https://en.wikipedia.org/wiki/Elliptic_curve_primality

4 3

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 13 Jul '18

13 Jul '18

On 2018-07-13 14:26, Steven D'Aprano wrote: > I'm pretty sure that Sage is using numpy This computation uses PARI/GP, a dedicated library for number theory (https://pari.math.u-bordeaux.fr/) with a Python interface (https://github.com/defeo/cypari2). > And it's > probably making far less conservative choices about the rate of false > positives it is willing to accept. It's an actual primality test, not a probable primality test. But for numbers which are not prime (like your examples), the difference doesn't actually matter.

1 0

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 13 Jul '18

13 Jul '18

On 2018-07-13 11:50, Jacco van Dorp wrote: > At the very least, use is_likely_prime() as function name. I agree with you here: the function name should reflect what it actually does. (Note that the technical term is "probable prime", so it should be is_probable_prime) But I don't think that the Python stdlib should have a proven is_prime() function because that would be complicated, slow and have very limited benefit over is_probable_prime().

2 1