> gcc Python.framework/Versions/3.0/Python -o python.exe \
>Modules/python.o \
> -ldl
> make: *** [sharedmods] Error 1
It seems likely that this is related to a report on comp.lang.python in
November:
http://mail.python.org/pipermail/python-list/20
On Wed, Jul 16, 2008 at 5:03 PM, nirinA raseliarison
<[EMAIL PROTECTED]> wrote:
> my initial motivation is to make these functions accessible,
> with just a few lines of additionnal code. that's so simple
> with a linux box!
As Daniel Stutzbach already hinted, the easiest way to just get at the
sy
On Wed, Jul 16, 2008 at 5:03 PM, nirinA raseliarison
<[EMAIL PROTECTED]> wrote:
> with the gamma from gcc under linux,
> which uses the MPFR library,
Are you sure it uses MPFR? I thought that for gcc 4.3, MPFR was used only for
compile-time constant expressions. For a call to tgamma whose argume
On Tue, Jul 15, 2008 at 1:32 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> If there is anything you need a decision on, please follow up to this
> thread. I'm inundated with email so I can't watch every thread on the
> mailing lists. Or ping me on #python-dev.
Can I request permission to check i
On Tue, Jul 15, 2008 at 9:10 AM, nirinA raseliarison
<[EMAIL PROTECTED]> wrote:
> gammas and errors functions are available from the C standard
> library. it would be nice to have them in the math module.
> or is there any reason not to include them?
One reason is that they're probably not availab
On Sun, Jun 29, 2008 at 12:36 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Indeed. On the other hand it already works properly for ints and floats,
> so perhaps Decimal shouldn't refuse unicode digits like it currently
> does:
Maybe. The IBM standard doesn't seem to say whether other Unicode
On Sat, Jun 28, 2008 at 9:45 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Wouldn't it be more natural that, at least when the pattern is a str object
> rather a bytes object, the re.UNICODE be implied by default?
Might this have some unintended consequences? For example, one
would then get the
On Sat, May 31, 2008 at 11:33 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> Now that the docs are reST, the source is almost pretty enough to display
> it raw, but I could also imagine a "text" writer that removes the more
> obscure markup to present a casual-reader-friendly text version.
>
> Th
On Thu, May 1, 2008 at 10:41 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> One way to optimise this (since all we need to support here is counting
> rather than arbitrary arithmetic) would be for the longrange iterator to use
> some simple pure C fixed point arithmetic internally to keep track of
On Tue, Apr 29, 2008 at 4:30 PM, Alexander Belopolsky <
[EMAIL PROTECTED]> wrote:
> I would say that if it is possible that n exceeds a few hundred
> million, it is a good idea to pause and think whether you want to have
> this loop implemented in Python to begin with.
>
Maybe. But the answer is
On Tue, Apr 29, 2008 at 10:30 AM, Alexander Belopolsky <
[EMAIL PROTECTED]> wrote:
> or sizable. I would say "range(n) is a memory efficient substitute
> for [0, 1, ... n-1]" is easier to fit into one's brain that the
> current hodgepodge of exceptions.
>
For what it's worth, I'm -1 on any chan
On Fri, Apr 25, 2008 at 12:04 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Eh, brain explosion from typing too late at night. The experiment I
> actually *meant* to try was:
>
> >>> x = range(0, 2**33, 2)
> >>> len(x)
> Traceback (most recent call last):
> File "", line 1, in
> OverflowError:
On Thu, Apr 24, 2008 at 11:50 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> There's definitely some bugs in this area of the range object code though:
>
> >>> x = range(2**33, 2)
> >>> len(x)
> 0
> >>> x[0]
> Traceback (most recent call last):
> File "", line 1, in
> IndexError: range object ind
On Thu, Apr 24, 2008 at 11:37 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> While I could understand a 'must fit in ssize_t' limitation on the index
> passed to the range object (or conceivably even on the value returned,
> although that would be a little odd), that isn't happening in the example
On Thu, Apr 24, 2008 at 10:58 AM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> r = range(1000)
> r[0]
> > Traceback (most recent call last):
> > File "", line 1, in
> > OverflowError: Python int too large to convert to C ssize_t
> >
> > This is a bug, right?
>
>
On Tue, Apr 15, 2008 at 6:06 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Input and output are often wildly asymmetric anyway. It's easy to make
> int() and float() accept more input types. But making them return a
> different output type is different. I find the existing work-arounds
> good
On Tue, Apr 15, 2008 at 2:37 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> Agreed. Otherwise the common ascii based network protocol task of reading
> some bytes in and converting them to the integer that they represent in
> ascii would require an additional unicode decoding step.
>
This use
This is a repeat of a question that came up on the "Decimal(unicode)" thread
a
little while ago. I think it needs an answer, so I'm reposting it in its
own thread.
I couldn't find any other previous discussion of this; apologies if I'm
rehashing
old issues.
Currently, int() and float() accept byt
On Mon, Apr 14, 2008 at 8:01 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
>
> Yeah, that's the 'wrong' part I was referring to. I guess I wanted to
> bring that issue up as well as question the actual implementation. For
> example, if we fixed the if statement, we'd having something looking like:
On Mon, Apr 14, 2008 at 6:02 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
>
> On Windows x64, sizeof(size_t) > sizeof(long), so the existing
> PyLong_FromSsize_t and PyLong_FromSize_t implementations in longobject.c are
> just plain wrong. I've patched it as follows, but as I'm not well versed in
I think test_tokenize is now fixed, too.
Mark
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
On Sat, Mar 15, 2008 at 8:00 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> test_datetime test_struct test_tokenize
>
I think I've fixed test_datetime and test_struct. I'm less sure what to do
for test_tokenize; the main cause of failure seems to be doctests
containing syntax that was va
On Fri, Feb 29, 2008 at 11:55 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
> They were failing for me a couple of days ago; checking now, they
> still are, and test_itertools has been added to the list of failing
> tests:
>
> test test_itertools failed -- Traceback (most recent call last):
> File "
On 9/30/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/9/28, Rob Crowther <[EMAIL PROTECTED]>:
>
> > a) MPF() now takes a float or integer argument because mpf_set_str is
> just
>
> Rob, there has been a *lot* of discussion about this for Decimal (see
> the PEP and discussions in python-de
24 matches
Mail list logo
