On 05/21/10 15:18, Yaniv Aknin wrote:
> I would if I were qualified, but I an mot. One way to get people to help
>> with details is to publish mistakes. This happens all the time on
>> python-list ;-). Pre-review would be nice though.
>>
>
> I don't mind so much the 'humiliation' of published mist
On 05/08/10 03:57, Steve Holden wrote:
> Steven D'Aprano wrote:
>>
>> [...]
>>> Similarly, if you wanted p1==p2, why not write
>>>
>>> p1 = partial(operator.add)
>>> p2 = p1
>>
>> I thought the OP gave a use-case. He's generating "jobs" (partial
>> applied to a callable and arguments), and
Michael Foord wrote:
Benjamin Peterson wrote:
2009/10/5 Nick Coghlan :
So I would agree that method invocation on literals (particularly string
literals) is an already established language idiom.
And who hasn't ever used 4.56.as_integer_ratio()? :)
>
I've tried 4.__add__ a few times
Raymond Hettinger wrote:
I concur. Numbers are naturally right aligned.
Isn't numbers are "naturally right aligned" because of the Big Endian
notations that most mathematicians currently use. Had we been using
Little Endian notation, numbers would be naturally left-aligned,
wouldn't they?
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lie Ryan wrote:
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Moore wrote:
2009/3/13 Chris Withers :
If a decent package management system *was* included, this wouldn't be an
issue..
Remember t
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Moore wrote:
2009/3/13 Chris Withers :
If a decent package management system *was* included, this wouldn't be an
issue..
Remember that a "decent package management system" needs to handle
filling in all the forms and arrang
Steven D'Aprano wrote:
On Fri, 13 Mar 2009 01:02:26 pm R. David Murray wrote:
On Fri, 13 Mar 2009 at 00:35, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
Seriously, though, the point is that IMO an application should not
be calling fsync unless it provides a way for that behavio
James Y Knight wrote:
On Mar 11, 2009, at 11:40 PM, Nick Coghlan wrote:
Raymond Hettinger wrote:
It is not the goal to replace locale or to accomodate every
possible convention. The goal is to make a common task easier
for many users. The current, default use of the period as a decimal
point
Scott Dial wrote:
Aahz wrote:
On Wed, Mar 11, 2009, Antoine Pitrou wrote:
After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
open(..., sync_on="close")
open(..., sync_on="flush")
with a default of None meaning no implicit syncs.
That looks good, though I'd prefe
PEP 239 says that Rational type was Rejected, but some time ago this
decision is reverted, and now python 3.0 and python 2.6 includes a
fractions.Fraction type. Shouldn't this PEP be updated? (At least to
include a note of its obsoleted status or to point to the reversion)
Martin v. Löwis wrote:
The prize was Martin von Löwis of the Python Foundation on behalf of the
Python community itself.
This is a funny translation from German-to-English. :-)
But yeah, a good one and the prize was presented by Klaus Knopper of Knoppix.
Congratulations!
Actually, the prize
Terry Reedy wrote:
Lie Ryan wrote:
Isn't ordered dictionary essentially also an "always sorted"
container? It is always sorted depending on the order of insertion? I
can't see any technical reason why the data structure can't
accommodate them both. Can you point m
Steven D'Aprano wrote:
I also can't think of an alternative
explanation, so thus far, it's resistant to false positive semantics.
"The keys don't expire with time."
"It's stable against accidental deletions."
"It's stable against accidentally over-writing values."
Add to that:
"The StableDict
Nick Coghlan wrote:
Lie Ryan wrote:
How about making odict ordered by insertion order, then provide an
optional argument for defining sorter? This optional argument must be a
function/lambda/callable object and must be the first argument.
or better yet, in the spirit of dumping cmp
Steve Holden wrote:
Raymond Hettinger wrote:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
Issues:
Gisle Aas wrote:
On Mar 4, 2009, at 9:01 , Glenn Linderman wrote:
On approximately 3/3/2009 11:22 PM, came the following characters from
the keyboard of Raymond Hettinger:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
On Mon, 23 Feb 2009 23:22:19 +, tav wrote:
> Steve, this isn't death by a 1,000 cuts. What's being put forward here
> is not a specific implementation -- but rather a specific model of
> security (the object capability model) -- which has been proven to be
> foolproof.
Proven? Isn't it imposs
On Thu, 19 Feb 2009 21:41:51 -0600, Benjamin Peterson wrote:
> As we prepare to merge the io-c branch, the question has come up [1]
> about the original Python implementation. Should it just be deleted in
> favor C version? The wish to maintain the two implementations together
> has been raised on
On Tue, 17 Feb 2009 11:04:35 +1300, Greg Ewing wrote:
> Leif Walsh wrote:
>
>> If only we had a second Earth to mess with, we could just copy and
>> swap.
>
> Or we could use a generational approach, doing all our messy stuff
> around the moon and copying to earth when we've got our traffic cont
On Sat, 13 Dec 2008 13:28:37 +, Michael Foord wrote:
> Lie Ryan wrote:
>> I'm sure probably most of you knows about psyco[1], the optimizer.
>> Python has an -O and -OO flag that is intended to be optimization flag,
>> but we know that currently it doesn'
I'm sure probably most of you knows about psyco[1], the optimizer. Python
has an -O and -OO flag that is intended to be optimization flag, but we
know that currently it doesn't do much. Why not add psyco as standard
library and let -O or -OO invoke psyco?
[1] http://psyco.sourceforge.net/index.
On Tue, 09 Dec 2008 12:15:53 -0500, Steve Holden wrote:
> Is anyone aware of any implementations that use other than 64-bit
> floating-point? I'd be particularly interested in any that use greater
> precision than the usual 56-bit mantissa. Do modern 64-bit systems
> implement anything wider than
22 matches
Mail list logo
