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 fro
On Thu, Feb 2, 2012 at 11:03 AM, Victor Stinner
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
> supposed to help the discussion
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 somewhere else", and since
On Thu, Feb 2, 2012 at 11:01 AM, Eric V. Smith wrote:
> On 2/1/2012 7:49 PM, Nick Coghlan wrote:
>> On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney
>> wrote:
3) Should it be an exception, or just inherit from object?
Is it worth worrying about somebody trying to raise it, or
raise
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: $Revisi
On 2/1/2012 7:49 PM, Nick Coghlan wrote:
> On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney
> 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 prev
On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney
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
> free. My feeling is
On 2 February 2012 11:18, Ethan Furman 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 explicitly the __c
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 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 al
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:
http://mail.pyt
On Wed, Feb 1, 2012 at 15:41, Brian Curtin wrote:
> On Wed, Feb 1, 2012 at 15:37, Catalin Iacob wrote:
>> On Tue, Jan 17, 2012 at 9:43 PM, "Martin v. Löwis"
>> wrote:
>> ...
>>> P.S. Here is my personal list of requirements and non-requirements:
>> ...
>>> - must generate binaries that run on W
On Wed, Feb 1, 2012 at 15:37, Catalin Iacob wrote:
> On Tue, Jan 17, 2012 at 9:43 PM, "Martin v. Löwis" 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 VS201
On Tue, Jan 17, 2012 at 9:43 PM, "Martin v. Löwis" 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 Windows 2000, XP RT
On Wed, Feb 1, 2012 at 12:55 PM, Ethan Furman wrote:
> Guido van Rossum wrote:
>>
>> On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman 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 o
Guido van Rossum wrote:
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman 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. I often *think* of
Not a bad idea.
On Wed, Feb 1, 2012 at 12:53 PM, Terry Reedy wrote:
> On 2/1/2012 3:07 PM, Guido van Rossum wrote:
>>
>> On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman wrote:
>>>
>>> Guido van Rossum wrote:
Hm... Reading this draft, I like the idea of using "raise X from
None"
On 2/1/2012 3:07 PM, Guido van Rossum wrote:
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman 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 t
On Wed, Feb 1, 2012 at 11:08 AM, stefan brunthaler wrote:
> On Wed, Feb 1, 2012 at 09:46, Guido van Rossum 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
On Sun, Jan 29, 2012 at 14:23, Trent Nelson 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 so and would like
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
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 Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman 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
>> __cause__
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 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).
On Wed, Feb 1, 2012 at 09:46, Guido van Rossum 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 stuff you didn'
Guido van Rossum 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. Wou
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 (
On Wed, Feb 1, 2012 at 9:13 AM, Hans Mulder 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 tha
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 to
On Jan 31, 2012 11:08 PM, "Nick Coghlan" 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, you don't have
t
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
> 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.
>
> Ple
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 s
> 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 pa
On Wed, Feb 1, 2012 at 9:40 PM, Victor Stinner
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 divisor cannot be writt
> 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 f
On Wed, Feb 1, 2012 at 9:08 PM, Antoine Pitrou 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 everywhere, tho
On Wed, 1 Feb 2012 14:08:34 +1000
Nick Coghlan wrote:
> On Wed, Feb 1, 2012 at 12:35 PM, Antoine Pitrou 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 of ``time.time(format='decimal'
On Wed, Feb 1, 2012 at 6:03 PM, Victor Stinner
wrote:
> 2012/2/1 Nick Coghlan :
>> 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)
2012/2/1 Nick Coghlan :
> 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) + Decimal(fraction) * Decim
41 matches
Mail list logo
