[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson added the comment: Sorry that I've taken so long to get back to this. I've just updated the PR, and I think it's ready to go. Looks like it does need you to update your GitHub username here in the "Your Details" section of the bugtracker, though; sorry about that

[issue34484] Unicode HOWTO incorrectly refers to Private Use Area for surrogateescape

Mark Dickinson added the comment: Whoops. Sorry, that should be #4153. -- ___ Python tracker <https://bugs.python.org/issue34484> ___ ___ Python-bugs-list mailin

[issue34484] Unicode HOWTO incorrectly refers to Private Use Area for surrogateescape

Mark Dickinson added the comment: For history, this text was introduced as a result of issue #4163. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34484] Unicode HOWTO incorrectly refers to Private Use Area for surrogateescape

New submission from Mark Dickinson : The Unicode HOWTO currently has contains this text in the "Files in an Unknown Encoding" section [1]: > The surrogateescape error handler will decode any non-ASCII bytes as code > points in the Unicode Private Use Area ranging from

[issue34350] Non obvious logging handler behaviour

Change by Mark Dickinson : -- nosy: +vinay.sajip ___ Python tracker <https://bugs.python.org/issue34350> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34351] Python 3.7 - Issues Installing Scikit Learn

Mark Dickinson added the comment: Closing as duplicate of #34348. -- nosy: +mark.dickinson resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34348] Python 3.7 - Issues Installing Scikit Learn

Mark Dickinson added the comment: > How do I reach to the upstream scikit-learn folks ? See http://scikit-learn.org/stable/support.html Closing here. -- resolution: -> third party stage: -> resolved status: open -> closed ___ Py

[issue34348] Python 3.7 - Issues Installing Scikit Learn

Mark Dickinson added the comment: Have you reported this upstream to the scikit-learn folks? scikit-learn is not part of core Python, so there's probably not a lot we can do here. -- nosy: +mark.dickinson ___ Python tracker <ht

[issue34350] Non obvious logging handler behaviour

Mark Dickinson added the comment: The behaviour is long-standing and documented, in the note just under this entry: https://docs.python.org/3/library/logging.html?highlight=logging#logging.log But I do agree that it's surprising and (at least for me) undesirable behaviour, in that it makes

[issue34337] Fail to get a right answer for 1.2%0.2

Mark Dickinson added the comment: This isn't a bug: in short, you're evaluating a discontinuous function very close to a discontinuity; the errors inherent in floating-point arithmetic put you the "wrong" side of the discontinuity. Or more simply, with binary floating-point, Wh

[issue33089] Add multi-dimensional Euclidean distance function to the math module

Mark Dickinson added the comment: For the record, let me register my objection here. I'm not convinced by adding math.dist, and am surprised that this was committed. Almost all the discussion in this issue was about adding multi-argument hypot, which seems like an obviously useful building

[issue33083] math.factorial accepts non-integral Decimal instances

Mark Dickinson added the comment: [Victor] > Is it really important to accept integral float? Possibly not, but acceptance of integral floats is deliberate, by-design, tested behaviour, so it at least deserves a deprecation period if we're going to get rid of it. (I'm -

[issue34273] %f is confusingly associated with fixed point format

Mark Dickinson added the comment: FTR, here "fixed point" refers to the output representation (a decimal string) rather than the input (a floating-point binary value). The output of %f gives a *fixed* number of places after the decimal point (6 by default). Contrast with %e, w

[issue33083] math.factorial accepts non-integral Decimal instances

Mark Dickinson added the comment: So I'm against _adding_ support for Decimal and Fraction on various grounds: (1) If it's our intention to deprecate acceptance of non-integral types, then it seems odd to deliberately add a new intentional feature (acceptance of integral-valued Decimal

[issue33083] math.factorial accepts non-integral Decimal instances

Mark Dickinson added the comment: > accepting non-integral floats but not non-integral Decimals and Fractions. I don't think anyone is proposing to accept non-integral floats. non-integral floats are _already_ rejected with a ValueError. Did you mean "integral" instead of

[issue33083] math.factorial accepts non-integral Decimal instances

Mark Dickinson added the comment: [Tal Einat] > So we keep things consistent by supporting Decimal and Fraction inputs, but > raising ValueError if the value isn't a non-negative integer? Re-reading the issue comments, my preference is still the same as expressed in msg

[issue29710] Incorrect representation caveat on bitwise operation docs

Mark Dickinson added the comment: > 4. Performing these calculations with at least one extra sign extension bit > in a finite two's complement representation (a working bit-width of ``1 + > max(x.bit_length(), y.bit_length()`` or more) is sufficient to get the same > result as i

[issue29710] Incorrect representation caveat on bitwise operation docs

Mark Dickinson added the comment: The wording for change 1 looks fine to me. For change 2, the mention of the internal representation is misleading, since the internal representation of (long) integers in current CPython is effectively sign-magnitude, and so there are some shenanigans

[issue34100] Python doesn't intern integers in a tuple of constant literals

Mark Dickinson added the comment: This was a side-effect of #29469. -- nosy: +inada.naoki, mark.dickinson, serhiy.storchaka, vstinner ___ Python tracker <https://bugs.python.org/issue34

[issue34023] timedelta(seconds=x) strange results when type(x) == np.int32

Change by Mark Dickinson : -- nosy: +belopolsky ___ Python tracker <https://bugs.python.org/issue34023> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34023] timedelta(seconds=x) strange results when type(x) == np.int32

New submission from Mark Dickinson : On Python 2.x on Windows, creating a timedelta with an `np.int32` instance for the number of seconds can (somewhat) silently give wrong results. Enthought Deployment Manager -- https://www.enthought.com Python 2.7.13 |Enthought, Inc. (x86_64)| (default

[issue34016] Bug in sort()

Mark Dickinson added the comment: This isn't a bug: I'm guessing that you expected an output of `['6', '8', '10']`, but in the example you give you're sorting strings rather than numbers, and those strings are sorted lexicographically (i.e., using "dictionary order") as normal. I

[issue33954] float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error

Change by Mark Dickinson : -- nosy: +eric.smith, mark.dickinson ___ Python tracker <https://bugs.python.org/issue33954> ___ ___ Python-bugs-list mailin

[issue24567] random.choice IndexError due to double-rounding

Mark Dickinson added the comment: Some relevant notes from Vincent Lefèvre here: http://www.vinc17.net/research/extended.en.html -- ___ Python tracker <https://bugs.python.org/issue24

[issue24567] random.choice IndexError due to double-rounding

Mark Dickinson added the comment: [Tim] > Mark, do you believe that 32-bit Linux uses a different libm? I don't know. But I'd expect to see accuracy losses as a result of forcing 53-bit precision, and I wouldn't be totally surprised to see other more catastrophic failure modes (infin

[issue24567] random.choice IndexError due to double-rounding

Mark Dickinson added the comment: [Tim] > a couple lines of inline assembler could be added at Python startup to > set the Pentium's FPU "precision control" bits to "round to 53 bits" mode On second thoughts, I don't think this will work; or at least, not easily. Th

[issue24567] random.choice IndexError due to double-rounding

Mark Dickinson added the comment: > Python _configuration_ should be changed to disable double rounding on such > platforms That sounds good to me, with the nitpick that setting an x87 FPU to 53-bit precision still doesn't avoid potential double rounding on underflow, and I'm not

[issue33784] hash collision in instances of ipaddress.ip_network

Mark Dickinson added the comment: Thanks, Francois. Indeed, comparing hashes isn't a good way to implement equality. :-) Closing here. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue33784] hash collision in instances of ipaddress.ip_network

Change by Mark Dickinson : -- resolution: -> not a bug status: open -> pending ___ Python tracker <https://bugs.python.org/issue33784> ___ ___ Python-bugs-

[issue33784] hash collision in instances of ipaddress.ip_network

Change by Mark Dickinson : -- nosy: +serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue33784> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33784] hash collision in instances of ipaddress.ip_network

Mark Dickinson added the comment: > I'd propose hashing a tuple instead of using the xor. To be clear; I'd propose this _only_ if there's evidence that the current hashing scheme is unsatisfactory for real-world use-cases. Otherwise, on an "if it's not broken, don't fix it" b

[issue33784] hash collision in instances of ipaddress.ip_network

Mark Dickinson added the comment: This shouldn't be a problem: there's no rule that says that different objects should have different hashes. Indeed, with a countable infinity of possible different hashable inputs, a deterministic hashing algorithm, and only finitely many outputs

[issue33770] base64 throws 'incorrect padding' exception even though the string length is a multiple of 4

Mark Dickinson added the comment: This doesn't look like a valid base64 string to me: the padding (if present) at the end of the string should be either "=" or "==", never "===". Is the length of the decoded string equal to 58? If so, what's the last ch

[issue33636] Unexpected behavior with * and arrays

Mark Dickinson <dicki...@gmail.com> added the comment: @nanthil: If you want to discuss the reasons behind this design decision further, I'd suggest asking on one of the mailing lists, e.g. https://mail.python.org/mailman/listinfo/python-list This is not the right forum for this disc

[issue33448] Output_Typo_Error

Change by Mark Dickinson <dicki...@gmail.com>: -- stage: -> resolved status: pending -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.

[issue33572] False/True as dictionary keys treated as integers

Mark Dickinson <dicki...@gmail.com> added the comment: It's documented here: https://docs.python.org/3/library/stdtypes.html#mapping-types-dict > Numeric types used for keys obey the normal rules for numeric > comparison: if two numbers compare equal (such as 1 and 1.0) then

[issue25478] Consider adding a normalize() method to collections.Counter()

Mark Dickinson <dicki...@gmail.com> added the comment: The point is that if you cache the total and update on each operation, you end up with a total that depends not just on the current contents of the Counter, but also on the history of operations. That seems like a bad idea: you could

[issue25478] Consider adding a normalize() method to collections.Counter()

Mark Dickinson <dicki...@gmail.com> added the comment: > total should be a cached property, that's updated on every Counter update That would run into difficulties for Counters with float values: e.g., after >>> c = Counter() >>> c['spam'] = 1e100 >>

[issue15443] datetime module has no support for nanoseconds

Change by Mark Dickinson <dicki...@gmail.com>: -- nosy: +mark.dickinson ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15443> ___

[issue33448] Output_Typo_Error

Mark Dickinson <dicki...@gmail.com> added the comment: Marking as pending; we can't take this forward without more input from the OP. As far as I can tell, the documentation is perfectly correct here: I suspect that there was a misunderstanding somewhere along the line. -- as

[issue33448] Output_Typo_Error

Mark Dickinson <dicki...@gmail.com> added the comment: I can't reproduce. I'm looking at https://docs.python.org/3.6/tutorial/introduction.html#strings, and when I test things in Python 3.6.5, I see exactly the same output as given in the documentation: Python 3.6.5 (default, Mar 29 20

[issue33402] Change the fractions.Fraction class to convert to a unicode fraction string

Mark Dickinson <dicki...@gmail.com> added the comment: -1 from me. Apart from anything else, the output for a general fraction looks (to my eyes) ugly in a fixed-width font: the tiny digits are harder to read, and there's too much space between successive numerator (or denominator)

[issue33390] matmul @ operator precedence

Mark Dickinson <dicki...@gmail.com> added the comment: Gah! Forgot that my post would reset this issue to open. I'm going to close here, since this would be a sufficiently big and unlikely change that it's not going to happen without a python-ideas/python-dev discussion. -- reso

[issue33390] matmul @ operator precedence

Mark Dickinson <dicki...@gmail.com> added the comment: [Steven] > please take the idea to the numpy and/or Python-Ideas mailing lists for > further discussion: But please do read through the previous discussions before starting a new one! See the links in PEP 465, and particu

[issue33292] Fix secrets.randbelow docstring

Mark Dickinson <dicki...@gmail.com> added the comment: """Return a random integer x satisfying 0 <= x < n""" ? -- nosy: +mark.dickinson ___ Python tracker <rep...@bugs.py

[issue33305] Improve syntax error for numbers with leading zero

Mark Dickinson <dicki...@gmail.com> added the comment: For the message: > invalid token, use 0o prefix for octal integers I'd expect (without having any evidence to back this up) that the majority of people who encounter this error would be those who intended a decimal literal ra

[issue33305] Improve syntax error for numbers with leading zero

Mark Dickinson <dicki...@gmail.com> added the comment: Maybe once Python 2.7 officially reaches EOL, we can remove the syntax error altogether and allow leading zeros on decimal integer literals. -- nosy: +mark.dickinson ___ Python tracke

[issue33200] Optimize the empty set "literal"

Mark Dickinson <dicki...@gmail.com> added the comment: Does anyone seriously write "{*()}" instead of "set()"? -- nosy: +mark.dickinson ___ Python tracker <rep...@bugs.python.org> <

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Change by Mark Dickinson <dicki...@gmail.com>: -- nosy: +mark.dickinson ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24234> ___

[issue4819] Misc/cheatsheet needs updating

Mark Dickinson <dicki...@gmail.com> added the comment: Given that Misc/cheatsheet doesn't exist any more in the Python 3 repo, and Python 2 is nearing end-of-life, I suspect this should just be closed. -- stage: needs patch -> resolved status: pending

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: > Mark, I tried `Fraction(10**23) // 1e22`, and I got 10. Sorry: that result was with your PR (as it was at the time I wrote that comment). On master, you do indeed get 10. > I think the fact that floating-point rounding err

[issue33089] Add multi-dimensional Euclidean distance function to the math module

Mark Dickinson <dicki...@gmail.com> added the comment: Okay, that cut and paste didn't work so well. Just imagine an infinity symbol in those missing spaces. Trying again: > For the hypot function, hypot(±0, ±0) is +0, hypot(±∞, qNaN) is +∞, and >

[issue33089] Add multi-dimensional Euclidean distance function to the math module

Mark Dickinson <dicki...@gmail.com> added the comment: > By the same logic, if there's an infinite argument to hypot(), it doesn't > matter what any other argument is - the result is +inf regardless. Yep, that's what IEEE 754-2008 says for the two-argument case, so I think that

[issue33083] math.factorial accepts non-integral Decimal instances

Mark Dickinson <dicki...@gmail.com> added the comment: Raymond: what are your thoughts on deprecating the ability of `math.factorial` to accept a float (as in `math.factorial(5.0)` -> `120`)? For me, I'm not sure I see the value of the deprecation. It's the usual story: the answer to

[issue33089] Add multi-dimensional Euclidean distance function to the math module

Mark Dickinson <dicki...@gmail.com> added the comment: +1 for a single-rounded dot product. If we're allowed to assume IEEE 754, it's straightforward to code up something that's not too inefficient and gives correctly rounded results for "normal" cases, using a combina

[issue33084] Computing median, median_high an median_low in statistics library

Mark Dickinson <dicki...@gmail.com> added the comment: > then the answer being 90 is correct,right? How do you deduce that? Why 90 rather than 85 (or 87.5, or some other value)? For what it's worth, NumPy gives a result of NaN for the median of an array that contains NaNs: >>&

[issue33084] Computing median, median_high an median_low in statistics library

Mark Dickinson <dicki...@gmail.com> added the comment: > Will just removing all np.nan values do the job? Unfortunately, I don't think it's that simple. You want consistency across the various library calls, so if the various `median` functions are changed to treat NaNs as mis

[issue33083] math.factorial accepts non-integral Decimal instances

Mark Dickinson <dicki...@gmail.com> added the comment: I'd suggest that in the not-float branch of math_factorial, we use PyNumber_Index to catch integer-like things. (That would also be consistent with what we do in math_gcd.) -- ___

[issue25735] math.factorial doc should mention integer return type

Mark Dickinson <dicki...@gmail.com> added the comment: I opened #33083, and copied the nosy list from this issue across. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33083] math.factorial accepts non-integral Decimal instances

New submission from Mark Dickinson <dicki...@gmail.com>: Observed by Terry Reedy in the issue #25735 discussion (msg255479): >>> factorial(decimal.Decimal(5.2)) 120 This should be either raising an exception (either ValueError or TypeError, depending on whether we want to accep

[issue25735] math.factorial doc should mention integer return type

Mark Dickinson <dicki...@gmail.com> added the comment: > Should the documentation patch for this be converted to a PR I think so, yes. How about we open a new issue for the factorial(Decimal(...)) behaviour, and keep this one focused on the original repor

[issue33073] Add as_integer_ratio() to int() objects

Mark Dickinson <dicki...@gmail.com> added the comment: [Tim] > [...] what would _you_ like to see done here? Given that float.as_integer_ratio and Decimal.as_integer_ratio already exist, and that I don't have a working time machine right now, I'm in favour of adding int.as_inte

[issue33073] Add as_integer_ratio() to int() objects

Mark Dickinson <dicki...@gmail.com> added the comment: It's a "virtual" subclass. The numpy.integer parent class is registered here: https://github.com/numpy/numpy/blob/10ccfe747a68d974ff16a5c0765054b816d5486f/numpy/core/nume

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: Yes, that sort of thing is going to happen as soon as floating-point enters the mix. There will be surprises from Fraction % float as well as float % Fraction: >>> from fractions import Fraction >>> Fraction(10**23)

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: Thanks for the PR (and apologies for being slow to look at it). I think we want to use the operator_fallbacks approach for both __rfloordiv__ and __floordiv__ (and similarly for __rmod__ and __mod__), else we'll get inconsistent r

[issue33073] Add as_integer_ratio() to int() objects

Mark Dickinson <dicki...@gmail.com> added the comment: On the Fraction constructor, it looks like there's some overlap with the goals of issue #28716 here. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33073] Add as_integer_ratio() to int() objects

Change by Mark Dickinson <dicki...@gmail.com>: -- nosy: +mark.dickinson ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33073> ___

[issue8947] Provide as_integer_ratio() method to Decimal

Mark Dickinson <dicki...@gmail.com> added the comment: Apologies: the title change was accidental. Reverted. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.pytho

[issue28716] Fractions instantiation revisited

Mark Dickinson <dicki...@gmail.com> added the comment: [Eric Wieser] > This would allow the numpy `np.floating` types to take part in `Fraction` > conversion as well, which would be great. I'm confused: as far as I can tell, the NumPy floating-point types don't implement `as_i

[issue8947] Provide as_integer_ratio() method to Decimal

Change by Mark Dickinson <dicki...@gmail.com>: -- title: as_integer_ratio Decimal -> Provide as_integer_ratio() method to Decimal ___ Python tracker <rep...@bugs.python.org> <https://bugs.py

[issue8947] as_integer_ratio Decimal

Change by Mark Dickinson <dicki...@gmail.com>: -- title: Provide as_integer_ratio() method to Decimal -> as_integer_ratio Decimal ___ Python tracker <rep...@bugs.python.org> <https://bugs.py

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

Mark Dickinson <dicki...@gmail.com> added the comment: Ongoing discussion here: https://mail.python.org/pipermail/python-dev/2018-March/152358.html -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue12345] Add math.tau

Mark Dickinson <dicki...@gmail.com> added the comment: Why does this issue keep ending up as the target of unrelated PR notifications? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

Mark Dickinson <dicki...@gmail.com> added the comment: One quibble with Raymond's response: > 2) Your use case is trivially solved in a portable, trivial, and readable > > way: > >a == int(a) For Decimal, I'd recommend using `a == a.to_integral_value()` inste

[issue33002] Making a class formattable as hex/oct integer with printf-style formatting requires both __int__ and __index__ for no good reason

Mark Dickinson <dicki...@gmail.com> added the comment: Agreed that this seems wrong. -- nosy: +eric.smith, mark.dickinson ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: Elias: please do go ahead and update your PR. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32978] Issues with reading large float values in AIFC files

Mark Dickinson <dicki...@gmail.com> added the comment: > But I don't know the exact format for infinities and NaNs. >From the Intel software developer manuals: For infinities: Sign bit: 0 or 1 (positive or negative infinity) Exponent field (15 bits): all ones Significand (64 bits

[issue32978] Issues with reading large float values in AIFC files

Mark Dickinson <dicki...@gmail.com> added the comment: > What if return 80-bit infinities and NaN as 64-bit infinities and NaN and > raise an error in the case of finite numbers overflow? That's certainly reasonable from a pure floating-point-conversion perspective: it's exac

[issue32978] Issues with reading large float values in AIFC files

Mark Dickinson <dicki...@gmail.com> added the comment: > If left the OverflowError propagated I would catch it at the caller place > (_read_float() is used only once) and reraise as aifc.Error. Ah, if there's a dedicated exception type already then yes, agreed that raising

[issue32978] Issues with reading large float values in AIFC files

Mark Dickinson <dicki...@gmail.com> added the comment: > And I think that using math.ldexp() can be more preferable that pow(2.0, ...) Yes, absolutely agreed. I'll take a look at the PR. -- ___ Python tracker <rep...@bugs.python

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: [Elias Zamaria] > I see exactly that. Understood; that's how I interpreted your "changed one test to make sure that it works". It seems we understand each other. :-) So yes, one always needs to be very cautious about

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: Serhiy: I think both those results are reasonable, and not too surprising. It should be easy to understand that the mixed-type operation converts one of the arguments to float, and if that conversion overflows we get an exc

[issue32978] Issues with reading large float values in AIFC files

Mark Dickinson <dicki...@gmail.com> added the comment: I'm finding it hard to imagine why you'd ever have a sample rate greater than 1e308 in an audio file. (In fact, it's hard to imagine needing a sample rate greater than 1e6.) Raising an OverflowError for a value that's too large

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: > I'd argue against such a change in any case And apparently I already did: see issue 22444 for previous discussion on the topic. -- ___ Python tracker <rep...@bugs.python

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: > It would be a bit strange if mod with a float returns a float and floordiv > with a float returns an int. Agreed: if there are floats involved (Fraction // float or float // Fraction), I think the rule should be that we simp

[issue32968] Fraction modulo infinity should behave consistently with other numbers

Mark Dickinson <dicki...@gmail.com> added the comment: I'm not quite sure why `Fraction_instance % float_instance` wouldn't simply convert the `Fraction` to a `float` and then use the usual floating-point mod. There's the issue that you want to maintain consistency with the floordiv ope

[issue12345] Add math.tau

Change by Mark Dickinson <dicki...@gmail.com>: -- pull_requests: -5653 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue12345> ___

[issue12345] Add math.tau

Change by Mark Dickinson <dicki...@gmail.com>: -- pull_requests: -5651 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue12345> ___

[issue32923] Typo in documentation of unittest: whilst instead of while

Mark Dickinson <dicki...@gmail.com> added the comment: > lets change it to make it more approachable to non-native speakers. Sounds good to me. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32923] Typo in documentation of unittest: whilst instead of while

Mark Dickinson <dicki...@gmail.com> added the comment: Not a typo: it's a valid English word. http://dictionary.cambridge.org/grammar/british-grammar/linking-words-and-expressions/while-and-whilst -- nosy: +mark.dickinson ___ Python tracke

[issue32886] new Boolean ABC in numbers module

Mark Dickinson <dicki...@gmail.com> added the comment: > and a minimal representation of boolean logic operations that will seem > natural to anyone, don't you think ? I'm afraid I don't. :-( Issue 1: this ABC doesn't seem a good match for Python bools. If I have a bool

[issue32908] decimal ROUND_HALF_UP not according to spec for 9.95 to 10.0

Mark Dickinson <dicki...@gmail.com> added the comment: This isn't a bug. When you do `Decimal(9.95)`, you're converting the binary floating-point number `9.95` to a `Decimal` instance. The conversion is performed exactly, with no change in the value. But the *input* to the conv

[issue32886] new Boolean ABC in numbers module

Mark Dickinson <dicki...@gmail.com> added the comment: Adjusted title (since the Integer <-> Integral rename is the subject of a separate issue) and versions (since as a new feature, this can't go into Python 3.7, which is already in feature freeze). -- title: new

[issue32886] new Boolean ABC in numbers module + Integral>Integer renaming

Mark Dickinson <dicki...@gmail.com> added the comment: > This one is common to both python bool and np.bool_. It's not, though. One of my examples was using `~` (`__invert__`) from the proposed ABC). And the behaviour of that function differs between NumPy and Python I think one of

[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.

Mark Dickinson <dicki...@gmail.com> added the comment: And it's Ned's call, of course, but this smells like a new feature rather than a fix to me, and I'm not sure why it would be considered special enough to break the usual release-process rules. Serhiy's point about pickles

[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.

Mark Dickinson <dicki...@gmail.com> added the comment: +1 for the Integer alias, if it can be made to work. The "Integral" name has always felt clunky and non-obvious to me. -- nosy: +mark.dickinson ___ Python tracker <rep...@bugs

[issue29282] Fused multiply-add: proposal to add math.fma()

Mark Dickinson <dicki...@gmail.com> added the comment: > Is this because of the inf/NaN discrimination hiccups [...] No, more than that. If it were just that, we could work around it by adding the appropriate special case handling before calling the libm fma (as has been done, re

[issue32886] new Boolean ABC in numbers module + Integral>Integer renaming

Mark Dickinson <dicki...@gmail.com> added the comment: > - register numpy bool ('np.bool_') as a virtual subclass of 'Boolean' only Be aware that np.bool_ behaves differently from Python's bool type in a number of ways. It may not make sense to have something that tries to abstract o

[issue29282] Fused multiply-add: proposal to add math.fma()

Mark Dickinson <dicki...@gmail.com> added the comment: > Do I read this thread correctly assuming that this hasn't been implemented > yet? Yes. Existing libm implementations don't work, so simply wrapping the libm function isn't enough. And writing an implementation from scr

[issue26743] Unable to import random with python2.7 on power pc based machine

Mark Dickinson <dicki...@gmail.com> added the comment: @csabella: Agreed. Let's close. Thanks! -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

<    8   9   10   11   12   13   14   15   16   17   >