On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson wrote:
[...]
>>>> Decimal.from_float(1.1) == 1.1
> False
Whoops. To clarify, this is the pre-patch behaviour; post-patch,
this gives True.
Mark
___
Python-Dev mailing list
Python-Dev@
On Tue, Mar 16, 2010 at 4:18 PM, Victor Stinner
wrote:
> If comparaison of Decimal and float can have "unpredictable" result, I would
> suggest the same behaviour (raise an error).
Well, it's not really `unpredictable': the new behaviour is perfectly
predictable and sane, provided only that you
On Tue, Mar 16, 2010 at 4:41 PM, Guido van Rossum wrote:
> I'd say if you're not going to forward-port this to Python 3, it
> shouldn't go into Python 2 -- in that case it would make more sense to
> me to back-port the exception-raising behavior.
That's also a possible solution, and the one that
On Tue, Mar 16, 2010 at 10:16 PM, Greg Ewing
wrote:
> Mark Dickinson wrote:
>>
>> On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby wrote:
>>
>>> If not, it might be confusing if a number that prints as '.1' compares
>>> unequal to Decimal('.1&#x
On Tue, Mar 16, 2010 at 10:32 PM, Steven D'Aprano wrote:
> On Wed, 17 Mar 2010 03:23:30 am Mark Dickinson wrote:
>> On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson
>> wrote: [...]
>>
>> >>>> Decimal.from_float(1.1) == 1.1
>> >
>> > Fa
On Wed, Mar 17, 2010 at 12:36 AM, Raymond Hettinger
wrote:
>
> On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
>>
>> Also supporting comparisons but not other mixed operations is going to
>> be confusing. If you are sticking to that behavior I think mixed
>> comparisons should also be ruled o
On Wed, Mar 17, 2010 at 11:43 AM, Steven D'Aprano wrote:
> Having said all that, I've just re-read the PEP, and spotted a fly in
> the ointment... hash.
>
> If we allow Decimals to compare equal to floats, that presumably implies
> that they need to hash equal. That may be simple enough for intege
On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum wrote:
> Definitely some. Stricter comparison rules are a frequent cause of
> problems when code is first ported to 3.x. While you'd think that code
> comparing a float and a Decimal is *already* broken, there's a
> surprising number of situations
On Thu, Mar 18, 2010 at 5:55 PM, Raymond Hettinger
wrote:
> My thought is that intentional mixed compares of float and decimal
> are very rare relative to unintentional cases. IOW, most of the
> time that x (or the user simply doesn't understand what his or her code is
> actually doing). That us
On Thu, Mar 18, 2010 at 9:48 PM, Nick Coghlan wrote:
> Note that even in Py3k there are some fairly serious weirdnesses kicking
> around due to the intransitive nature of numeric equality though:
Yep. My personal favourite is:
>>> from decimal import Decimal as dec
>>> set((1, 1.0, dec(1))) ==
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
> Making hashes of int,
> float, Decimal *and* Fraction all compatible with one another,
> efficient for ints and floats, and not grossly inefficient for
> Fractions and Decimals, is kinda hairy, though I have a couple of
>
On Fri, Mar 19, 2010 at 12:46 PM, Alex A. Naanou wrote:
> A friend of mine stumbled upon the following behavior:
>
>
> ---cut---
>
class A(object): pass
> ...
class B(object):
> ... def __add__(self, other):
> ... print 'B: adding B and %s objects.' % other.__class__.__name__
On Fri, Mar 19, 2010 at 6:43 PM, Terry Reedy wrote:
> On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
>>
>> Raymond Hettinger gmail.com> writes:
>>>
>>> The reason to prefer an exception is that decimal/float comparisons
>>> are more likely to be a programmer error than an intended behavior.
>
> If
On Fri, Mar 19, 2010 at 7:50 PM, Mark Dickinson wrote:
> So the patch
> I've put on the issue tracker is wrong, since it does raise TypeError ...
s/I've put/I have yet to put/
I really shouldn't admit to errors in things that I haven't even been
Just a couple of quick side comments on this; I haven't got my head
around the whole mixed-operations idea yet.
On Fri, Mar 19, 2010 at 9:50 PM, Guido van Rossum wrote:
> There is one choice which I'm not sure about. Should a mixed
> float/Decimal operation return a float or a Decimal?
I'll jus
On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen wrote:
> On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson wrote:
>> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
>>> Making hashes of int,
>>> float, Decimal *and* Fraction all compatible with one another,
On Sat, Mar 20, 2010 at 12:10 AM, Greg Ewing
wrote:
> Nick Coghlan wrote:
>>
>> Mark Dickinson wrote:
>
>> It seems to me that given the existing conflation of numeric equivalence
>> and containment testing, going the whole hog and fixing the set
>> member
On Sat, Mar 20, 2010 at 11:41 AM, Paul Moore wrote:
> On 20 March 2010 04:20, Nick Coghlan wrote:
>> In the case of floats and Decimals, there's no ambiguity here that
>> creates any temptation to guess - to determine a true/false result for a
>> comparison, floats can be converted explicitly to
On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen wrote:
> On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson wrote:
>> What external modules are there that rely on existing hash behaviour?
>
> I'm only aware of gmpy and SAGE.
>
>> And exactly what behaviour do
On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum wrote:
> I propose to reduce all hashes to the hash of a normalized fraction,
> which we can define as a combination of the hashes for the numerator
> and the denominator. Then all we have to do is figure fairly efficient
> ways to convert floats a
On Sat, Mar 20, 2010 at 11:20 PM, Greg Ewing
wrote:
> * Decimal and float really belong side-by-side in the
> tower, rather than one above the other. Neither of them is
> inherently any more precise or exact than the other.
Except that float is fixed-width (typically 53 bits of precision),
while
On Sun, Mar 21, 2010 at 10:50 PM, Greg Ewing
wrote:
> Raymond Hettinger wrote:
>
>> Since decimal also allows arbitrary sizes, all long ints can be
>> exactly represented (this was even one of the design goals
>> for the decimal module).
>
> There may be something we need to clarify here. I've bee
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
wrote:
>
> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>
> Decimal + float --> Decimal
>
> If everybody associated with the Decimal implementation wants this I
> won't stop you; as I repeatedly said my intuition about this one (as
> op
On Mon, Mar 22, 2010 at 7:00 PM, Raymond Hettinger
wrote:
>
> On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
>>
>> Just for the record, I'd also prefer Decimal + Fraction -> Decimal.
>
>
> Guido was persuasive on why float + Fraction --> float,
>
On Mon, Mar 22, 2010 at 8:02 PM, Pierre B. wrote:
> Sorry to intervene out of the blue, but I find the suggested rule for
> fractional to decimal conversion not as clean as I'd expect.
>
> If fractions are converted to decimals when doing arithmetics, would it be
> worthwhile to at least provide a
On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
wrote:
> While we're on the topic, I think you should consider allowing the Fraction()
> constructor to accept a decimal input.
>
> This corresponds to common schoolbook problems and simple client requests:
> "Express 3.5 as a fraction".
>
>
On Mon, Mar 22, 2010 at 8:44 PM, Guido van Rossum wrote:
> On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
> wrote:
>> While we're on the topic, I think you should consider allowing the Fraction()
>> constructor to accept a decimal input.
>>
>> This corresponds to common schoolbook problems a
On Tue, Mar 23, 2010 at 12:33 AM, Greg Ewing
wrote:
> Mark Dickinson wrote:
>>
>> It might make sense for
>> Decimal + complex mixed-type operations to be disallowed, for example.
>
> As long as you're allowing Decimal-float comparisons,
> Decimal-complex com
On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah wrote:
> Facundo Batista wrote:
>> On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum wrote:
>>
>> > As a downside, there is the worry that inadvertent mixing of Decimal
>> > and float can compromise the correctness of programs in a way that is
>> > h
On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah wrote:
> Mark Dickinson wrote:
>> [Stefan]
>> >
>> > strictness 2: current py3k behaviour + pure equality comparisons
>>
>> Can you explain what you mean by "+ pure equality comparisons" here?
>>
On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
> a = Decimal('nan')
> a != a
>
> They don't follow the behaviour required for being hashable.
What's this required behaviour? The only rule I'm aware of is that if
a == b then hash(a) == hash(b). That's not violated here.
Note that containmen
On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen wrote:
> On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
>> Note that containment tests check identity before equality, so there's
>> no problem with putting (float) nans in sets or dicts:
>>
>>>>> x
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > As usual though, NANs are unintuitive:
> >
> > >>> d = {float('nan'): 1}
> > >>> d[float('nan')] = 2
> > >>> d
> > {nan: 1, nan: 2}
> >
> >
> > I suspect that's a feature, not a bug.
Right: disti
On Wed, Mar 24, 2010 at 11:47 AM, Nick Coghlan
> Interning NaN certainly seems like it should be sufficient to eliminate
> the set/dict membership weirdness.
>
> That is, make it so that the first two lines of the following return
> True, while the latter two lines continue to return False:
>
On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky
wrote:
> Mark, I wonder if you could describe an algorithm off the top of your
> head that relies on NaN == NaN being false.
>
No, I certainly couldn't! And I often wonder if the original IEEE 754
committee, given 20/20 foresight, would have
[Changing the subject line, since we're way off the original topic]
On Wed, Mar 24, 2010 at 7:04 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson wrote:
> ..
>> If Python were to do something different then a naively translated
>>
Slight change of topic. I've been implementing the extra comparisons
required for the Decimal type and found an anomaly while testing.
Currently in py3k, order comparisons (but not ==, !=) between a
complex number and another complex, float or int raise TypeError:
>>> z = complex(0, 0)
>>> z < in
On Wed, Mar 24, 2010 at 8:56 PM, Raymond Hettinger
wrote:
> FWIW, my viewpoint on this is softening over time
> and I no longer feel a need to push for a new context flag.
>
> It is probably simplest for users if implicit coercions didn't come
> with control knobs. We already have Fraction+float-
On Wed, Mar 24, 2010 at 10:30 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 6:21 PM, Raymond Hettinger
> wrote:
> ..
>> If we want to be able to reason about our programs,
>> then we need to rely on equality relations being
>> reflexsive, symmetric, and transitive. Otherwise,
>> cont
On Wed, Mar 24, 2010 at 10:36 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson wrote:
> ..
>> Neither is necessary, because Python doesn't actually use == as the
>> equivalence relation for containment testing: the actual equival
On Wed, Mar 24, 2010 at 10:52 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 6:47 PM, Mark Dickinson wrote:
> ..
>> There's no ideal solution here; IMO, the compromise that currently
>> exists is an acceptable one.
>
> I don't see a compromise.
On Wed, Mar 24, 2010 at 11:11 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson wrote:
> ..
>>
>> So if I understand correctly, you propose that float('nan') ==
>> float('nan') return True. Would you also suggest
On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Here's an interesting recent blog post on this subject, from the
>> creator of Eiffel:
>>
>> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
>
On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan wrote:
> So, I'm specifically putting that proposal on the table for both float
> and Decimal NaNs in Python:
>
> "Not a Number" is not a single floating point value. Instead each
> instance is a distinct value representing the precise conditions th
On Thu, Mar 25, 2010 at 12:36 PM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/25/2010 07:54 AM, Georg Brandl wrote:
>>> float('nan') in [float('nan')]
False
>>>
>>> Sure, but just think of it as having two different nans there. (You
>>> could imagine thin
On Thu, Mar 25, 2010 at 12:39 PM, Jesus Cea wrote:
>
> But IEEE 754 was created by pretty clever guys and sure they had a
> reason for define things in the way they are. Probably we are missing
> something.
Well, if we are, then nobody seems to know what! See the Bertrand
Meyer blog post that wa
On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan wrote:
> Jesus Cea wrote:
>> But IEEE 754 was created by pretty clever guys and sure they had a
>> reason for define things in the way they are. Probably we are missing
>> something.
>
> Yes, this is where their "implementable in a hardware circuit" fo
On Thu, Mar 25, 2010 at 2:26 PM, Antoine Pitrou wrote:
> Le Thu, 25 Mar 2010 07:19:24 -0700, Curt Hagenlocher a écrit :
>> Wait, what? I haven't been paying much attention, but this is backwards.
>> There are multiple representations of NaN in the IEEE encoding; that's
>> actually part of the prob
On Thu, Mar 25, 2010 at 2:42 PM, Mark Dickinson wrote:
> On Thu, Mar 25, 2010 at 2:26 PM, Antoine Pitrou wrote:
>> This sounds a bit sophistic, if the (Python) user doesn't have access to
>> the payload anyway.
>
> Well, you can get at the payload using the struct mo
On Thu, Mar 25, 2010 at 3:01 PM, Curt Hagenlocher wrote:
> On Thu, Mar 25, 2010 at 7:54 AM, Mark Dickinson wrote:
>>
>> Hmm. I take it back. I was being confused by the fact that sqrt(nan)
>> returns a nan with a new identity; but it does apparently preserve
>> the
On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan wrote:
>>> Jesus Cea wrote:
>>>> But IEEE 754 was created by pretty clever guys and sure they had a
>>>> reason for define t
On Thu, Mar 25, 2010 at 1:15 AM, Jeffrey Yasskin wrote:
> On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson wrote:
>> Slight change of topic. I've been implementing the extra comparisons
>> required for the Decimal type and found an anomaly while testing.
>> Currently
On Fri, Mar 26, 2010 at 11:16 PM, Raymond Hettinger
wrote:
> Of the ideas I've seen in this thread, only two look reasonable:
> * Do nothing. This is attractive because it doesn't break anything.
> * Have float.__eq__(x, y) return True whenever x and y are
> the same NaN object. This is attra
On Sat, Mar 27, 2010 at 12:59 AM, Michael Foord
wrote:
> Hello all,
>
> A user has suggested an optional argument to
> unittest.TestCase.assertAlmostEqual for specifying a maximum difference
> between the expected and actual values, instead of using rounding.
+1.
Mark
___
On Mon, Mar 22, 2010 at 7:52 PM, Guido van Rossum wrote:
> On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
> wrote:
>> One other thought.
>>
>> The Decimal constructor should now accept floats as a possible input type.
>> Formerly, we separated that out to Decimal.from_float() because
>> deci
On Fri, Apr 2, 2010 at 3:54 PM, Stefan Krah wrote:
>
> I looks like the 'stop build' button can a) cause subsequent builds to fail
> and b) cause pending builds to be deleted from the queue.
>
>
> a) http://www.python.org/dev/buildbot/builders/ARM Linux EABI 3.x/builds/18
> was apparently interr
On Wed, Apr 7, 2010 at 1:39 PM, Jeroen Ruigrok van der Werven
wrote:
> Before I file a bug report, is anyone else seeing this (in my case on
> FreeBSD 8):
>
> Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first
> unrecognized character is `@'
> Modules/_ctypes/libffi/src/
On Fri, Apr 16, 2010 at 9:04 AM, Hagen Fürstenau wrote:
>> This behavior seems pretty strange to me, indeed PyPy gives the
>> TypeError for both attempts. I just wanted to confirm that it was in
>> fact intentional.
>
> Oleg already answered why f(**{1:3}) raises a TypeError. But your
> question
On Fri, Apr 16, 2010 at 3:33 PM, Guido van Rossum wrote:
> On Fri, Apr 16, 2010 at 7:15 AM, Nick Coghlan wrote:
>> I would agree with leaving it implementation defined - I don't think
>> either PyPy or CPython should be forced to change their current
>> behaviour in relation to this. A minor note
On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>>
>> Can this sneak in under the 'incorrect language semantics' exemption
>&g
On Sat, Apr 17, 2010 at 7:41 PM, Victor Stinner
wrote:
> Ezio and Florent are developing a tool called bbreport to collect buildbot
> results and generate short reports to the command line. It's possible to
> filter results by Python branch, builder name, etc. I send patches to link
> failed tests
On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote:
> While talking about Python 2.6 -> 2.7 transitions, the subject of relative and
> absolute imports has come up. PEP 328 states that absolute imports will be
> enabled by default in Python 2.7, however I cannot verify that this has
> actually h
On Wed, Apr 21, 2010 at 2:56 PM, Mark Dickinson wrote:
> On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote:
>> While talking about Python 2.6 -> 2.7 transitions, the subject of relative
>> and
>> absolute imports has come up. PEP 328 states that absolute imports will
On Thu, May 6, 2010 at 4:52 AM, Joao S. O. Bueno wrote:
> On Wed, May 5, 2010 at 9:59 PM, Eric Smith wrote:
>> That's my point. Since it's basically unreviewable, is it smart to do it
>> during a beta?
>
> Hello folks -
> I don't think these modifications are that "unreviewable": the
> generated
On Tue, May 18, 2010 at 11:00 PM, Gustavo Narea wrote:
> I've checked the new collections.Counter class and I think I've found a bug:
>
>> >>> from collections import Counter
>> >>> c1 = Counter([1, 2, 1, 3, 2])
>> >>> c2 = Counter([1, 1, 2, 2, 3])
>> >>> c3 = Counter([1, 1, 2, 3])
>> >>> c1 == c2
On Thu, May 20, 2010 at 10:18 PM, Mark Dickinson wrote:
> See also this recent thread on python-list, and in particular the messages
> from Raymond Hettinger in that thread:
>
> http://mail.python.org/pipermail/python-list/2010-March/thread.html
Sorry, bad thread link.
On Wed, May 26, 2010 at 10:15 AM, Colin H wrote:
> issue991196 was closed being described as intentional. I've added
> a comment in that issue which argues that this is a serious bug (also
> aserted by a previous commenter - Armin Rigo), because it creates a
> unique, undocumented, oddly behavi
On Fri, Jun 25, 2010 at 7:35 PM, Michael Foord
wrote:
> Hello all,
>
> I've put a recipe up on the Python cookbook for creating APIs that work as
> both decorators and context managers and wonder if it would be considered a
> useful addition to the functools module.
> http://code.activestate.com/r
On Sun, Jun 27, 2010 at 10:41 AM, Georg Brandl wrote:
> So -- if every dev "adopted" a Tool or Demo, that would be quite a
> manageable piece of work, and maybe a few demos can be brought up
> to scratch instead of be deleted.
>
> I'll go ahead and promise to care for the "Demo/classes" subdir.
B
On Sun, Jun 27, 2010 at 12:37 AM, M.-A. Lemburg wrote:
> Brett Cannon wrote:
>> On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote:
>>> I finally realized why clang has not been silencing its warnings about
>>> unused return values: I have -Wno-unused-value set in CFLAGS which
>>> comes before OPT
On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin wrote:
> AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based
> systems
> (http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-AC_005fPROG_005fCC-842).
> If Python's configure.in sets an otherwise-empty CFLAGS to -g b
On Sun, Jun 27, 2010 at 9:37 PM, Jeffrey Yasskin wrote:
> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote:
>> I think saving and restoring CFLAGS across AC_PROG_CC was attempted in
>> http://bugs.python.org/issue8211 . It turned out that it broke OS X
>> universal b
On Mon, Jun 28, 2010 at 12:38 PM, M.-A. Lemburg wrote:
>> On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin wrote:
>>> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote:
>>>> I'm not sure I understand the importance of allowing AC_PROG_CC to set
>>>>
On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote:
> Why do you think that the default -O2 is unwanted
Because it can cause debug builds of Python to be built with
optimization enabled, as we've already seen at least twice.
> and how do you know
> whether the compiler accepts -g as option ?
On Mon, Jun 28, 2010 at 4:28 PM, M.-A. Lemburg wrote:
> Mark Dickinson wrote:
>> On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote:
>>> Why do you think that the default -O2 is unwanted
>>
>> Because it can cause debug builds of Python to be built with
>
On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro wrote:
>
> Ok, I'm obviously being silly here, but sure you can:
>
dis.dis("raise TypeError()")
> 0 <114> 26977
> 3 <115> 8293
> 6 IMPORT_STAR
> 7 SETUP_EXCEPT 25968 (to 25978)
> 10
On Fri, Jul 2, 2010 at 8:22 AM, Mark Dickinson wrote:
> On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro wrote:
>>
>>>>> dis.dis("raise TypeError()")
>> 0 <114> 26977
>> 3 <115> 8293
>>
On Fri, Jul 2, 2010 at 12:25 PM, Steven D'Aprano wrote:
> Craig, what are you using to get that? When I try it in Python 3.1, I
> get:
>
> TypeError: don't know how to disassemble str objects
>
> How do you get that result?
As I just discovered (see above), dis.dis is happy to interpret byte
stri
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
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 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 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
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 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
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 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
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 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
>>
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
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
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
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 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 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
a bit embarrassing if they fail for some inputs.
One more thing: since this is my first post to python-dev I should
probably introduce myself. I'm a mathematician, working mostly in
number theory. I learnt programming and numerical analysis the hard
way, coding service-life prediction algorit
On 9/17/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> In the Tracker Issue...
>
> http://bugs.python.org/issue1772851
>
> ... Mark Dickinson came with a patch that alters in a very corner case
> how the hash is calculated to a long integer.
>
Much as I'
On 10/2/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/10/2, Raymond Hettinger <[EMAIL PROTECTED]>:
>
> > Yes! We have guaranteed that spec updates are to be treated as bug
> fixes and backported. This is especially important in this case
> > because other errors have been fixed and the
On 10/15/07, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
> [...] I
> would like to know if there is still interest in C version of Decimal.
> If so - should I write PEP, or just code and 'we'll see later'?
I'd be happy to see decimal.py replaced by a C version giving
essentially the same functiona
On 10/16/07, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
> Well, I am pretty sure, that addition works in linear time in Python
> version :>.
Unfortunately not. Here are some timings from my laptop:
>>> from timeit import Timer
>>> Timer("x+x", "from decimal import Decimal; x =
Decimal('1'*5000)
On 10/16/07, Fredrik Johansson <[EMAIL PROTECTED]> wrote:
> There is another alternative, which is to use integers exclusively for
> both representation and arithmetic, and only compute an explicit digit
> tuple or string in special cases. I'm doing this in in mpmath
> (http://code.google.com/p/mpm
101 - 200 of 388 matches
Mail list logo
