PEP 682 (Format Specifier for Signed Zero) has been accepted! Please see
https://discuss.python.org/t/accepting-pep-682-format-specifier-for-signed-zero/14088
Thanks to all involved,
Mark
___
Python-Dev mailing list -- python-dev@python.org
To unsubscri
On Mon, Feb 7, 2022 at 5:11 PM Victor Stinner wrote:
> I made a change to require C99 "NAN" constant [...]
There's a separate discussion topic lurking here. It's equally in need of
discussion here (IMO), but it's orthogonal to the "should we require C99"
discussion. I've changed the subject li
On Sun, Jan 16, 2022 at 9:28 PM Guido van Rossum wrote:
> Does the optimization for //10 actually help in the real world? [...]
>
Yep, I don't know. If 10 is *not* the most common small divisor in real
world code, it must at least rank in the top five. I might hazard a guess
that division by 2 w
On Sun, Jan 16, 2022 at 12:08 PM Mark Dickinson wrote:
> So gcc is anticipating divisions by 10 and introducing special-case
> divide-by-reciprocal-multiply code for that case, and presumably the
> profile generated for the PGO backs up this being a common enough case, so
> we end
On Sun, Jan 16, 2022 at 4:11 PM Terry Reedy wrote:
>
>
> https://stackoverflow.com/questions/41183935/why-does-gcc-use-multiplication-by-a-strange-number-in-implementing-integer-divi
>
> and
>
>
> https://stackoverflow.com/questions/30790184/perform-integer-division-using-multiplication
>
> have
On Sat, Jan 15, 2022 at 8:12 PM Tim Peters wrote:
> Something is missing here, but can't guess what without seeing the
> generated machine code.But I trust Mark will do that.
>
Welp, there goes my weekend. :-)
$ python -m timeit -n 150 -s "x = 10**1000" "x//10"
150 loops, best of 5: 3
On Sun, Jan 2, 2022 at 10:35 AM Mark Dickinson wrote:
> Division may still be problematic.
>
On that note: Python divisions are somewhat crippled even on x64. Assuming
30-bit digits, the basic building block that's needed for multi-precision
division is a 64-bit-by-32-bit unsig
On Sat, Jan 1, 2022 at 9:05 PM Antoine Pitrou wrote:
> Note that ARM is merely an architecture with very diverse
> implementations having quite differing performance characteristics. [...]
>
Understood. I'd be happy to see timings on a Raspberry Pi 3, say. I'm not
too worried about things like
On Fri, Dec 31, 2021 at 12:40 PM Skip Montanaro
wrote:
> Perhaps I missed it, but maybe an action item would be to add a
> buildbot which configures for 15-bit PyLong digits.
>
Yep, good point. I was wrong to say that "15-bit builds don't appear to be
exercised by the buildbots": there's a 32-b
Thanks all! So to summarize:
- 15-bit digits are still very much in use, and deprecating the option
would likely be premature at this point
- the main users are old 32-bit (x86), which it's difficult to care about
too much, and new 32-bit (principally ARM microarchitectures), which we
*do* care ab
tl;dr: I'd like to deprecate and eventually remove the option to use 15-bit
digits in the PyLong implementation. Before doing so, I'd like to find out
whether there's anyone still using 15-bit PyLong digits, and if so, why they're
doing so.
History: the use of 30-bit digits in PyLong was introd
Meta: apologies for failing to trim the context in the previous post.
--
Mark
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
I'd propose that we relegate `__trunc__` to the same status as `__floor__`
and `__ceil__`: that is, have `__trunc__` limited to being support for
`math.trunc`, and nothing more. Right now the `int` constructor potentially
looks at all three of `__int__`, `__index__` and `__trunc__`, so the
proposal
On Fri, Jun 22, 2018 at 7:28 PM, Chris Barker via Python-Dev <
python-dev@python.org> wrote:
>
> But once it becomes a more common idiom, students will see it in the wild
> pretty early in their path to learning python. So we'll need to start
> introducing it earlier than later.
>
> I think this r
On Wed, Mar 21, 2018 at 8:49 PM, David Mertz wrote:
> For example, this can be true (even without reaching inf):
>
> >>> x.is_integer()
> True
> >>> (math.sqrt(x**2)).is_integer()
> False
>
If you have a moment to share it, I'd be interested to know what value of
`x` you used to achieve this, an
I'd prefer to see `float.is_integer` stay. There _are_ occasions when one
wants to check that a floating-point number is integral, and on those
occasions, using `x.is_integer()` is the one obvious way to do it. I don't
think the fact that it can be misused should be grounds for deprecation.
As far
On Mon, Mar 12, 2018 at 9:18 PM, Tim Peters wrote:
> [Guido]
> > as_integer_ratio() seems mostly cute (it has Tim Peters all
> > over it),
>
> Nope! I had nothing to do with it. I would have been -0.5 on adding
> it had I been aware at the time.
>
Looks like it snuck into the float type a
On Mon, Mar 12, 2018 at 4:49 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> What is the proposal?
> * Add an is_integer() method to int(), Decimal(), Fraction(), and Real().
> Modify Rational() to provide a default implementation.
>
>From the issue discussion, it sounds to me as th
On Mon, Jul 3, 2017 at 5:52 AM, Siyuan Ren wrote:
> The current PyLong implementation represents arbitrary precision integers in
> units of 15 or 30 bits. I presume the purpose is to avoid overflow in
> addition , subtraction and multiplication. But compilers these days offer
> intrinsics that all
On Sun, Sep 11, 2016 at 7:43 PM, Elliot Gorokhovsky
wrote:
> So I suppose the thing to do is to benchmark stable radix sort against
> timsort and see if it's still worth it.
Agreed; it would definitely be interesting to see benchmarks for the
two-array stable sort as well as the American Flag un
> I am interested in making a non-trivial improvement to list.sort() [...]
Would your proposed new sorting algorithm be stable? The language
currently guarantees stability for `list.sort` and `sorted`.
--
Mark
___
Python-Dev mailing list
Python-Dev@pyt
[Moderately off-topic]
On Sun, Aug 17, 2014 at 3:39 AM, Steven D'Aprano
wrote:
> I used to refer to Python 4000 as the hypothetical compatibility break
> version. Now I refer to Python 5000.
>
I personally think it should be Python 500, or Py5M. When we come to
create the mercurial branch,
On Thu, Apr 17, 2014 at 5:33 PM, Mark Dickinson wrote:
> This looks like a doc build issue: when I build the documentation locally
> for the default branch, I still see the expected "Return value: New
> reference." lines.
>
Opened http://bugs.python.org/issue21286 for
On Thu, Apr 17, 2014 at 4:34 PM, Jianfeng Mao wrote:
> I noticed the following changes in the C API manuals from 3.3.5 (and
> earlier versions) to 3.4. I don’t know if these changes are deliberate and
> imply that we C extension developers no longer need to care about
> ‘reference ownership’ beca
On Wed, Apr 16, 2014 at 11:26 PM, Antoine Pitrou wrote:
> What does this mean exactly? Under OS X and Linux, Python is typically
> installed by default.
Under OS X, at least, I think there are valid reasons to not want to use
the system-supplied Python. On my up-to-date OS X 10.9.2 machine, I s
On Sun, Feb 16, 2014 at 12:22 AM, Nick Coghlan wrote:
> The practical benefits of this kind of change in the test suite are
> also highly dubious, because they *only help if the test fails at some
> point in the future*. At that point, whoever caused the test to fail
> will switch into debugging
cs import median; m = median(my_data)" should still
work in the simple case.
Mark
>
> Steven D'Aprano wrote:
>
>> On 15/08/13 21:42, Mark Dickinson wrote:
>>
>>> The PEP and code look generally good to me.
>>>
>>> I think the API
On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano wrote:
>
> - Each scheme ended up needing to be a separate function, for ease of both
> implementation and testing. So I had four private median functions, which I
> put inside a class to act as namespace and avoid polluting the main
> namespace. Th
On Thu, Aug 15, 2013 at 2:25 AM, Steven D'Aprano wrote:
> Can I request that people please look at this issue, with an aim to ruling
> on the PEP and (hopefully) adding the module to 3.4 before feature freeze?
> If it is accepted, I am willing to be primary maintainer for this module in
> the futu
The PEP and code look generally good to me.
I think the API for median and its variants deserves some wider discussion:
the reference implementation has a callable 'median', and variant callables
'median.low', 'median.high', 'median.grouped'. The pattern of attaching
the variant callables as attr
On Fri, Apr 5, 2013 at 6:34 PM, Terry Jan Reedy wrote:
> 2. int(rational): for floats, Fractions, and Decimals, this returns the
> integral part, truncating toward 0. Decimal and float have __int__ methods.
> Fractions, to my surprise, does not, so int must use __floor__ or __round__
> as a backu
On Wed, Apr 3, 2013 at 12:17 PM, Nick Coghlan wrote:
> Perhaps we should start emitting a DeprecationWarning for int subclasses
> returned from __int__ and __index__ in 3.4?
>
+1. Sounds good to me.
> (I like the idea of an explicit error over implicit conversion to the base
> type, so deprecat
On Tue, Apr 2, 2013 at 10:02 AM, Mark Dickinson wrote:
> On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski wrote:
>
>>
>> My 2 cents here is that which one is called seems to be truly random.
>> Try looking into what builtin functions call (for example list.pop
&g
On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski wrote:
>
> My 2 cents here is that which one is called seems to be truly random.
> Try looking into what builtin functions call (for example list.pop
> calls __int__, who knew)
>
That sounds like a clear bug to me. It should definitely be using
On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon wrote:
>
> Hence my original question: what *should* the semantics be?
>
>
I like Nick's answer to that: int *should* always return something of exact
type int. Otherwise you're always left wondering whether you have to do
"int(int(x))", or perhaps ev
On Tue, Apr 2, 2013 at 8:07 AM, Mark Dickinson wrote:
> On Tue, Apr 2, 2013 at 1:44 AM, Nick Coghlan wrote:
>
>> There's code in the slot wrappers so that if you return a non-int object
>> from either __int__ or __index__, then the interpreter will complain about
>
On Tue, Apr 2, 2013 at 1:44 AM, Nick Coghlan wrote:
> int() and operator.index() are both type coercion calls to produce true
> Python integers - they will never return a subclass, and this is both
> deliberate and consistent with all the other builtin types that accept an
> instance of themselve
On Sun, Mar 31, 2013 at 2:29 PM, Mark Shannon wrote:
> class Int1(int):
> def __init__(self, val=0):
> print("new %s" % self.__class__)
>
> class Int2(Int1):
> def __int__(self):
> return self
>
> and two instances
> i1 = Int1()
> i2 = Int2()
>
> we get the following behav
On Fri, Dec 14, 2012 at 7:27 AM, Gregory P. Smith wrote:
> So changing the definition of the dummy side of the union makes zero
> difference to already compiled code as it (a) doesn't change the structure's
> size and (b) all existing implementations already align these on an 8 byte
> boundary.
I
On Mon, Nov 5, 2012 at 12:22 PM, Nick Coghlan wrote:
> If you can find an existing test for it, then definitely (although the
> fact it didn't previously work on Jython suggests there may not be
> one).
I don't see any *direct* tests for this feature, though there are a
couple of tests that just
In Python 2, the 'exec' statement supports 'exec'-ing a (statement,
globals, locals) tuple:
>>> exec("print 2", {}, {})
2
This isn't currently documented at:
http://docs.python.org/reference/simple_stmts.html#the-exec-statement.
It's easy to fix the docs, but in doing so we'd effectively be
bles
On Sun, Oct 21, 2012 at 1:23 PM, Stephen J. Turnbull wrote:
> I probably not say that, but even so my personal taste would be to fix
> the docs to describe the current behavior in 2.7. Evidently somebody
> thought "float" was appropriate
The implementation of complex_new is complicated enough th
On Sun, Oct 21, 2012 at 6:26 AM, Greg Ewing wrote:
> I think I've changed my mind on this, since it was pointed
> out that if you're going to return a float instead of a
> complex, you should really be implementing __float__, not
> __complex__.
Yes, I'm wavering on this, too. I'm reasonably conv
On Fri, Oct 19, 2012 at 3:13 PM, Nick Coghlan wrote:
> Given the way complex numbers interact with floats generally,
> returning a complex number with no imaginary component as a floating
> point value seems legitimate and the checks in cmath overly strict.
> Otherwise you would get redundancy lik
On Fri, Oct 19, 2012 at 5:31 PM, Christian Heimes wrote:
> In order to fix the bug the code in PyComplex_AsCComplex() must be
> altered to support float as return type from __complex__(). That's a
> major change.
Agreed that this doesn't seem appropriate for bugfix releases.
We might also want t
On Fri, Oct 19, 2012 at 4:26 PM, Benjamin Peterson wrote:
> 2012/10/19 Antonio Cuni :
>> indeed, you are right. So I suppose that in pypy we could just relax the
>> check
>> in cmath and be happy. Is there any chance that this will be changed in 2.7
>> and/or 3.x?
>
> Certainly 3.x, but not 2.7.
On Thu, Sep 20, 2012 at 4:14 PM, Benjamin Peterson wrote:
> 2012/9/20 Mark Dickinson :
>> And excepting optional ones, too, right? E.g., the c in
>>
>> def foo(a, b, c=1, *args, d):
>> pass
>>
>> can be passed to by position, but isn't
On Thu, Sep 20, 2012 at 3:12 PM, Benjamin Peterson wrote:
> As you noted in your next message, keyword-only arguments need to be
> distinguished from these "positional" arguments somehow. Maybe it
> helps to think of "positional" to mean "the only formals you can pass
> to with position" (excepti
On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlan wrote:
> +1 for using the unqualified "argument" in these error messages to
> mean "positional or keyword argument" (inspect.Parameter spells it out
> as POSITIONAL_OR_KEYWORD, but the full phrase is far too verbose for
> an error message).
Ah yes; I
I suspect I've missed the boat on this one (certainly for 3.3.0), but
here goes. The new TypeError reporting for bad function calls is a
huge improvement (thanks Benjamin!), but I have one small nitpick:
what *is* a positional argument? For example:
>>> def f(x): pass
...
>>> f()
On Mon, Sep 10, 2012 at 9:06 PM, Matti Picus wrote:
> Can the authors of the original file help me reconstruct the scripts or
> programs used to generate it, and reformulate them for 32 bit floats?
I used a ctypes wrapper around the MPFR library for most of the
testcases, though some were generat
On Sun, Jul 15, 2012 at 1:36 PM, Antoine Pitrou wrote:
> On Sun, 15 Jul 2012 18:47:38 +1000
> Nick Coghlan wrote:
>> I'm not seeing the value in returning None over 0 for the don't know
>> case - it just makes the API harder to use.
>
> The point is that 0 is a legitimate value for a length hint.
On Mon, May 7, 2012 at 12:35 PM, Mark Dickinson wrote:
> will almost always be one less than a power of 2 and powers of 2 are
> always congruent to 1, 2 or 4 modulo 5, we're safe.
Bah. That should have read "1, 2, 3 or 4 modulo 5".
_
On Mon, May 7, 2012 at 12:08 PM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/ab500b297900
> changeset: 76821:ab500b297900
> user: Victor Stinner
> date: Mon May 07 13:02:44 2012 +0200
> summary:
> Issue #14716: Change integer overflow check in unicode_writer_prepare(
On Fri, Jan 13, 2012 at 5:43 PM, Guido van Rossum wrote:
>> How pathological do you consider the set
>>
>> {1 << n for n in range(2000)}
>>
>> to be? What about the set:
>>
>> ieee754_powers_of_two = {2.0**n for n in range(-1074, 1024)}
>>
>> ? The > 2000 elements of the latter set have only
On Fri, Jan 13, 2012 at 2:57 AM, Guido van Rossum wrote:
> How
> pathological the data needs to be before the collision counter triggers? I'd
> expect *very* pathological.
How pathological do you consider the set
{1 << n for n in range(2000)}
to be? What about the set:
ieee754_powers_of
On Thu, Sep 29, 2011 at 2:45 AM, Victor Stinner
wrote:
> I would like to suggest the opposite: move platform independdant macros from
> pyport.h to pymacro.h :-) Suggestions:
> - Py_ARITHMETIC_RIGHT_SHIFT
> - Py_FORCE_EXPANSION
> - Py_SAFE_DOWNCAST
Not sure about the other two, but Py_ARITHMET
e outlined the
topics that we discussed below.
Present:
Antonio Cuni
Mark Dickinson
Larry Hastings (chair)
Marc-André Lemburg
Ezio Melotti
Antoine Pitrou
Armin Ronacher
Armin Rigo
Mark Ramm
Topics covered
==
Python 3 adoption
-
On Mon, Jun 20, 2011 at 1:31 PM, Antoine Pitrou wrote:
> Maciej Fijalkowski a écrit :
>>
>> Unfortunately I'm missing Europython (and language summit) this year.
>> Did anyone do a writeup on what was discussed?
>
> Mark Dickinson has been taking notes,
Hi Michael,
Sorry for the late reply; it's been kinda busy around here.
If there are places left, I'll definitely be there at the summit.
Congratulations on your impending doom! (And sorry to hear that you
might not be there in Florence.)
Mark
On Sat, Apr 16, 2011 at 3:50 PM, Michael Foord
On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing wrote:
> Taking a step back from all this, why does Python allow
> NaNs to arise from computations *at all*?
History, I think. There's a c.l.p. message from Tim Peters somewhere
saying something along the lines that he'd love to make (e.g.,) 1e300
* 1e
On Wed, Apr 27, 2011 at 7:41 PM, Glenn Linderman wrote:
> One issue that I don't fully understand: I know there is only one instance
> of None in Python, but I'm not sure where to discover whether there is only
> a single, or whether there can be multiple, instances of NaN or Inf. The
> IEEE 754
On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic wrote:
> The other day I was surprised to learn this:
>
nan = float('nan')
nan == nan
> False
[nan] == [nan]
> True # also True in tuples, dicts, etc.
That one surprises me a bit too: I knew we were using
identity-th
On Tue, Apr 12, 2011 at 6:01 PM, Djoume Salvetti wrote:
> Thank you and sorry about the pastebin.
> I can reproduce it on python 2.5.2 and python 2.6.6 but not on python 3.1.2
> (all in ubuntu). I'll open a bug.
Is http://bugs.python.org/issue5215 the same issue?
Mark
__
FWIW, I'm -1 on backing out Antoine's patch. In addition to fixing
the minor optimization regression, it makes the peepholer
significantly more consistent in what it can and can't fold. One of
the first times that I delved into the peepholer code was to try to
understand why expressions like: 2
On Thu, Mar 10, 2011 at 2:17 AM, Eugene Toder wrote:
>> Indeed, see http://bugs.python.org/issue11244
>
> Yes, I've noticed that too. However, if I'm not missing something, your
> patches
> do not address folding of -0.
Hmm, it seems that way. Could you post a comment on the tracker issue
about
On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou wrote:
> On Wed, 5 Jan 2011 12:55:55 +
> Mark Dickinson wrote:
>> The need for obj is a little ugly: as far as I can tell, it's
>> meaningless for a 3rd-party object that wants to export buffers---it's
>>
On Wed, Jan 5, 2011 at 2:03 PM, Mark Dickinson wrote:
> Maybe I'm misunderstanding. What's the responsibility of a buffer
> export w.r.t. the obj field---i.e., what should 3rd party code be
Grr. *buffer exporter*, not *buffe
On Wed, Jan 5, 2011 at 12:31 PM, Nick Coghlan wrote:
> Currently [1], the implementation and the documentation for PEP 3118's
> Py_buffer struct don't line up (there's an extra field in the
> implementation that the PEP doesn't mention).
I think there are actually two such fields: smalltable and
.. and here's my original reply to Nick, which was also intended to go
to the list. Sorry, folks.
Mark
-- Forwarded message --
From: Mark Dickinson
Date: Mon, Dec 27, 2010 at 10:27 AM
Subject: Re: [Python-Dev] Range __contains__ and objects with __index__ methods
To:
Bah. I meant to send this to the list. (I suspect that Nick also
meant to send his reply to the list.)
On Mon, Dec 27, 2010 at 12:43 PM, Mark Dickinson wrote:
> On Mon, Dec 27, 2010 at 12:23 PM, Nick Coghlan wrote:
>> The symmetry only breaks for a class that breaks the invariant:
On Mon, Dec 27, 2010 at 9:43 AM, Raymond Hettinger
wrote:
> FWIW, I'm entirely opposed to doing an assignment in a nonlocal definition.
> [...]
-1 for assignment in nonlocal and global statements from me, too.
Mark
___
Python-Dev mailing list
Python-De
On Fri, Dec 24, 2010 at 1:08 AM, Nick Coghlan wrote:
>> def __index__(self):
>> - """index(self)"""
>> + """someobject[self]"""
>> return int(self)
>
> Changing the docstring to say "operator.index(self)" would be the
> clearest solution here.
Agreed. Certainly "someobj
On Mon, Dec 13, 2010 at 3:51 PM, R. David Murray wrote:
> It seems like the status quo is fine. I wouldn't object to it being
> made more consistent. I would object to removing the existing cases.
Same here, on all three counts. In one of the projects I'm currently
working on, we've settled on
On Sat, Dec 4, 2010 at 1:40 PM, Benjamin Peterson wrote:
> You have to touch Include/Python-ast.h and Python/Python-ast.c. We do
> this for release tarballs.
Ah, that makes sense. Thanks.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote:
> On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:
>> Er, normally you don't need *any* Python installed to build Python (be
>> it 3.x or 2.x).
>
> Are you sure about this? I remember needing an existing Pytho
On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:
> Er, normally you don't need *any* Python installed to build Python (be
> it 3.x or 2.x).
Are you sure about this? I remember needing an existing Python to
building Python 2.7 on a new python-less install of FreeBSD a couple
of months ago.
On Thu, Dec 2, 2010 at 8:23 PM, "Martin v. Löwis" wrote:
> In the case of number parsing, I think Python would be better if
> float() rejected non-ASCII strings, and any support for such parsing
> should be redone correctly in a different place (preferably along with
> printing of numbers).
+1.
On Fri, Nov 12, 2010 at 9:29 AM, "Martin v. Löwis" wrote:
> As you may have noticed: I updated the buildbot master to release 0.8.2.
> If you notice any problems, please post them here.
One effect of this change seems to be that bbreport[1] no longer
works, since it appears that buildbot 0.8.2 ha
On Tue, Sep 7, 2010 at 11:00 PM, Mark Dickinson wrote:
> On Tue, Sep 7, 2010 at 10:51 PM, Mark Dickinson wrote:
>> On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin wrote:
>>> It's ignoring the order of the arguments. It also creates
>>> a new Decimal object for
On Tue, Sep 7, 2010 at 10:51 PM, Mark Dickinson wrote:
> On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin wrote:
>> It's ignoring the order of the arguments. It also creates
>> a new Decimal object for the return value, so I can't use id() to
>> check which one o
On Tue, Sep 7, 2010 at 10:40 PM, Jeffrey Yasskin wrote:
> Decimal may actually have this backwards. The idea would be that
> min(*lst) == sorted(lst)[0], and max(*lst) == sorted(lst)[-1]. Given a
> stable sort, then, max of equivalent elements would return the last
> element, and min the first.
Y
On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin wrote:
> Actually, Decimal isn't doing anything along these lines. At least in
> Python 2.6, I get:
>
Decimal('2').max(Decimal('2.0'))
> Decimal('2')
Decimal('2.0').max(Decimal('2'))
> Decimal('2')
Decimal('2.0').min(Decimal('2'))
> D
On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
wrote:
> In CPython, the builtin max() and min() have the property that if there
> are items with equal keys, the first item is returned. From a quick look
> at their source, I think this is true for Jython and IronPython too.
It's actually not cl
On Thu, Aug 19, 2010 at 7:11 AM, Timothy Kinney
wrote:
> I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box.
>
> If I run the following:
>
> [code]
> from pylab import randint
>
> for s in range(100):
> print randint(0,1)
> [/code]
>
> I get 100 zeroes.
>
> If I import ran
On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou wrote:
>
> Hello,
>
> I would like to see “unit test needed” removed from the workflow menu in
> the bug tracker. The reason is that we don't do test-driven development
> (or, at least, most of us don't) and this stage entry is therefore
> useless a
On Wed, Aug 11, 2010 at 4:09 PM, Ezio Melotti wrote:
> On 11/08/2010 17.59, Mark Dickinson wrote:
>> One niggle: we seem to have lost the simple 'Open Issues' search
>> under 'Summaries' on the left-hand side of the page.
>
> I was expecting some
On Wed, Aug 11, 2010 at 3:21 PM, Tim Golden wrote:
> Thanks to whoever's been working on the new Summary lists on the Issue
> Tracker.
Ezio Melotti, I assume.
> The "Followed by you" / "Created by you" / "Assigned to you" are just what
> the doctor ordered.
Agreed. Now I can get rid of my own
2010/8/7 Mark Dickinson :
> 2010/8/7 Kristján Valur Jónsson :
>> Hi there.
>> [...]
>> But it appears that the builtin round() method also changed. Whereas I see
>> the changing of floating point representation in string formatting as not
>> being very serious
2010/8/7 Kristján Valur Jónsson :
> Hi there.
> [...]
> But it appears that the builtin round() method also changed. Whereas I see
> the changing of floating point representation in string formatting as not
> being very serious, why did the arithmetic function round() have to change?
This was par
On Thu, Jul 29, 2010 at 8:16 PM, Raymond Hettinger
wrote:
>
> On Jul 29, 2010, at 11:47 AM, Mark Dickinson wrote:
>
>> Now that we've got the short float repr in Python, there's less value
>> in having float.__str__ truncate to 12 significant digits (as it
>>
Now that we've got the short float repr in Python, there's less value
in having float.__str__ truncate to 12 significant digits (as it
currently does). For Python 3.2, I propose making float.__str__ use
the same algorithm as float.__repr__ for its output (and similarly for
complex).
Apart from si
On Mon, Jul 12, 2010 at 10:19 PM, Nick Coghlan wrote:
> On Tue, Jul 13, 2010 at 3:35 AM, Petre Galan wrote:
>> ival should not be resolved through PyLong_AsLong, but through
>> functionality/interface like PyNumber_Long
+1, but I'd prefer it if PyNumber_Index were used, rather than PyNumber_Long
On Sat, Jul 10, 2010 at 1:22 AM, Nick Coghlan wrote:
> +1 for fixing it from me, unless any of the other implementations object.
>
> @Mark: my comment on the tracker issue had an implied "...unless you
> really want to" on the end :)
Thanks! Patch at http://bugs.python.org/issue9232
Mark
___
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland wrote:
> Terry wrote:
>> This violates the important principle that allowed def and call arg
>> sequences should match to the extent sensible and possible. In this
>> sense, the SyntaxError is a bug. So I would fix this now for 3.2 and
>> notify the ot
While looking at a parser module issue
(http://bugs.python.org/issue9154) I noticed that Python's grammar
doesn't permit trailing commas after keyword-only args. That is,
def f(a, b,): pass
is valid syntax, while
def f(*, a, b,): pass
is not. I was just curious whether the latter was
On Tue, Jul 6, 2010 at 1:10 PM, Walter Dörwald wrote:
> http://coverage.livinglogic.de/ *does* include coverage info for stuff
> written in C, see for example:
>
> http://coverage.livinglogic.de/Objects/unicodeobject.c.html
>
> However it *is* strange that test_audioop.py gets executed, but
> au
On Sun, Jul 4, 2010 at 9:45 PM, Jesse Noller wrote:
> On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé wrote:
>> On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore wrote:
>>> On 4 July 2010 17:02, Benjamin Peterson wrote:
Now that Python 2.7 is out, I'd like to thank a few of the people who
made i
On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson wrote:
> This is just a note that we have one bug blocking 2.7 final at the
> moment: http://bugs.python.org/issue9144
I've just made http://bugs.python.org/issue7673 a release blocker too,
I'm afraid. It's a potential security vulnerability in t
On Fri, Jul 2, 2010 at 3:44 PM, Craig Citro wrote:
>> Whoa. That's very peculiar looking bytecode. Is dis.dis behaving as
>> it should here?
>> BTW, I think you want 'raise TypeError', not 'raise TypeError()'.
>>
>
> Yep, that's embarrassing. I was being lazy: I was expecting different
> bytecod
1 - 100 of 388 matches
Mail list logo
