2012/2/1 Nick Coghlan ncogh...@gmail.com:
The secret to future-proofing such an API while only using integers
lies in making the decimal exponent part of the conversion function
signature:
def from_components(integer, fraction=0, exponent=-9):
return Decimal(integer) +
On Wed, Feb 1, 2012 at 6:03 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
2012/2/1 Nick Coghlan ncogh...@gmail.com:
The secret to future-proofing such an API while only using integers
lies in making the decimal exponent part of the conversion function
signature:
def
On Wed, 1 Feb 2012 14:08:34 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Feb 1, 2012 at 12:35 PM, Antoine Pitrou solip...@pitrou.net wrote:
It strikes me as inelegant to have to do so much typing for something
as simple as getting the current time. We should approach the
simplicity
On Wed, Feb 1, 2012 at 9:08 PM, Antoine Pitrou solip...@pitrou.net wrote:
Right, but that's not even a plausible request. Nobody wants to write a
separate time module just to have a different return type.
I can definitely see someone doing import hirestime as time to avoid
having to pass a flag
If a callback protocol is used at all, there's no reason those details
need to be exposed to the callbacks. Just choose an appropriate
exponent based on the precision of the underlying API call.
If the clock divisor cannot be written as a power of 10, you loose
precision, just because your
On Wed, Feb 1, 2012 at 9:40 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
If a callback protocol is used at all, there's no reason those details
need to be exposed to the callbacks. Just choose an appropriate
exponent based on the precision of the underlying API call.
If the clock
How many times did you regenerate this code until you got it right?
Well, honestly, I changed the code generator to pack the new
optimized instruction derivatives densly into the available opcodes,
so that I can make optimal use of what's there. Thus I only generated
the code twice for this
Wiadomość napisana przez stefan brunthaler w dniu 1 lut 2012, o godz. 16:55:
And how do you know that you really got it so right that it was the last
time ever
that you needed your generator for it?
I am positive that I am going to need my code generator in the future,
as I have several
But let me put this straight: as an open-source project, we are hesitant to
accept changes which depend on closed software. Even if your optimization
techniques would result in performance a hundred times better than what is
currently achieved, we would still be wary to accept them.
Please
On 30/01/12 00:30:14, Steven D'Aprano wrote:
Mark Shannon wrote:
Antoine Pitrou wrote:
[..]
Antoine is right. It is a reorganisation of the dict, plus a couple of
changes to typeobject.c and object.c to ensure that instance
dictionaries do indeed share keys arrays.
I don't quite follow
On Jan 31, 2012 11:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
PJE is quite right that using a new named protocol rather than a
callback with a particular signature could also work, but I don't see
a lot of advantages in doing so.
The advantage is that it fits your brain better. That is,
Let's make one thing clear. The Python core developers need to be able
to reproduce your results from scratch, and that means access to the
templates, code generators, inputs, and everything else you used. (Of
course for stuff you didn't write that's already open source, all we
need is a pointer
On Wed, Feb 1, 2012 at 9:13 AM, Hans Mulder han...@xs4all.nl wrote:
On 30/01/12 00:30:14, Steven D'Aprano wrote:
Mark Shannon wrote:
Antoine Pitrou wrote:
[..]
Antoine is right. It is a reorganisation of the dict, plus a couple of
changes to typeobject.c and object.c to ensure that
Hm... Reading this draft, I like the idea of using raise X from
None, but I still have one quibble. It seems the from clause sets
__cause__, and __cause__ can indicate three things: (1) print
__cause__ (explicitly set), (2) print __context__ (default), (3) print
neither (raise X from None). For
Guido van Rossum guido at python.org writes:
Hey, I like this! It's a subtle encouragement for developers to
initialize all their instance variables in their __init__ or __new__
method, with a (modest) performance improvement for a carrot. (Though
I have to admit I have no idea how you do it.
On Wed, Feb 1, 2012 at 09:46, Guido van Rossum gu...@python.org wrote:
Let's make one thing clear. The Python core developers need to be able
to reproduce your results from scratch, and that means access to the
templates, code generators, inputs, and everything else you used. (Of
course for
On Feb 1, 2012, at 12:46 PM, Guido van Rossum wrote:
I understand that you're hesitant to just dump your current mess, and
you want to clean it up before you show it to us. That's fine. (...) And
remember, it doesn't need to be
perfect (in fact perfectionism is probably a bad idea here).
Guido van Rossum wrote:
Hm... Reading this draft, I like the idea of using raise X from
None, but I still have one quibble. It seems the from clause sets
__cause__, and __cause__ can indicate three things: (1) print
__cause__ (explicitly set), (2) print __context__ (default), (3) print
neither
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman et...@stoneleaf.us wrote:
Guido van Rossum wrote:
Hm... Reading this draft, I like the idea of using raise X from
None, but I still have one quibble. It seems the from clause sets
__cause__, and __cause__ can indicate three things: (1) print
Hey, I like this! It's a subtle encouragement for developers to
initialize all their instance variables in their __init__ or __new__
method, with a (modest) performance improvement for a carrot. (Though
I have to admit I have no idea how you do it. Wouldn't the set of dict
keys be different while
On Thu, Jan 26, 2012 at 12:54:31PM -0800, mar...@v.loewis.de wrote:
Is this considered a new feature that has to be in by the first beta?
I'm hoping to have it completed much sooner than that so we can get
mileage on it, but is there a cutoff for changing the compiler?
At some point, I'll
On Sun, Jan 29, 2012 at 14:23, Trent Nelson tr...@snakebite.org wrote:
Brian, what are your plans? Are you going to continue working in
hg.python.org/sandbox/vs2010port then merge everything over when
ready? I have some time available to work on this for the next
three weeks or
On Wed, Feb 1, 2012 at 11:08 AM, stefan brunthaler s.bruntha...@uci.edu wrote:
On Wed, Feb 1, 2012 at 09:46, Guido van Rossum gu...@python.org wrote:
Let's make one thing clear. The Python core developers need to be able
to reproduce your results from scratch, and that means access to the
On 2/1/2012 3:07 PM, Guido van Rossum wrote:
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furmanet...@stoneleaf.us wrote:
Guido van Rossum wrote:
Hm... Reading this draft, I like the idea of using raise X from
None, but I still have one quibble. It seems the from clause sets
__cause__, and
Not a bad idea.
On Wed, Feb 1, 2012 at 12:53 PM, Terry Reedy tjre...@udel.edu wrote:
On 2/1/2012 3:07 PM, Guido van Rossum wrote:
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furmanet...@stoneleaf.us wrote:
Guido van Rossum wrote:
Hm... Reading this draft, I like the idea of using raise X from
Guido van Rossum wrote:
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman et...@stoneleaf.us wrote:
My apologies for my ignorance, but is the code smell because both False and
None evaluate to bool(False)?
That's part of it, but the other part is that the type of __context__
is now truly dynamic.
On Wed, Feb 1, 2012 at 12:55 PM, Ethan Furman et...@stoneleaf.us wrote:
Guido van Rossum wrote:
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman et...@stoneleaf.us wrote:
My apologies for my ignorance, but is the code smell because both False
and
None evaluate to bool(False)?
That's part of
On Tue, Jan 17, 2012 at 9:43 PM, Martin v. Löwis mar...@v.loewis.de wrote:
...
P.S. Here is my personal list of requirements and non-requirements:
...
- must generate binaries that run on Windows XP
I recently read about Firefox switching to VS2010 and therefore
needing to drop support for
On Wed, Feb 1, 2012 at 15:37, Catalin Iacob iacobcata...@gmail.com wrote:
On Tue, Jan 17, 2012 at 9:43 PM, Martin v. Löwis mar...@v.loewis.de wrote:
...
P.S. Here is my personal list of requirements and non-requirements:
...
- must generate binaries that run on Windows XP
I recently read
On Wed, Feb 1, 2012 at 15:41, Brian Curtin br...@python.org wrote:
On Wed, Feb 1, 2012 at 15:37, Catalin Iacob iacobcata...@gmail.com wrote:
On Tue, Jan 17, 2012 at 9:43 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
...
P.S. Here is my personal list of requirements and non-requirements:
...
raise from None seems pretty in band. A NoException class could have many
other uses and leaves no confusion about intent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Sun, Jan 29, 2012 at 12:23:14PM -0800, Trent Nelson wrote:
* Updates to externals/(tcl|tk)-8.5.9.x so that they both build with
VS2010.
Before I go updating tcl/tk, any thoughts on bumping our support to
the latest revision, 8.5.11?
I guess the same question applies to all
Terry Reedy wrote:
It sounds like you are asking for a special class
__NoException__(BaseException) to use as the marker.
Guido van Rossum wrote:
So what did you think of Terry Reedy's idea of using a special exception class?
Our table would then look like:
__context__
On 2 February 2012 11:18, Ethan Furman et...@stoneleaf.us wrote:
Implementation questions for the __NoException__ route:
1) Do we want double underscores, or just a single one?
I'm thinking double to mark it as special as opposed
to private.
Double and exposed allows someone to
On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney
timothy.c.dela...@gmail.com wrote:
3) Should it be an exception, or just inherit from object?
Is it worth worrying about somebody trying to raise it, or
raise from it?
If it's not actually an exception, we get prevention of instantiation for
On 2/1/2012 7:49 PM, Nick Coghlan wrote:
On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney
timothy.c.dela...@gmail.com wrote:
3) Should it be an exception, or just inherit from object?
Is it worth worrying about somebody trying to raise it, or
raise from it?
If it's not actually an
Even if I am not really conviced that a PEP helps to design an API,
here is a draft of a PEP to add new timestamp formats to Python 3.3.
Don't see the draft as a final proposition, it is just a document
supposed to help the discussion :-)
---
PEP: xxx
Title: New timestamp formats
Version:
On Thu, Feb 2, 2012 at 11:01 AM, Eric V. Smith e...@trueblade.com wrote:
On 2/1/2012 7:49 PM, Nick Coghlan wrote:
On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney
timothy.c.dela...@gmail.com wrote:
3) Should it be an exception, or just inherit from object?
Is it worth worrying about somebody
On 2 February 2012 12:43, Nick Coghlan ncogh...@gmail.com wrote:
Hmm, after writing up that list, the idea of using __cause__ is
Ellipsis (or even __cause__ is ...)to mean use __context__
instead occurs to me. After all, ... has the right connotations of
fill this in from somewhere else, and
On Thu, Feb 2, 2012 at 11:03 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Even if I am not really conviced that a PEP helps to design an API,
here is a draft of a PEP to add new timestamp formats to Python 3.3.
Don't see the draft as a final proposition, it is just a document
Tim Delaney wrote:
On 2 February 2012 12:43, Nick Coghlan wrote:
Hmm, after writing up that list, the idea of using __cause__ is
Ellipsis (or even __cause__ is ...)to mean use __context__
instead occurs to me. After all, ... has the right connotations of
fill this in from
41 matches
Mail list logo
