[Python-ideas] Giving Decimal a global context was a mistake?

Broken off from the "Custom literals, a la C++" thread: Greg Ewing wrote: >Personally I think giving Decimal a global context was a mistake, [...] > so arguing that "it's no worse than Decimal" isn't going to do much > to convince me. :-) I'd be curious to know what alternatives you see. When a

[Python-ideas] Re: Make 10**400 / 1e200 work?

On Sun, Feb 20, 2022 at 3:59 PM Stefan Pochmann wrote: > Mark Dickinson wrote: > > Unrelated question: under this proposal, what would you want > > `Fraction(10**400) / 1e200` to do? > > Somehow that sounds like a trick question :-). I'd say 1e200, yes, > although

[Python-ideas] Re: Make 10**400 / 1e200 work?

On Sat, Feb 19, 2022 at 1:37 PM Stefan Pochmann wrote: > So could/should 10**400 / 1e200 be implemented to do that instead of > raising the error? Or is it a too rare use case and not worth the effort, > or does something else speak against it? > For me, it's not so much that it's not worth the

[Python-ideas] Re: NAN handling in statistics functions

Returning a NaN by default has the advantage of being consistent with IEEE 754 semantics for sequence-based operations (like `sum` and `dot`) and with existing Python `math` module functions like `fsum`, `prod` and `hypot`. In IEEE 754, the majority of operations silently return a NaN (not

[Python-ideas] Re: Consider having numbers.Real provide __complex__?

Inheriting from `numbers.Real` _does_ give you `__complex__`, though: https://github.com/python/cpython/blob/314b8787e0c50985ba708034b84ff5b37a1d47de/Lib/numbers.py#L245-L248 Is it instead `float.__complex__` you're asking for? ___ Python-ideas mailing

[Python-ideas] Re: Please consider adding numbers.Boolean

[Neil Girdhar] > It seems that builtins.bool and numpy.bool_ would both be elements of Boolean I'd be wary of trying to abstract over `bool` and `numpy.bool_`. There are some fundamental differences: - `bool` subclasses `int`; `numpy.bool_` is not a subclass of any integer type - moreover,

[Python-ideas] Expose PyFloat_AsDouble to Python

Here's the short version: * "Convert float-like object to a float" is a useful operation * For a C extension, there's an obvious way to spell that operation: use `PyFloat_AsDouble` * In pure Python, there's no Obvious Way To Do It * Proposal: expose the equivalent of

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

> > > Proposed alternatives > = > > Keeping with the good practice of referencing sketches from Monty > Python's > Flying Circus, this PEP proposes to adopt the fruits mentioned in the > `"Self-Defence Against Fresh Fruit" sketch`_: > > * raspberry (not currently in use) > *

[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

On Wed, Mar 4, 2020 at 4:08 PM David Mertz wrote: > > And I'm also fudging the Decimal question too. The relationship between > *expressions* can vary by decimal context. But not of a value named by a > single variable. > Right: Decimal objects don't know anything about context, and

[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

On Wed, Mar 4, 2020 at 9:22 AM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > Is there any commonly used or even imaginable useful type that uses them > in weirder ways than set and float (which are both partially ordered) [...] Nitpick: why do you say "partially ordered"

[Python-ideas] Re: Add Binary module.

ananthakrishnan15.2001＠gmail.com wrote: > binary.twos_complement(0b0011)==1101 > binary.twos_complement(0b0011)==1101 How would you make that possible, when `0b0011` and `0b0011` are the exact same integer? ___ Python-ideas mailing list --

[Python-ideas] Re: Add Binary module.

ananthakrishnan15.2001＠gmail.com wrote: > we can use 0b1100 instead of 1100.Then the output of > binary.twos_complement(0b1100) will be 0b0100 That would be printed as `4`. Is that what you want? Supposing we accept that `binary.twos_complement(0b1100) == 0b0100`. What would

[Python-ideas] Re: Add Binary module.

ananthakrishnan15.2001＠gmail.com wrote: > >>> binary.ones_complement(1101100001) > 0010011110 I see. So you want `binary.ones_complement` to accept a nonnegative Python `int` whose decimal expansion consists entirely of ones and zeros, interpret that decimal expansion as though it's a

[Python-ideas] Re: Add Binary module.

ananthakrishnan15.2001＠gmail.com wrote: > I'm proposing a module that has functions intended to work with existing > python > types. Okay, great. *Which* Python types, specifically? `int`? `bytes`? To help us understand, please can you show example inputs to and output from your proposed

[Python-ideas] Re: Add Binary module.

ananthakrishnan15.2001＠gmail.com wrote: > In the below examples a and b are binary numbers. Please can you clarify what this means, in Python terms? Are you proposing a _new_ Python type that represents a "binary number", or is `binary.add` (for example) intended to work with existing Python

[Python-ideas] Re: Traits

Stéfane Fermigier wrote: > Note that there are several packages already in PyPI: > > https://pypi.org/project/traits/ > https://pypi.org/project/strait/ That first package is unrelated, I'm afraid: completely different meaning of the word "trait". In that case, a "trait" is an observable, typed

[Python-ideas] Re: Testing for NANs [was Re: Fix statistics.median()?]

Honestly, I don't think we should let the behaviour of signaling NaNs influence the design decisions much here, beyond that yes, `is_nan(some_decimal_snan)` should return `True` (and not raise). They hardly ever turn up in practice, and unlike regular NaNs, you're unlikely to encounter them by

[Python-ideas] Re: Testing for NANs [was Re: Fix statistics.median()?]

The failure of the `x == x` test for signaling NaNs may be a non-issue in practice, for a couple of reasons; one is that signaling NaNs are *supposed* to raise when you do almost anything at all with them. The other is that, unlike a quiet NaN, it's hard to imagine how anyone would ever get a

[Python-ideas] Re: Segmentation of string

Apologies for the bad formatting. Here are the relevant bits, better formatted (I hope): >>> segment = lambda s, m: (tuple(s[i:j] for i, j in zip((0,)+c, c+(len(s),))) ... for c in itertools.combinations(range(1, len(s)), m-1)) >>> >>> list(segment("12345", m=3)) [('1',

[Python-ideas] Re: Segmentation of string

On Sat, Dec 14, 2019 at 3:56 PM David Mertz wrote: > [...] compositions are simply the permutations on the full length of the > list of each partition. > Using permutations of partitions would be overkill. For compositions of a given fixed length, it's much easier to compute them directly using

Re: [Python-ideas] "given" vs ":=" in list comprehensions

On Sun, May 13, 2018 at 1:34 AM, Andre Roberge wrote: > First example: single temporary assignment, done four different ways. > > 1) using := > > real_roots = [ (-b/(2*a) + (D:= sqrt( (b/(2*a))**2 - c/a), -b/(2*a) - D) > for a in range(10) >

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

On Wed, Feb 7, 2018 at 10:50 PM, Steven D'Aprano wrote: > 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

Re: [Python-ideas] Way to repeat other than "for _ in range(x)"

On Thu, Mar 30, 2017 at 10:18 AM, Markus Meskanen wrote: > And wondered, why don't we have a way to repeat other than looping over > range() and using a dummy variable? If it's the assignment to a dummy variable that bothers you, the language already has a way around

Re: [Python-ideas] Ideas for improving the struct module

On Fri, Jan 20, 2017 at 12:30 AM, Steven D'Aprano wrote: > Does it require a PEP just to add one more > format code? (Maybe it will, if the format code requires a complete > re-write of the entire module.) Yes, I think a PEP would be useful in this case. The proposed change

Re: [Python-ideas] Ideas for improving the struct module

On Thu, Jan 19, 2017 at 1:27 AM, Steven D'Aprano wrote: > [...] struct already supports > variable-width formats. Unfortunately, that's not really true: the Pascal strings it supports are in some sense variable length, but are stored in a fixed-width field. The internals of

Re: [Python-ideas] PEP 531: Existence checking operators

On Fri, Oct 28, 2016 at 9:30 AM, Nick Coghlan wrote: > [...] the current practicises of: > > * obj is not None (many different use cases) > * obj is not Ellipsis (in multi-dimensional slicing) Can you elaborate on this one? I don't think I've ever seen an `is not Ellipsis`