[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 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, 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
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 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
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
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 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 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 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 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 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 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 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 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 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 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 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
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 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
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
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
> 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
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
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
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
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/
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
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
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
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 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 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 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 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 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 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
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 Fri, Feb 6, 2009 at 9:04 PM, Lisandro Dalcin wrote:
> At Objects/longobject.c, you should see that in almost all cases
> OverflowError is raised when a unsigned integral is requested from a
> negative PyLong. However, See this one:
> [...]
> if (!is_signed) {
>
On Fri, Feb 6, 2009 at 11:38 PM, Lisandro Dalcin wrote:
> Done, http://bugs.python.org/issue5175
Thank you!
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
On Tue, Feb 10, 2009 at 1:23 PM, Daniel (ajax) Diniz wrote:
> If anyone is interested in being added as nosy for any category of
> bugs, let me know and I'll do that as I scan the tracker.
Feel free to assign anything math-related (math and cmath modules,
float and complex objects) to me.
Thanks
On Thu, Feb 12, 2009 at 8:42 PM, Lisandro Dalcin wrote:
> I would like to propose the inclusion of a new T_SIZET in structmember.h
> in order to suport 'size_t' struct fields with PyMemberDef. Would such
> addition be accepted for 2.7 and 3.1?
Please open a feature request at bugs.python.org, and
A few months ago there was a discussion [1] about changing
Python's long integer type to use base 2**30 instead of base
2**15. http://bugs.python.org/issue4258 was opened for this.
With much help from many people (but especially Antoine
and Victor), I've finally managed to put together an
essenti
On Tue, Feb 17, 2009 at 7:49 PM, "Martin v. Löwis" wrote:
> Can you please upload it to Rietveld also?
Will do. I'm getting a "500 Server Error" at the moment, but I'll keep trying.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
On Tue, Feb 17, 2009 at 8:42 PM, Guido van Rossum wrote:
> Use the upload.py script (/static/upload.py) rather than the Create Issue
> page.
Thanks. That worked.
http://codereview.appspot.com/14105
___
Python-Dev mailing list
Python-Dev@python.org
ht
On Wed, Feb 25, 2009 at 2:23 PM, Barry Warsaw wrote:
> This is now done. Please let me know if you have any problems with the
> mirrors.
Is the cron job that's supposed to update the bzr repository still running?
I'm getting 'No revisions to pull' when I do 'bzr pull' for the py3k branch:
Macin
On Fri, Feb 27, 2009 at 7:26 PM, Barry Warsaw wrote:
> On Feb 25, 2009, at 2:03 PM, Mark Dickinson wrote:
>> Is the cron job that's supposed to update the bzr repository still
>> running?
> I think I have this fixed now. The branch updater is running on dinsdale
&
2009/3/24 Daniel Stutzbach :
> [...]
> 100 nanoseconds, py3k trunk:
> ceval -> PyObject_GetItem (object.c) -> list_subscript (listobject.c) ->
> PyNumber_AsSsize_t (object.c) -> PyLong_AsSsize_t (longobject.c)
> [more timings snipped]
Does removing the PyLong_Check call in PyLong_AsSsize_t
make an
On Tue, Mar 24, 2009 at 3:50 PM, Daniel Stutzbach
wrote:
> On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson wrote:
>> Does removing the PyLong_Check call in PyLong_AsSsize_t
>> make any noticeable difference to these timings?
>
> Making no other changes from the trunk, remo
[Antoine]
> - Issue #5593: code like 1e16+2. is optimized away and its result stored
> as
> a constant (again), but the result can vary slightly depending on the internal
> FPU precision.
[Guido]
> I would just not bother constant folding involving FP, or only if the
> values involved have an
On Mon, Apr 6, 2009 at 9:05 PM, Raymond Hettinger wrote:
> The code for the lsum() recipe is more readable with a line like:
>
> exp = long(mant * 2.0 ** 53)
>
> than with
>
> exp = long(mant * 9007199254740992.0)
>
> It would be ashamed if code written like the former suddenly
> started doing t
Executive summary (details and discussion points below)
=
Some time ago, Noam Raphael pointed out that for a float x,
repr(x) can often be much shorter than it currently is, without
sacrificing the property that eval(repr(x)) == x, and proposed
changing Python accordingly. See
ht
On Wed, Apr 8, 2009 at 7:13 AM, John Barham wrote:
> If you play around a bit it becomes clear that what set.pop() returns
> is independent of the insertion order:
It might look like that, but I don't think this is
true in general (at least, with the current implementation):
>>> foo = set([1, 65
On Sat, Apr 11, 2009 at 11:14 AM, Chris Withers wrote:
> Also got the following failure from a py3k checkout:
>
> test test_cmd_line failed -- Traceback (most recent call last):
> File "/Users/chris/py3k/Lib/test/test_cmd_line.py", line 143, in
> test_run_code
> 0)
> AssertionError: 1 != 0
Ar
On Fri, Apr 10, 2009 at 2:31 PM, Barry Warsaw wrote:
> bugs.python.org is apparently down right now, but I set issue 5724 to
> release blocker for 2.6.2. This is waiting for input from Mark Dickinson,
> and it relates to test_cmath failing on Solaris 10.
I'd prefer to leave this a
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily wrote:
> Ned Deily wrote:
>> Eric Smith wrote:
>> > Before then, if anyone could build and test the py3k-short-float-repr
>> > branch on any of the following machines, that would be great:
>> >
>> [...]
>> > Something bigendian, like a G4 Mac
>>
>> I'
By the way, a simple native build on OS X 10.4/PPC passed all tests (that
we're already failing before).
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
On Tue, Apr 14, 2009 at 11:37 AM, Mark Dickinson wrote:
> By the way, a simple native build on OS X 10.4/PPC passed all tests (that
> we're already failing before).
s/we're/weren't
___
Python-Dev mailing list
Pytho
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily wrote:
> FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for
> 10.3 and above; this is the similar to recent python.org OSX installers.
What's the proper way to create such a build? I've been trying:
./configure --with-universal-ar
Okay, I think I might have fixed up the float endianness detection for
universal builds on OS X. Ned, any chance you could give this
another try with an updated version of the py3k-short-float-repr branch?
One thing I don't understand:
Is it true that to produce a working universal/fat build of
On Tue, Apr 14, 2009 at 5:14 PM, Antoine Pitrou wrote:
> If this approach is sane, could it be adopted for all other instances of
> endianness detection in the py3k code base?
I think everything else is fine: float endianness detection (for marshal,
pickle, struct) is done at runtime. Integer e
On Tue, Apr 14, 2009 at 5:49 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>> Do you know the right way to create a universal build?
>
> Not at all, sorry.
No problem :). I might try asking on the pythonmac-sig list.
Mark
On Tue, Apr 14, 2009 at 6:55 PM, "Martin v. Löwis" wrote:
> The outcome of AC_C_BIGENDIAN isn't used on OSX. Depending on the exact
> version you look at, things might work differently; in trunk,
> Include/pymacconfig.h should be used [...]
Many thanks---that was the missing piece of the puzzle.
On Tue, Apr 14, 2009 at 6:32 PM, Ned Deily wrote:
> The OSX installer script is in Mac/BuildScript/build-installer.py.
>
> For 2-way builds, it essentially does:
>
> export MACOSX_DEPLOYMENT_TARGET=10.3
> configure -C --enable-framework
> --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk
>
On Fri, Apr 17, 2009 at 3:58 PM, Scott David Daniels
wrote:
> Non-associativity is what makes for floating point headaches.
> To my knowledge, floating point is at least commutative.
Well, mostly. :-)
>>> from decimal import Decimal
>>> x, y = Decimal('NaN123'), Decimal('-NaN456')
>>> x + y
Deci
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy wrote:
> In going through this, I notice a lot of effort by Mark Dickenson and others
Many others, but Eric Smith's name needs to be in big lights here.
There's no way the short float repr would have been ready for 3.1 if
Eric hadn't shown an interest
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
>>> '%f' % 2**166.
'93536104789177
The bugs.python.org site seems to be down. ping gives me
the following (from Ireland):
Macintosh-4:py3k dickinsm$ ping bugs.python.org
PING bugs.python.org (88.198.142.26): 56 data bytes
36 bytes from et.2.16.rs3k6.rz5.hetzner.de (213.239.244.101):
Destination Host Unreachable
Vr HL TOS Len ID
On Sun, Apr 26, 2009 at 4:19 PM, Aahz wrote:
> On Sun, Apr 26, 2009, Mark Dickinson wrote:
>>
>> The bugs.python.org site seems to be down.
>
> Dunno -- forwarded to the people who can do something about it. (There's
> a migration to a new mailserver going on, but I
On Sun, Apr 26, 2009 at 5:59 PM, Eric Smith wrote:
> Mark Dickinson wrote:
>> I propose changing the complex str and repr to behave like the
>> float version. That is, repr(4. + 10.j) should be "(4.0 + 10.0j)"
>> rather than "(4+10j)".
>
> I
On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
wrote:
> As a user of Idle, I would not like to see the change you seek of
> having %f stay full-precision. When a number gets too long to print
> on a single line, the wrap depends on the current window width, and
> is calculated dynamically.
On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels
wrote:
> I had also said (without explaining:
>> > only the trailing zeroes with the e, so we wind up with:
>> > 1157920892373161954235709850086879078532699846656405640e+23
>> > or 115792089237316195423570985008687907853269984665640564.0
Here's one more proposed change, this time for formatting
of floats using format() and the empty presentation type.
To avoid repeating myself, here's the text from the issue
I just opened:
http://bugs.python.org/issue5864
"""
In all versions of Python from 2.6 up, I get the following behaviour:
On Mon, May 4, 2009 at 10:10 AM, Larry Hastings wrote:
> So: you don't need it, it clutters up our code (particularly typeobject.c),
> and it adds overhead. The only good reason to keep it is backwards
> compatibility, which I admit is a fine reason.
Presumably whoever added the context field h
On Mon, May 4, 2009 at 8:11 PM, Daniel Stutzbach
wrote:
> If you make the change, will 3rd party code that relies on it fail in
> unexpected ways, or will they just get a compile error?
I *think* that third party code that's recompiled for 3.1 and that
doesn't use the closure field will either ju
On Mon, May 4, 2009 at 9:15 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> I *think* that third party code that's recompiled for 3.1 and that
>> doesn't use the closure field will either just work, or will produce an
>> easily-fixe
On Sat, Aug 1, 2009 at 11:40 PM, Vincent Legoll wrote:
> Hello,
>
> I've fed parts of the stdlib to pylint and after some filtering
> there appears to be some things that looks strange, I've
> filled a few bugs to the tracker for them.
>
>
>
> Is this useless and taking reviewer's time for nothing
Comments on some of the branches I've had involvement with...
On Mon, Aug 3, 2009 at 11:51 AM, Dirkjan Ochtman wrote:
> py3k-short-float-repr: strip streamed-merge
Sounds fine.
> py3k-issue1717: keep-clone
I don't think there's any need to keep this branch; its contents were
all merged (in pi
On Sat, Aug 15, 2009 at 8:54 PM, Scott David
Daniels wrote:
> [...] input to .setstate: old, new-short, and new-long. In trying to
> get this to work, I found what might be a bug:
> code says
> mt[0] = 0x8000UL; /* MSB is 1; assuring non-zero initial array */
> but probably should be:
> mt[0
On Mon, Sep 7, 2009 at 11:10 PM, Eric Smith wrote:
> Hmm, I never noticed that. At this point, I think changing the formatting
> for any types would break code, so we should just change the documentation
> to reflect how currently works.
I think the alignment for Decimal *does* need to be changed,
On Tue, Sep 22, 2009 at 3:37 PM, Chris Withers wrote:
> Where are the specifications on what happens if two objects are compared and
> both have implementations of __eq__? Which __eq__ is called?
> What happens if the first one called returns False? Is the second one called?
> What is one implem
On Tue, Sep 22, 2009 at 4:12 PM, Mark Dickinson wrote:
> I'll open an issue for the duplicate __eq__ calls.
http://bugs.python.org/issue6970
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
On Wed, Sep 23, 2009 at 9:12 AM, Chris Withers wrote:
> Mark Dickinson wrote:
>>
>> I (still :-) think this is covered, for Python 2.x at least, by:
>>
>> http://docs.python.org/reference/datamodel.html#coercion-rules
>
> But this isn't coercion! :-)
Agree
On Wed, Sep 23, 2009 at 4:43 AM, wrote:
>
> Dino> For IronPython we wrote a set of tests which go through and define
> Dino> the various operator methods in all sorts of combinations on both
> Dino> new-style and old-style classes as well as subclasses of those
> Dino> classes and the
On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland wrote:
> We are going to start contributing tests back real soon now. I'm not sure
> that these are the best tests to contribute as they require a version of
> Python to compare against rather than being nice and stand alone. But I'm
> sure we have
Hello all,
I'm looking for advice on how to clean up an ugliness (one
that I'm at least partly responsible for) in the Python build setup.
Here's the problem: some of the exported functions (e.g. atanh,
log1p) in the Python/pymath.c file aren't needed by the Python core
at all; they're exported
On Sun, Sep 27, 2009 at 8:48 AM, Brett Cannon wrote:
> On Sun, Sep 27, 2009 at 00:21, Mark Dickinson wrote:
[...]
>> So I've now got a file Modules/math_support.c that contains
>> some functions needed by both mathmodule.c and
>> cmathmodule.c, as well as a couple of f
On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
wrote:
> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>
>> I should note that I've softened my position slightly from what I posted
>> yesterday. I could live with the following compromise:
>>
>> >>> x = IPv4Network('192.168.1.1/24')
>
On Mon, Sep 28, 2009 at 3:42 PM, Dj Gilcrease wrote:
> On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
> wrote:
>> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>>
>>> I should note that I've softened my position slightly from what I posted
>>> yesterday. I could live with the followin
On Wed, Sep 30, 2009 at 1:44 AM, Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I would say that there certainly are precedents in other areas for
>>> keeping the information about the input form around. For example,
>>> occasionally it would be handy if parsing a hex integer returned an
>>> obj
On Wed, Sep 30, 2009 at 10:52 AM, Paul Moore wrote:
> 2009/9/30 Mark Dickinson :
>> Please could someone who understands the uses of IPNetwork better than
>> I do explain why the following wouldn't be a significant problem, if __eq__
>> and __hash__ were modified to disr
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Okay, so maybe this is an abuse of IPv4Network. But I'd (mis?)understood
>> that the retention of the .ip attribute was precisely a convenience to allow
>> this sort of use. If not, then
On Sat, Oct 3, 2009 at 4:41 PM, Steven Bethard wrote:
> I thought it might be useful for those who don't have time to read a
> million posts to have a summary of what's happened in the formatting
> discussion.
Definitely useful. Thanks for the summary!
[...]
> * Add a parameter which declares
In a recent #python-dev IRC conversation, it was suggested that we
should consider backporting the new-style float repr from py3k to
trunk. I'd like to get people's opinions on this idea.
To recap quickly, the algorithm for computing the repr of floats changed
between Python 2.x and Python 3.x (w
[Guido]
> I think you mean doctests? These are the primary reason I've always
> been hesitant to change this in 2.x.
Yes, sorry. I did of course mean doctests.
It occurs to me that any doctests that depend on the precise form of
repr(x) are, in a sense, already broken, since 2.x makes no guarante
On Mon, Oct 12, 2009 at 7:48 PM, Guido van Rossum wrote:
> On Mon, Oct 12, 2009 at 11:41 AM, Mark Dickinson wrote:
>> But str still has some value in py3k: it protects users from
>> accumulated rounded errors produced by arithmetic operations:
> [...]
>
> I kno
[I originally sent this reply to Skip instead of to the list; apologies.]
On Thu, Oct 15, 2009 at 12:39 PM, wrote:
> I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files
> but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in
> configure or pyconfig.h.
On Thu, Oct 15, 2009 at 4:06 PM, Antoine Pitrou wrote:
> pobox.com> writes:
>>
>> I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files
>> but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in
>> configure or pyconfig.h.in. Are builds --without-complex s
On Thu, Oct 15, 2009 at 8:17 PM, Antoine Pitrou wrote:
(-1)**.5
> (6.123031769111886e-17+1j)
>
> Don't we have a precision problem here? 0.5 is supposed to be represented
> exactly, isn't it?
0.5 is represented exactly, but complex.__pow__ makes no pretence of
being correctly rounded (and ma
On Sun, Oct 18, 2009 at 9:01 PM, Antoine Pitrou wrote:
> In Objects/longobject.c, there's the SIGCHECK() macro which periodically
> checks
> for signals when doing long integer computations (divisions, multiplications).
> It does so by messing with the _Py_Ticker variable.
>
> It was added in 19
1 - 100 of 388 matches
Mail list logo
