On Sun, Mar 13, 2011 at 12:41 AM, "Martin v. Löwis" wrote:
> Am 12.03.11 18:00, schrieb Glenn Linderman:
>>
>> On 3/12/2011 1:55 PM, Fredrik Johansson wrote:
>>>
>>> Consider sorting a list of pairs representing fractions. This can be
>>> do
On Sat, Mar 12, 2011 at 9:44 PM, Guido van Rossum wrote:
> I was just reminded that in Python 3, list.sort() and sorted() no
> longer support the cmp (comparator) function argument. The reason is
> that the key function argument is always better. But now I have a
> nagging doubt about this:
>
> I
On Sat, May 2, 2009 at 9:01 PM, Georg Brandl wrote:
> Hi,
>
> this is just a short notice that Mattias Brändström and I have finished a
> patch to implement the previously discussed and mostly warmly welcomed
> extension to with's syntax, allowing
>
> with A() as a, B() as b:
>
> to be written i
On Tue, Apr 7, 2009 at 8:59 PM, Alexandru Moșoi wrote:
> Not necessarily. For example C/C++ doesn't define the order of the
> operations inside an expression (and AFAIK neither Python) and
> therefore folding 2 * 3 is OK whether b is an integer or an arbitrary
> object with mul operator overloade
On Wed, Jan 7, 2009 at 9:48 PM, Raymond Hettinger wrote:
> Does anyone here have access to Mathematica?
> I would like to know what it returns for:
>
> In[1]:= Permutations({a, b, c}, {5})
>
> Knowing this will help resolve a feature request
> for itertools.permutations() and friends.
I assume yo
On Wed, Jul 30, 2008 at 2:26 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 25, 2008 at 6:50 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Sebastien Loisel wrote:
>>
>>> What are the odds of this thing going in?
>>
>> I don't know. Guido has said nothing about it so far this
>> time r
On Fri, Jul 25, 2008 at 12:06 AM, Scott Dial
<[EMAIL PROTECTED]> wrote:
> Perhaps I'm nobody, but I think this would be ridiculous. Matrices are
> not native objects to the language. There is no type(matrix). The notion
> of what makes a Python object a matrix is a convention and to have
> built-i
On Sun, Jun 1, 2008 at 8:15 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Discussion
> --
> The only known use cases for variants of int are types that limit the range
> of
> values to those that fit in a fixed storage width.
Add:
* Faster big integers (gmpy)
* Integers with exact div
On Nov 28, 2007 4:20 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
> open for better suggestions.
Perhaps __basic__?
Fredrik
___
Python-Dev mailing list
Python-Dev@python.org
htt
On 10/16/07, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> The alternative would be to implement addition digit-by-digit in
> decimal.py; this would be asymptotically linear but would be much
> slower for the low precision ( < 50 digits, say)
> decimals that almost everybody is going to be using in
On 8/29/07, dany <[EMAIL PROTECTED]> wrote:
> Looking deeper in the python PEPs, I saw that division on integers is
> defined as: idiv(a, b) = floor(fdiv(a, b)).
> This non-quotient division leads to some odd results, e.g. Python seems
> to think -3/2+3/2 = -1. This is clearly, and correct me if I'
On 4/13/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> One low-effort approach is to use a general root-finding algorithm and
> build ln(x) on top of exp() via (numerically) solving the equation
> exp(ln(x)) == x for ln(x). That appears to be what Don Peterson did
> in his implementation of transcend
I like the present print statement because parentheses are
inconvenient to type compared to lowercase letters, and it looks less
cluttered without them. The parentheses in writeln("hello world")
don't add any more meaning than a terminating semicolon would, so why
are they necessary?
Why not inste
Should I write a PEP?
- Fredrik
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 6/27/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Fredrik Johansson writes:
> > In either case, compatibility can be ensured by allowing both n-digit
> > decimal and hardware binary precision for floats, settable via a float
> > context.
>
> Perhaps you
On 6/22/05, Skip Montanaro <[EMAIL PROTECTED]> wrote:
> If nothing else, extension module code that executes
>
> f = PyFloat_AsDouble(o);
>
> or
>
> if (PyFloat_Check(o)) {
>...
> }
>
> would either have to change or those functions would have to be rewritten to
> accept Dec
On 6/22/05, Michael McLay <[EMAIL PROTECTED]> wrote:
> This idea is dead on arrival. The change would break many applications and
> modules. A successful proposal cannot break backwards compatibility. Adding a
> dpython interpreter to the current code base is one possiblity.
Is there actually much
idea :-) Sorry if this has been discussed and/or rejected before (this
is my first post to python-dev, though I've occasionally read the list
since I started using Python extensively about two years ago).
Fredrik Johansson
___
Python-De
18 matches
Mail list logo
