Re: [Python-ideas] Consider generalizing Decimal to support arbitrary radix

[Neil Girdhar]

That's really cool!  I never knew about gmpy.

On Wed, Feb 7, 2018 at 7:10 PM Case Van Horsen  wrote:

> On Wed, Feb 7, 2018 at 3:49 PM, Neil Girdhar 
> wrote:
> > On Wed, Feb 7, 2018 at 6:36 PM Chris Angelico  wrote:
> >> You should be able to use the native float type for binary
> >> floating-point. But the whole point of that challenge is that you
> >> shouldn't need a computer.
> >
> >
> > Yeah, I know, but I wanted to play with it.  Anyway, native floats don't
> > help.
> >>
> >>
> >> ChrisA
>
> I maintain gmpy2 and it might do what you want (arbitrary precision
> radix-2 arithmetic and easy access to the bits).
>
> >>> gmpy2.get_context().precision=70
> >>> gmpy2.mpfr(1)/7
> mpfr('0.14285714285714285714283',70)
> >>> (gmpy2.mpfr(1)/7).digits(2)
> ('1001001001001001001001001001001001001001001001001001001001001001001001',
> -2, 70)
>
> Historical memory - I once wrote a radix-6 fixed point library to
> explore an extension of the 3n+1 problem to rational numbers. It was
> written in Turbo Pascal and ran for days on a 286/287 PC.
>
> casevh
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/twWEvFwahaQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Consider generalizing Decimal to support arbitrary radix

[Terry Reedy]

On 2/7/2018 6:08 PM, Neil Girdhar wrote:


On Wed, Feb 7, 2018 at 5:52 PM Steven D'Aprano 
> wrote:


On Wed, Feb 07, 2018 at 10:08:50PM +, Neil Girdhar wrote:

 > Oh, and to answer your specific question, I want to change the way
 > arithmetic is done.  I want it to be done in a different radix.

Why?

There are clear advantages to floating point arithmetic done in base 2
(speed, minimum possible rounding error, least amount of wobble), and a
different advantage to floating point done in base 10 (matches exactly
the standard decimal notation used by humans with no conversion error),


This is the specialness of base 10


Outside of those two bases, arithmetic done in any other base is going
to combine the worst of both:

- slower;
- larger errors when converting from decimal numbers (in general);
- larger rounding errors;
- larger wobble;



I don't see why it would have any of those problems.


Any base other than 2 has decreased speed (on a binary computer) and 
increased computational rounding errors and wobble.



  Base 10 isn't special in any way.


Except as noted above and the fact that computation with binary coded 
decimal goes back to the early days of electronic computation.



with no corresponding advantages unless your data is coming to you in
arbitrary bases.


Right, I was playing with this problem 
(https://brilliant.org/weekly-problems/2017-10-02/advanced/?problem=no-computer-needed) 
and wanted to work in base 2.  I realize it's niche, but it's not 
exactly a significant change to the interface even if it's a big change 
to the implementation.


In cpython, decimal uses _cdecimal for speed.  I suspect that 10 is not 
only explicitly hard-coded as the base but implicitly hard-coded by 
using algorithm tricks that depend on and only work when the base is 10.


--
Terry Jan Reedy


___
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] Consider generalizing Decimal to support arbitrary radix

[Steven D'Aprano]

On Wed, Feb 07, 2018 at 11:49:27PM +, Neil Girdhar wrote:

> I see your list was about converting to and from base 10.  That wasn't
> really intended in my proposal.  I meant wholly working in another base.
> In that sense, 10 isn't particularly "fast, error-free, better at rounding,
> etc."

I never said it was. Base 2 floats is the one that is faster and better 
at rounding than any other base. No finite precision floating point 
arithmetic can be error free, but all else being equal, base 2 minimises 
the errors you get.

The advantage of base 10 is that it matches the standard base 10 
numbers we write. Within the boundaries of the available precision, if 
you can write it in decimal, you can represent it in a decimal float. 
That isn't necessarily true of decimal -> binary floats.


> > > Right, I was playing with this problem
> > > (
> > https://brilliant.org/weekly-problems/2017-10-02/advanced/?problem=no-computer-needed
> > )
> > > and wanted to work in base 2.  I realize it's niche, but it's not
> > exactly a
> > > significant change to the interface even if it's a big change to the
> > > implementation.
> >
> > You should be able to use the native float type for binary
> > floating-point. But the whole point of that challenge is that you
> > shouldn't need a computer.
> >
> 
> Yeah, I know, but I wanted to play with it.  Anyway, native floats don't
> help.

Why not?

If you can write the float in binary exactly, you can write it in hex, 
and use float.fromhex() to convert it exactly (provided it fits into the 
64-bit floats Python uses).



-- 
Steve
___
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] Consider generalizing Decimal to support arbitrary radix

[Case Van Horsen]

On Wed, Feb 7, 2018 at 3:49 PM, Neil Girdhar  wrote:
> On Wed, Feb 7, 2018 at 6:36 PM Chris Angelico  wrote:
>> You should be able to use the native float type for binary
>> floating-point. But the whole point of that challenge is that you
>> shouldn't need a computer.
>
>
> Yeah, I know, but I wanted to play with it.  Anyway, native floats don't
> help.
>>
>>
>> ChrisA

I maintain gmpy2 and it might do what you want (arbitrary precision
radix-2 arithmetic and easy access to the bits).

>>> gmpy2.get_context().precision=70
>>> gmpy2.mpfr(1)/7
mpfr('0.14285714285714285714283',70)
>>> (gmpy2.mpfr(1)/7).digits(2)
('1001001001001001001001001001001001001001001001001001001001001001001001',
-2, 70)

Historical memory - I once wrote a radix-6 fixed point library to
explore an extension of the 3n+1 problem to rational numbers. It was
written in Turbo Pascal and ran for days on a 286/287 PC.

casevh
___
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] Consider making Decimal's context use PEP 567

[Nick Coghlan]

On 8 February 2018 at 08:36, Neil Girdhar  wrote:
> Wow, that's awesome!  I didn't notice that when I checked.  It seemed like
> context had to be passed in.  If it were me, I would probably deprecate
> those context=None arguments now that we have such a clean solution.

The context=None feature is there so that developers can write pure
Decimal operations if they choose to do so, rather than always
depending on implicit dynamic state.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Consider generalizing Decimal to support arbitrary radix

[Chris Angelico]

On Thu, Feb 8, 2018 at 10:49 AM, Neil Girdhar  wrote:
>> > Right, I was playing with this problem
>> >
>> > (https://brilliant.org/weekly-problems/2017-10-02/advanced/?problem=no-computer-needed)
>> > and wanted to work in base 2.  I realize it's niche, but it's not
>> > exactly a
>> > significant change to the interface even if it's a big change to the
>> > implementation.
>>
>> You should be able to use the native float type for binary
>> floating-point. But the whole point of that challenge is that you
>> shouldn't need a computer.
>
>
> Yeah, I know, but I wanted to play with it.  Anyway, native floats don't
> help.

Sounds like performance isn't going to be a big problem, then. You can
manage with a non-optimized and naive implementation. So here's a
couple of things to try:

1) Check out PyPI and see if something like what you want exists.
2) Poke around in the source code for the Decimal class (ignore the C
module and use the pure Python one) and see if you can hack on it.

It'd then be off-topic for python-ideas, but it'd be an awesome topic
to discuss on python-list. Exploration is great fun, and Python's a
great language to explore with.

ChrisA
___
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] Consider generalizing Decimal to support arbitrary radix

[Neil Girdhar]

On Wed, Feb 7, 2018 at 6:36 PM Chris Angelico  wrote:

> On Thu, Feb 8, 2018 at 10:08 AM, Neil Girdhar 
> wrote:
> >
> > On Wed, Feb 7, 2018 at 5:52 PM Steven D'Aprano 
> wrote:
> >>
> >> - slower;
> >> - larger errors when converting from decimal numbers (in general);
> >> - larger rounding errors;
> >> - larger wobble;
> >
> >
> > I don't see why it would have any of those problems.  Base 10 isn't
> special
> > in any way.
>
> Base 10 *is* special, because it corresponds to what humans use. In
> binary floating-point, you get weird results (by human standards) like
> 0.1+0.2 not being 0.3; that doesn't happen in decimal.
>
> There is no error when converting from a string of decimal digits to a
> decimal.Decimal, so presumably to avoid error, you'd have to work with
> digits in the same base. The rounding errors and wobble are by
> comparison with binary; you get the same problems in any other base,
> without the benefit of human-friendly behaviour.
>

I see your list was about converting to and from base 10.  That wasn't
really intended in my proposal.  I meant wholly working in another base.
In that sense, 10 isn't particularly "fast, error-free, better at rounding,
etc."

>
> > Right, I was playing with this problem
> > (
> https://brilliant.org/weekly-problems/2017-10-02/advanced/?problem=no-computer-needed
> )
> > and wanted to work in base 2.  I realize it's niche, but it's not
> exactly a
> > significant change to the interface even if it's a big change to the
> > implementation.
>
> You should be able to use the native float type for binary
> floating-point. But the whole point of that challenge is that you
> shouldn't need a computer.
>

Yeah, I know, but I wanted to play with it.  Anyway, native floats don't
help.

>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/twWEvFwahaQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Possible Enhancement to py Launcher - set default

[Paul Moore]

On 7 February 2018 at 19:35, Steve Dower  wrote:
> Checking the Version (!=SysVersion) property should be enough (and perhaps
> we need to set it properly on install). The launcher currently only works
> with PythonCore entries anyway, so no need to worry about other distros.

Fair enough. But there was a separate proposal to make the launcher
handle non-PythonCore cases - there's a risk of conflicting feature
requests here :-)

> PEP 514 allows for other keys to be added as well (it specifies a minimum
> set), so we could just set one for this. “NoDefaultLaunch” or similar.

Sure - it could be purely a launcher convention, rather than having to
be specifically noted in PEP 514.

Paul
___
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] Consider generalizing Decimal to support arbitrary radix

[Chris Angelico]

On Thu, Feb 8, 2018 at 10:08 AM, Neil Girdhar  wrote:
>
> On Wed, Feb 7, 2018 at 5:52 PM Steven D'Aprano  wrote:
>>
>> - slower;
>> - larger errors when converting from decimal numbers (in general);
>> - larger rounding errors;
>> - larger wobble;
>
>
> I don't see why it would have any of those problems.  Base 10 isn't special
> in any way.

Base 10 *is* special, because it corresponds to what humans use. In
binary floating-point, you get weird results (by human standards) like
0.1+0.2 not being 0.3; that doesn't happen in decimal.

There is no error when converting from a string of decimal digits to a
decimal.Decimal, so presumably to avoid error, you'd have to work with
digits in the same base. The rounding errors and wobble are by
comparison with binary; you get the same problems in any other base,
without the benefit of human-friendly behaviour.

> Right, I was playing with this problem
> (https://brilliant.org/weekly-problems/2017-10-02/advanced/?problem=no-computer-needed)
> and wanted to work in base 2.  I realize it's niche, but it's not exactly a
> significant change to the interface even if it's a big change to the
> implementation.

You should be able to use the native float type for binary
floating-point. But the whole point of that challenge is that you
shouldn't need a computer.

ChrisA
___
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] Consider generalizing Decimal to support arbitrary radix

[Neil Girdhar]

On Wed, Feb 7, 2018 at 5:52 PM Steven D'Aprano  wrote:

> On Wed, Feb 07, 2018 at 10:08:50PM +, Neil Girdhar wrote:
>
> > Oh, and to answer your specific question, I want to change the way
> > arithmetic is done.  I want it to be done in a different radix.
>
> Why?
>
> There are clear advantages to floating point arithmetic done in base 2
> (speed, minimum possible rounding error, least amount of wobble), and a
> different advantage to floating point done in base 10 (matches exactly
> the standard decimal notation used by humans with no conversion error),
> Outside of those two bases, arithmetic done in any other base is going
> to combine the worst of both:
>
> - slower;
> - larger errors when converting from decimal numbers (in general);
> - larger rounding errors;
> - larger wobble;
>

I don't see why it would have any of those problems.  Base 10 isn't special
in any way.

>
> with no corresponding advantages unless your data is coming to you in
> arbitrary bases.
>

Right, I was playing with this problem (
https://brilliant.org/weekly-problems/2017-10-02/advanced/?problem=no-computer-needed)
and wanted to work in base 2.  I realize it's niche, but it's not exactly a
significant change to the interface even if it's a big change to the
implementation.


>
> Doing floating point arithmetic in decimal is already slower and less
> accurate than doing it in binary. I'd like to hear more about your
> use-case for doing it in base 19 or base 7, say, but I would have to
> guess that it is likely to be such a niche use-case that this
> functionality doesn't belong in the standard library.
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/twWEvFwahaQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Consider generalizing Decimal to support arbitrary radix

[Steven D'Aprano]

On Wed, Feb 07, 2018 at 10:08:50PM +, Neil Girdhar wrote:

> Oh, and to answer your specific question, I want to change the way
> arithmetic is done.  I want it to be done in a different radix.

Why?

There are clear advantages to floating point arithmetic done in base 2 
(speed, minimum possible rounding error, least amount of wobble), and a 
different advantage to floating point done in base 10 (matches exactly 
the standard decimal notation used by humans with no conversion error), 
Outside of those two bases, arithmetic done in any other base is going 
to combine the worst of both:

- slower;
- larger errors when converting from decimal numbers (in general);
- larger rounding errors;
- larger wobble;

with no corresponding advantages unless your data is coming to you in 
arbitrary bases.

Doing floating point arithmetic in decimal is already slower and less 
accurate than doing it in binary. I'd like to hear more about your 
use-case for doing it in base 19 or base 7, say, but I would have to 
guess that it is likely to be such a niche use-case that this 
functionality doesn't belong in the standard library.


-- 
Steve
___
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] Consider making Decimal's context use PEP 567

[Neil Girdhar]

Wow, that's awesome!  I didn't notice that when I checked.  It seemed like
context had to be passed in.  If it were me, I would probably deprecate
those context=None arguments now that we have such a clean solution.

On Wed, Feb 7, 2018 at 5:32 PM Nathaniel Smith  wrote:

> On Feb 7, 2018 1:54 PM, "Neil Girdhar"  wrote:
>
> Decimal could just pull its Context object from a context variable rather
> than having to pass it in to all functions.  This would be similar to how
> numpy works.
>
>
> Decimal has always used a thread local context the same way numpy does,
> and in 3.7 it's switching to use a PEP 567 context:
>
> https://bugs.python.org/issue32630
>
> -n
>
___
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] Consider making Decimal's context use PEP 567

[Nathaniel Smith]

On Feb 7, 2018 1:54 PM, "Neil Girdhar"  wrote:

Decimal could just pull its Context object from a context variable rather
than having to pass it in to all functions.  This would be similar to how
numpy works.


Decimal has always used a thread local context the same way numpy does, and
in 3.7 it's switching to use a PEP 567 context:

https://bugs.python.org/issue32630

-n
___
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] Complicate str methods

[Serhiy Storchaka]

04.02.18 00:04, Franklin? Lee пише:
Let s be a str. I propose to allow these existing str methods to take 
params in new forms.


s.replace(old, new):
     Allow passing in a collection of olds.
     Allow passing in a single argument, a mapping of olds to news.
     Allow the olds in the mapping to be tuples of strings.

s.split(sep), s.rsplit, s.partition:
     Allow sep to be a collection of separators.

s.startswith, s.endswith:
     Allow argument to be a collection of strings.

s.find, s.index, s.count, x in s:
     Similar.
     These methods are also in `list`, which can't distinguish between 
items, subsequences, and subsets. However, `str` is already inconsistent 
with `list` here: list.M looks for an item, while str.M looks for a 
subsequence.


s.[r|l]strip:
     Sadly, these functions already interpret their str arguments as 
collections of characters.


The name of complicated str methods is regular expressions. For doing 
these operations efficiently you need to convert arguments in special 
optimized form. This is what re.compile() does. If make a compilation on 
every invocation of a str method, this will add too large overhead and 
kill performance.


Even for simple string search a regular expression can be more efficient 
than a str method.


$ ./python -m timeit -s 'import re; p = re.compile("spam"); s = 
"spa"*100+"m"' -- 'p.search(s)'

50 loops, best of 5: 680 nsec per loop

$ ./python -m timeit -s 's = "spa"*100+"m"' -- 's.find("spam")'
20 loops, best of 5: 1.09 usec per loop

___
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] Consider generalizing Decimal to support arbitrary radix

[Neil Girdhar]

Oh, and to answer your specific question, I want to change the way
arithmetic is done.  I want it to be done in a different radix.

On Wed, Feb 7, 2018 at 5:07 PM Neil Girdhar  wrote:

> I wanted to have something like a binary floating point number like
> 0.11011.  Ideally, it would be as simple as Decimal('0.11011', radix=2).
>
> Best,
>
> Neil
>
> On Wed, Feb 7, 2018 at 5:02 PM Chris Angelico  wrote:
>
>> On Thu, Feb 8, 2018 at 8:49 AM, Neil Girdhar 
>> wrote:
>> > Arbitrary radix comes up every now and then and Decimal already has a
>> > radix() method.  It would be nice when initializing a Decimal object to
>> be
>> > able to specify an arbitrary radix>=2.
>> >
>>
>> The radix method always returns 10, because decimal.Decimal always
>> operates in base 10. Are you looking for a way to change the way
>> arithmetic is done, or are you looking for a way to construct a
>> Decimal from a string of digits and an arbitrary base (the way
>> int("...", x) does)?
>>
>> ChrisA
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "python-ideas" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/python-ideas/twWEvFwahaQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> python-ideas+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
___
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] Consider generalizing Decimal to support arbitrary radix

[Neil Girdhar]

I wanted to have something like a binary floating point number like
0.11011.  Ideally, it would be as simple as Decimal('0.11011', radix=2).

Best,

Neil

On Wed, Feb 7, 2018 at 5:02 PM Chris Angelico  wrote:

> On Thu, Feb 8, 2018 at 8:49 AM, Neil Girdhar 
> wrote:
> > Arbitrary radix comes up every now and then and Decimal already has a
> > radix() method.  It would be nice when initializing a Decimal object to
> be
> > able to specify an arbitrary radix>=2.
> >
>
> The radix method always returns 10, because decimal.Decimal always
> operates in base 10. Are you looking for a way to change the way
> arithmetic is done, or are you looking for a way to construct a
> Decimal from a string of digits and an arbitrary base (the way
> int("...", x) does)?
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/twWEvFwahaQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Consider generalizing Decimal to support arbitrary radix

[Chris Angelico]

On Thu, Feb 8, 2018 at 8:49 AM, Neil Girdhar  wrote:
> Arbitrary radix comes up every now and then and Decimal already has a
> radix() method.  It would be nice when initializing a Decimal object to be
> able to specify an arbitrary radix>=2.
>

The radix method always returns 10, because decimal.Decimal always
operates in base 10. Are you looking for a way to change the way
arithmetic is done, or are you looking for a way to construct a
Decimal from a string of digits and an arbitrary base (the way
int("...", x) does)?

ChrisA
___
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] Consider making Decimal's context use PEP 567

[Neil Girdhar]

Decimal could just pull its Context object from a context variable rather 
than having to pass it in to all functions.  This would be similar to how 
numpy works.
___
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] Complicate str methods

[Neil Girdhar]

On Saturday, February 3, 2018 at 8:10:38 PM UTC-5, Steven D'Aprano wrote:
>
> On Sun, Feb 04, 2018 at 10:54:53AM +1100, Chris Angelico wrote: 
>
> > Picking up this one as an example, but this applies to all of them: 
> > the transformation you're giving here is dangerously flawed. If there 
> > are any regex special characters in the strings, this will either bomb 
> > with an exception, or silently do the wrong thing. The correct way to 
> > do it is (at least, I think it is): 
> > 
> > re.match("|".join(map(re.escape, strings)), testme) 
> > 
> > With that gotcha lurking in the wings, I think this should not be 
> > cavalierly dismissed with "just 'import re' and be done with it". 
>
> Indeed. 
>
> This is not Perl and "just use a regex" is not a close fit to the 
> culture of Python. 
>
> Regexes are a completely separate mini-language, and one which is the 
> opposite of Pythonic. Instead of "executable pseudo-code", regexes are 
> excessively terse and cryptic once you get past the simple examples. 
> Doing anything complicated using regexes is painful. 
>
> Even Larry Wall has criticised regex syntax for choosing poor defaults 
> and information density. (Rarely used symbols get a single character, 
> while frequently needed symbols are coded as multiple characters, so 
> Perlish syntax has the worst of both worlds: too terse for casual users, 
> too verbose for experts, hard to maintain for everyone.) 
>
> Any serious programmer should have at least a passing familiarity with 
> regexes. They are ubiquitous, and useful, especially as a common 
> mini-language for user-specified searching. 
>
> But I consider regexes to be the fall-back for when Python doesn't 
> support the kind of string matching operation I need, not the primary 
> solution. I would never write: 
>
> re.match('start', text) 
> re.search('spam', text) 
>
> when 
>
> text.startswith('start') 
> text.find('spam') 
>
> will do. I think this proposal to add more power to the string methods 
> is worth some serious consideration. 
>

Completely agree with the sentiment.  I don't know about this proposal, but 
complicated regular expressions are never a good solution even when they 
are the best solution.  

>
>
>
> -- 
> Steve 
> ___ 
> Python-ideas mailing list 
> python...@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] Consider generalizing Decimal to support arbitrary radix

[Neil Girdhar]

Arbitrary radix comes up every now and then and Decimal already has a 
radix() method.  It would be nice when initializing a Decimal object to be 
able to specify an arbitrary radix>=2.
___
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] Possible Enhancement to py Launcher - set default

[Steve Dower]

Checking the Version (!=SysVersion) property should be enough (and perhaps we 
need to set it properly on install). The launcher currently only works with 
PythonCore entries anyway, so no need to worry about other distros.

PEP 514 allows for other keys to be added as well (it specifies a minimum set), 
so we could just set one for this. “NoDefaultLaunch” or similar.

Finally, if someone created a script for setting py.ini, it could probably be 
included in the Tools directory. Wouldn’t be run on install or get a start menu 
shortcut though, just to set expectations right.

Top-posted from my Windows phone

From: Paul Moore
Sent: Wednesday, February 7, 2018 7:37
To: Alex Walters
Cc: Python-Ideas
Subject: Re: [Python-ideas] Possible Enhancement to py Launcher - set default

I don't think so. As an example, what registry keys would Anaconda
write to say that Release 5.2.1.7 is a pre-release version? Or would
the py launcher have to parse the version looking for rc/a/b/... tags?
And distributions would have to agree on how they record pre-release
version numbers?

Paul

On 7 February 2018 at 14:57, Alex Walters  wrote:
>
>
>> -Original Message-
>> From: Paul Moore [mailto:p.f.mo...@gmail.com]
>> Sent: Wednesday, February 7, 2018 4:15 AM
>> To: Alex Walters 
>> Cc: Steve Barnes ; Python-Ideas > id...@python.org>
>> Subject: Re: [Python-ideas] Possible Enhancement to py Launcher - set
>> default
>>
> ...
>>
>> IMO the biggest technical issue with this is that as far as I can see
>> PEP 514 doesn't specify a way to determine if a given Python is a
>> pre-release version. If we do want to implement this (I'm +0 on it,
>> personally) then I think the starting point would need to be an update
>> to PEP 514 to include that data.
>>
>> Paul
>
> Looking at pep 514, it looks like sys.winver is what would have to change to 
> support reporting the release status to the registry.  I don't think 514 has 
> to change at all if sys.winver changes.  Is that a correct interpretation?
>
___
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/

Re: [Python-ideas] Possible Enhancement to py Launcher - set default

[Paul Moore]

I don't think so. As an example, what registry keys would Anaconda
write to say that Release 5.2.1.7 is a pre-release version? Or would
the py launcher have to parse the version looking for rc/a/b/... tags?
And distributions would have to agree on how they record pre-release
version numbers?

Paul

On 7 February 2018 at 14:57, Alex Walters  wrote:
>
>
>> -Original Message-
>> From: Paul Moore [mailto:p.f.mo...@gmail.com]
>> Sent: Wednesday, February 7, 2018 4:15 AM
>> To: Alex Walters 
>> Cc: Steve Barnes ; Python-Ideas > id...@python.org>
>> Subject: Re: [Python-ideas] Possible Enhancement to py Launcher - set
>> default
>>
> ...
>>
>> IMO the biggest technical issue with this is that as far as I can see
>> PEP 514 doesn't specify a way to determine if a given Python is a
>> pre-release version. If we do want to implement this (I'm +0 on it,
>> personally) then I think the starting point would need to be an update
>> to PEP 514 to include that data.
>>
>> Paul
>
> Looking at pep 514, it looks like sys.winver is what would have to change to 
> support reporting the release status to the registry.  I don't think 514 has 
> to change at all if sys.winver changes.  Is that a correct interpretation?
>
___
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] importlib: making FileFinder easier to extend

[Erik Bray]

Hello,

Brief problem statement: Let's say I have a custom file type (say,
with extension .foo) and these .foo files are included in a package
(along with other Python modules with standard extensions like .py and
.so), and I want to make these .foo files importable like any other
module.

On its face, importlib.machinery.FileFinder makes this easy.  I make a
loader for my custom file type (say, FooSourceLoader), and I can use
the FileFinder.path_hook helper like:

sys.path_hooks.insert(0, FileFinder.path_hook((FooSourceLoader, ['.foo'])))
sys.path_importer_cache.clear()

Great--now I can import my .foo modules like any other Python module.
However, any standard Python modules now cannot be imported.  The way
PathFinder sys.meta_path hook works, sys.path_hooks entries are
first-come-first-serve, and furthermore FileFinder.path_hook is very
promiscuous--it will take over module loading for *any* directory on
sys.path, regardless what the file extensions are in that directory.
So although this mechanism is provided by the stdlib, it can't really
be used for this purpose without breaking imports of normal modules
(and maybe it's not intended for that purpose, but the documentation
is unclear).

There are a number of different ways one could get around this.  One
might be to pass FileFinder.path_hook loaders/extension pairs for all
the basic file types known by the Python interpreter.  Unfortunately
there's no great way to get that information.  *I* know that I want to
support .py, .pyc, .so etc. files, and I know which loaders to use for
them.  But that's really information that should belong to the Python
interpreter, and not something that should be reverse-engineered.  In
fact, there is such a mapping provided by
importlib.machinery._get_supported_file_loaders(), but this is not a
publicly documented function.

One could probably think of other workarounds.  For example you could
implement a custom sys.meta_path hook.  But I think it shouldn't be
necessary to go to higher levels of abstraction in order to do
this--the default sys.path handler should be able to handle this use
case.

In order to support adding support for new file types to
sys.path_hooks, I ended up implementing the following hack:

#
import os
import sys

from importlib.abc import PathEntryFinder


@PathEntryFinder.register
class MetaFileFinder:
"""
A 'middleware', if you will, between the PathFinder sys.meta_path hook,
and sys.path_hooks hooks--particularly FileFinder.

The hook returned by FileFinder.path_hook is rather 'promiscuous' in that
it will handle *any* directory.  So if one wants to insert another
FileFinder.path_hook into sys.path_hooks, that will totally take over
importing for any directory, and previous path hooks will be ignored.

This class provides its own sys.path_hooks hook as follows: If inserted
on sys.path_hooks (it should be inserted early so that it can supersede
anything else).  Its find_spec method then calls each hook on
sys.path_hooks after itself and, for each hook that can handle the given
sys.path entry, it calls the hook to create a finder, and calls that
finder's find_spec.  So each sys.path_hooks entry is tried until a spec is
found or all finders are exhausted.
"""

def __init__(self, path):
if not os.path.isdir(path):
raise ImportError('only directories are supported', path=path)

self.path = path
self._finder_cache = {}

def __repr__(self):
return '{}({!r})'.format(self.__class__.__name__, self.path)

def find_spec(self, fullname, target=None):
if not sys.path_hooks:
return None

for hook in sys.path_hooks:
if hook is self.__class__:
continue

finder = None
try:
if hook in self._finder_cache:
finder = self._finder_cache[hook]
if finder is None:
# We've tried this finder before and got an ImportError
continue
except TypeError:
# The hook is unhashable
pass

if finder is None:
try:
finder = hook(self.path)
except ImportError:
pass

try:
self._finder_cache[hook] = finder
except TypeError:
# The hook is unhashable for some reason so we don't bother
# caching it
pass

if finder is not None:
spec = finder.find_spec(fullname, target)
if spec is not None:
return spec

# Module spec not found through any of the finders
return None

def invalidate_caches(self):
for finder in self._finder_cache.values():
finder.invalidate_caches()

Re: [Python-ideas] Possible Enhancement to py Launcher - set default

[Alex Walters]

> -Original Message-
> From: Paul Moore [mailto:p.f.mo...@gmail.com]
> Sent: Wednesday, February 7, 2018 4:15 AM
> To: Alex Walters 
> Cc: Steve Barnes ; Python-Ideas  id...@python.org>
> Subject: Re: [Python-ideas] Possible Enhancement to py Launcher - set
> default
> 
...
> 
> IMO the biggest technical issue with this is that as far as I can see
> PEP 514 doesn't specify a way to determine if a given Python is a
> pre-release version. If we do want to implement this (I'm +0 on it,
> personally) then I think the starting point would need to be an update
> to PEP 514 to include that data.
> 
> Paul

Looking at pep 514, it looks like sys.winver is what would have to change to 
support reporting the release status to the registry.  I don't think 514 has to 
change at all if sys.winver changes.  Is that a correct interpretation? 

___
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] Possible Enhancement to py Launcher - set default

[Paul Moore]

On 7 February 2018 at 05:36, Alex Walters  wrote:
> While this thread has focused on the location and means of managing py.ini,
> I think there is a more general solution that should be considered to the
> original problem, as described.  The problem isn't that it's difficult or
> non-obvious how to set the default python for the py.exe launcher (that's a
> possible documentation issue, and I argue a minor tooling problem), the
> problem is that the launcher, by default, selects the latest version of
> python as the default, regardless of that python's release status.  Without
> looking at the C code (I haven't but should), I don't think it would be too
> difficult to teach py.exe to not auto-select dev, alpha, or beta versions of
> python without being told explicitly to do so.
>
> For example (for the archives, this is written in February 2018, when 3.7 is
> in its beta), on a system with 3.6 and 3.7 installed...
>
>py.exe myfile.py  REM should run 3.6, unless shebang overrides
>py.exe -3.7 myfile.py REM should run 3.7 beta
>
> And after 3.7.0 final is released and installed on said system, py.exe
> myfile.py should run 3.7.
>
> Is this difficult to implement?  Is this a bad idea?

IMO the biggest technical issue with this is that as far as I can see
PEP 514 doesn't specify a way to determine if a given Python is a
pre-release version. If we do want to implement this (I'm +0 on it,
personally) then I think the starting point would need to be an update
to PEP 514 to include that data.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/