Re: [Python-ideas] Add the imath module

On Fri, Jul 13, 2018 at 4:11 AM, Steven D'Aprano wrote: > There is no reason why primality testing can't be deterministic up to > 2**64, and probabilistic with a ludicrously small chance of false > positives beyond that. The implementation I use can be expected to fail > on average once every 18

Re: [Python-ideas] Add the imath module

]Serhiy Storchaka ] > What are your thoughts about adding a new imath module for integer > mathematics? It could contain the following functions: > I have mixed feelings :-( There are a number of integer functions broadly useful to people attracted to such things, and "it would be nice" to have

[Python-ideas] Including the unparse module in the standard library

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

Re: [Python-ideas] Including the unparse module in the standard library

If you want to get source code from an AST, you'd probably be better off with a more fully-featured library like Astor: https://github.com/berkerpeksag/astor On July 12, 2018 1:21:23 PM Andre Roberge wrote: In the cPython repository, there is an unparse module in the Tools section.

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018 at 2:22 PM Chris Angelico wrote: > On Fri, Jul 13, 2018 at 4:11 AM, Steven D'Aprano > wrote: > > There is no reason why primality testing can't be deterministic up to > > 2**64, and probabilistic with a ludicrously small chance of false > > positives beyond that. The

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018 at 01:26:45PM -0400, David Mertz wrote: [talking about prime numbers] > That's the point I was getting at. "For your purposes" isn't general enough > to include in the standard library. There are quite a few algorithms and > efficiency trade-offs to decide on. It's not

Re: [Python-ideas] Add the imath module

I take it back... Tim's (really Will Ness's) version is *always* faster and more memory friendly. I'm still trying to understand it though :-). On Thu, Jul 12, 2018 at 6:05 PM David Mertz wrote: > > On Thu, Jul 12, 2018 at 2:22 PM Chris Angelico wrote: > >> On Fri, Jul 13, 2018 at 4:11 AM,

Re: [Python-ideas] Add the imath module

[David Mertz] > Miller-Rabin or other pseudo-primality tests do not produce false > negatives IIUC. > That's true if they're properly implemented ;-) If they say False, the input is certainly composite (but there isn't a clue as to what a factor may be); if the say True, the input is "probably"

Re: [Python-ideas] Add the imath module

On Fri, Jul 13, 2018 at 10:56:21AM +1000, Chris Angelico wrote: > You can say that about algorithms easily enough. My point is that this > ought to be a constraint on the function - implementations may choose > other algorithms, but they MUST follow one pattern or the other, > meaning that a

Re: [Python-ideas] Add the imath module

On Fri, Jul 13, 2018 at 10:40 AM, Steven D'Aprano wrote: > On Fri, Jul 13, 2018 at 04:20:55AM +1000, Chris Angelico wrote: >> On Fri, Jul 13, 2018 at 4:11 AM, Steven D'Aprano wrote: >> > There is no reason why primality testing can't be deterministic up to >> > 2**64, and probabilistic with a

Re: [Python-ideas] Add the imath module

On Fri, Jul 13, 2018 at 11:48 AM, Steven D'Aprano wrote: > On Fri, Jul 13, 2018 at 10:56:21AM +1000, Chris Angelico wrote: > >> You can say that about algorithms easily enough. My point is that this >> ought to be a constraint on the function - implementations may choose >> other algorithms, but

Re: [Python-ideas] Add the imath module

Oops... yeah. I had fixed the "up to and including" previously, but somehow I copied the wrong version to the thread. On Thu, Jul 12, 2018 at 6:36 PM Tim Peters wrote: > [David Mertz] > >> Miller-Rabin or other pseudo-primality tests do not produce false >> negatives IIUC. >> > > That's true

Re: [Python-ideas] Add the imath module

On Fri, Jul 13, 2018 at 04:20:55AM +1000, Chris Angelico wrote: > On Fri, Jul 13, 2018 at 4:11 AM, Steven D'Aprano wrote: > > There is no reason why primality testing can't be deterministic up to > > 2**64, and probabilistic with a ludicrously small chance of false > > positives beyond that. The

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018 at 05:35:54PM -0500, Tim Peters wrote: > [David Mertz] > > > Miller-Rabin or other pseudo-primality tests do not produce false > > negatives IIUC. > > > > That's true if they're properly implemented ;-) If they say False, the > input is certainly composite (but there isn't

Re: [Python-ideas] Add the imath module

[David Mertz] > Oops... yeah. I had fixed the "up to and including" previously, but > somehow I copied the wrong version to the thread. > Doesn't matter ;-) The point here, to me, is that the prime generator I pointed at is significantly faster, more memory-frugal, and even "more correct",

Re: [Python-ideas] Fwd: grouping / dict of lists

On Mon, Jul 9, 2018 at 5:55 PM, Franklin? Lee wrote: > >> - The storage container. > > > > > > so this means you'r passing in a full set of storage containers? I'm a > vit > > confused by that -- if they might be pre-populated, then they would need > to > > be instance,s an you'd need to have

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018 at 11:05 AM, Steven D'Aprano wrote: > I'm not sure that we need a specific module for integer-valued maths. I > think a more important change would be to allow math functions to be > written in Python, not just C: > > - move the current math library to a private _math

Re: [Python-ideas] Add the imath module

[Chris Angelico, on "probable prime" testers] > You can say that about algorithms easily enough. My point is that this > ought to be a constraint on the function - implementations may choose > other algorithms, but they MUST follow one pattern or the other, > meaning that a Python script can

Re: [Python-ideas] Add the imath module

On Fri, Jul 13, 2018 at 2:58 PM, Tim Peters wrote: > [Chris Angelico, on "probable prime" testers] >> >> You can say that about algorithms easily enough. My point is that this >> ought to be a constraint on the function - implementations may choose >> other algorithms, but they MUST follow one

Re: [Python-ideas] Fwd: grouping / dict of lists

On Mon, Jul 9, 2018 at 3:38 PM, David Mertz wrote: > In my mind, I *rarely* (which is more than never) have my data in the form > of a sequence of key/value pairs. The version of the API that assumes data > starts that way feels like either a niche case, or demands preprocessing > before it's

Re: [Python-ideas] anyone need a frozenset or bytearray literal?

12.07.18 02:25, Gregory P. Smith пише: (c) adding a .freeze() method to sets which would raise an exception if the set's refcount were > 1 and would mutate the type of the set object into a frozenset object in place.  refcount assertions are bad, not all VMs need refcounts.  The concept of a

Re: [Python-ideas] anyone need a frozenset or bytearray literal?

12.07.18 08:33, Gregory P. Smith пише: Agreed, bytearray(b'...') should be way less common.  I don't immediately have a use for that beyond merely than disliking the copy from temporary bytes object and gc behind the scenes. You can't avoid this since bytearray is mutable. The constant bytes

Re: [Python-ideas] anyone need a frozenset or bytearray literal?

Hi all, While we are at it, could {"a":1, "b":2}.freeze() perhaps create a MappingProxyType? I've a gist at https://gist.github.com/stephanh42/d277170dd8a3a2f026c272a4fda15396 with a stand-alone freeze function which attempts to convert objects to a read-only version, and dict ->

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

Replying to a few points out of order... On Thu, Jul 12, 2018 at 02:03:07AM +, Robert Vanden Eynde wrote: > lookup(name(x)) == x for all x is natural isn't it ? The Unicode Consortium doesn't think so, or else they would mandate that all defined code points have a name. > In the

Re: [Python-ideas] Add the imath module

12.07.18 14:55, Serhiy Storchaka пише: What are your thoughts about adding a new imath module for integer mathematics? It could contain the following functions: I forgot yet one useful function: def divide_and_round(a, b): q, r = divmod(a, b) r *= 2 greater_than_half = r > b if b

Re: [Python-ideas] Add the imath module

About the name, why not intmath ? And why not using sage ? Or create a package on pypi ? Le jeu. 12 juil. 2018 à 15:11, Serhiy Storchaka a écrit : > 12.07.18 14:55, Serhiy Storchaka пише: > > What are your thoughts about adding a new imath module for integer > > mathematics? It could contain

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

I like your alias(...) function, with that one, an application could code my function like try name(x) expect alias(x).abbreviations[0]. If the abbreviation list is sorted by AdditionToUnicodeDate. Or try: return name(x) expect: if category(x) == 'Cc': return

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018 at 5:20 AM Daniel Moisset wrote: > (I don't have a good name): something telling that an integer can be > represented exactly as a float One might also ask that question of e.g. decimal.Decimal, fractions.Fraction, so maybe it's better as a method or somewhere else. (Is

Re: [Python-ideas] Add the imath module

12.07.18 15:15, David Mertz пише: On Thu, Jul 12, 2018, 7:56 AM Serhiy Storchaka > wrote: * isprime(n) Tests if n is a prime number. How would you test this? The Miller-Rabin Primality test? For large numbers, iterating through candidate prime divisors is

Re: [Python-ideas] Add the imath module

12.07.18 16:15, Robert Vanden Eynde пише: About the name, why not intmath ? Because cmath. But if most core developers prefer intmath, I have no objections. And why not using sage ? Or create a package on pypi ? Because some of these function could be useful in the stdlib. Because the

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

On Thu, Jul 12, 2018 at 05:17:26PM +1000, Steven D'Aprano wrote: > > I propose adding a keyword argument, to > > unicodedata.name > > I don't think that's a real URL. I'm sure it was a stupid autoreplacement by web mail (hotmail in this case). As '.name' is a

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

Yes, my gmail client transformed unicodata . name to a url. I hope the mobile gmail client won't do it here. Yes current version is 11. I noticed it after sending the mail, I've compared to the version 6 and all my arguments are still valid (they just added some characters in the "correction"

Re: [Python-ideas] anyone need a frozenset or bytearray literal?

On Wed, Jul 11, 2018 at 04:25:56PM -0700, Gregory P. Smith wrote: > Completely obvious what it does, but it irritates my aesthetic > sensibilities every time I see: > frozenset({spam, eggs}) +1 to the idea of a new set method, freeze, returning a frozenset, and allowing the interpreter to

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018, 7:56 AM Serhiy Storchaka wrote: > * isprime(n) > Tests if n is a prime number. > How would you test this? The Miller-Rabin Primality test? For large numbers, iterating through candidate prime divisors is pricey. * primes() > Returns an iterator of prime numbers: 2, 3, 5,

[Python-ideas] Add the imath module

What are your thoughts about adding a new imath module for integer mathematics? It could contain the following functions: * factorial(n) Is just moved from the math module, but non-integer types are rejected. Currently math.factorial() accepts also integer floats like 3.0. It looks to me,

Re: [Python-ideas] Add the imath module

If you want inspiration: https://github.com/sagemath/sage/blob/master/src/sage/arith/misc.py ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct:

Re: [Python-ideas] Add the imath module

primefactors(n): an iterator on the primes that evenly divide n (repeating such as the product is n (I don't have a good name): something telling that an integer can be represented exactly as a float On 12 July 2018 at 12:55, Serhiy Storchaka wrote: > What are your thoughts about adding a new

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

Robert Vanden Eynde writes: > As I'm at, I mentionned the ffef character but we don't care about > it because it already has a name, so that's mostly a control > character issue. The problem with control characters is that from the point of view of the Unicode Standard, the C0 and C1

Re: [Python-ideas] Add the imath module

12.07.18 17:30, Paul Moore пише: I'm -1 on having inefficient versions like your primes(n) implementation above in the stdlib. People will use them not realising they may not be suitable for anything other than toy problems. This is just the shortest version that I write every time when I need

Re: [Python-ideas] Add the imath module

On 12 July 2018 at 14:30, Serhiy Storchaka wrote: > 12.07.18 15:15, David Mertz пише: >> >> On Thu, Jul 12, 2018, 7:56 AM Serhiy Storchaka > > wrote: >> >> * isprime(n) >> Tests if n is a prime number. >> >> >> How would you test this? The Miller-Rabin

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

> I like your alias(...) function, with that one, an application > could code my function like try name(x) expect > alias(x).abbreviations[0]. If the abbreviation list is sorted by > AdditionToUnicodeDate. I don't understand why that's particularly useful, especially in the Han case (see

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018 at 06:28:19PM +0300, Serhiy Storchaka wrote: > This is the one that is useful in many applications and can't be > trivially written as expression in Python, but is useful in many > applications (date and time, Fraction, Decimal). > > Divide and rounding down: n//m. >

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018 at 02:55:58PM +0300, Serhiy Storchaka wrote: > What are your thoughts about adding a new imath module for integer > mathematics? I'm not sure that we need a specific module for integer-valued maths. I think a more important change would be to allow math functions to be

Re: [Python-ideas] Add the imath module

12.07.18 19:14, Steven D'Aprano пише: Sorry, I don't understand why you say that divide and round up can't be trivially written in Python. Don't you give two implementations yourself? Sorry, perhaps I was unclear, but I said the opposite. ___

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

On 2018-07-12 16:02, Stephen J. Turnbull wrote: Robert Vanden Eynde writes: > As I'm at, I mentionned the ffef character but we don't care about > it because it already has a name, so that's mostly a control > character issue. The problem with control characters is that from the point of

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

On Fri, Jul 13, 2018 at 12:02:20AM +0900, Stephen J. Turnbull wrote: > > I like your alias(...) function, with that one, an application > > could code my function like try name(x) expect > > alias(x).abbreviations[0]. If the abbreviation list is sorted by > > AdditionToUnicodeDate. > > I

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018, 9:31 AM Serhiy Storchaka wrote: > 12.07.18 15:15, David Mertz пише: > > On Thu, Jul 12, 2018, 7:56 AM Serhiy Storchaka > I didn't mean any concrete implementation. Sure there are enough > efficient and simple. I sometimes need a sequence of prime numbers for > solving toy

Re: [Python-ideas] Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names

On Thu, Jul 12, 2018 at 03:11:59PM +, Robert Vanden Eynde wrote: [Stephen] > I don't understand what you're asking for. The Unicode Standard > already provides canonical names. > > Not for control characters. That's because the Unicode Consortium considers that control characters have no

Re: [Python-ideas] Add the imath module

On Thu, Jul 12, 2018 at 07:50:32PM +0300, Serhiy Storchaka wrote: > 12.07.18 19:14, Steven D'Aprano пише: > >Sorry, I don't understand why you say that divide and round up can't be > >trivially written in Python. Don't you give two implementations > >yourself? > > Sorry, perhaps I was unclear,