stefan brunthaler, 31.01.2012 22:17:
>> Well, nobody wants to review generated code.
>>
> I agree. The code generator basically uses templates that contain the
> information and a dump of the C-structure of several types to traverse
> and see which one of them implements which functions. There is r
What an appropriate title since I sent it to the wrong place. :(
~Ethan~
___
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
Ethan Furman wrote:
Only PyException_GetCause is directly related to PEP 409 -- should I
only fix that one, and open up a new issue on the tracker for the other
three, or should I fix all four now?
The specific question is now irrelevant (still learning the differences
between the C code and
On Wed, Feb 1, 2012 at 3:07 PM, Ethan Furman wrote:
> I'm looking at the docs to make the relevant changes due to PEP 409, and I'm
> noticing some problems.
>
> E.g. The PyException_Get|Set_Context|Cause all talk about using NULL to
> clear the related attribute, when actually in should be Py_None
I'm looking at the docs to make the relevant changes due to PEP 409, and
I'm noticing some problems.
E.g. The PyException_Get|Set_Context|Cause all talk about using NULL to
clear the related attribute, when actually in should be Py_None.
Only PyException_GetCause is directly related to PEP 40
On Wed, Feb 1, 2012 at 1:57 PM, Ethan Furman wrote:
> I haven't seen any further discussion here or in the bug tracker. Below is
> the latest version of this PEP, now with a section on Language Details.
>
> Who makes the final call on this? Any idea how long that will take? (Not
> that I'm antsy
PEP: 409
Title: Suppressing exception context
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2012
Post-History: 30-Aug-2002, 01-Feb-2012
Abstract
One of the open issues from PEP 3134 is suppre
I haven't seen any further discussion here or in the bug tracker. Below
is the latest version of this PEP, now with a section on Language Details.
Who makes the final call on this? Any idea how long that will take?
(Not that I'm antsy, or anything... ;)
PEP: 409
Title: Suppressing exceptio
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')`` or
> ``time.decimal_time()``.
Getting the current time is
Analysis paralysis commence. +1 for separate module using decimal.
On Feb 1, 2012 1:44 PM, "PJ Eby" wrote:
> On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan wrote:
>
>> Such a protocol can easily be extended to any other type - the time
>> module could provide conversion functions for integers and
On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan wrote:
> Such a protocol can easily be extended to any other type - the time
> module could provide conversion functions for integers and float
> objects (meaning results may have lower precision than the underlying
> system calls), while the existing
On Wed, 1 Feb 2012 10:35:08 +1000
Nick Coghlan wrote:
>
> With this approach, API usage might end up looking something like:
>
>>>> time.time()
>1328006975.681211
>>>> time.time(convert=time.as_float)
>1328006975.681211
>>>> time.time(convert=time.as_int)
>1328006979
>
On Wed, Feb 1, 2012 at 8:58 AM, Mark Shannon wrote:
> Why not add a new function rather than modifying time.time()?
> (after all its just a timestamp, does it really need nanosecond precision?)
>
> For those who do want super-accuracy then add a new function
> time.picotime() (it could be nanotime
Alexander Belopolsky wrote:
On Tue, Jan 31, 2012 at 7:13 AM, Antoine Pitrou wrote:
On Tue, 31 Jan 2012 21:11:37 +1000
Nick Coghlan wrote:
Having a low-level module like os needing to know about higher-level
types like decimal.Decimal and datetime.datetime (or even timedelta)
should be setting
Nick mentioned using a single type and converting upon return, I'm starting
to like that more. A limited set of time formats is mostly arbitrary, and
there will always be a performance hit deciding which type to return.
The goal here is to allow high precision timings with minimal cost. A
separate
On 1/31/2012 3:10 PM, Raymond Hettinger wrote:
On Jan 29, 2012, at 6:11 PM, John O'Connor wrote:
On Sat, Jan 28, 2012 at 3:07 PM, Benjamin Peterson
mailto:benja...@python.org>> wrote:
But why would you want to pass a float? It seems like API abuse to me.
Agreed. Anything else seems meaning
I concur. This is very much a non-problem.
There is no need to add more code and slow
running time with superfluous type checks.
Raymond
What do you think about the following check from threading.py:
@@ -317,8 +317,6 @@
self._value = value
def acquire(self, blocking=True, time
> (I removed the timespec format, I consider that we don't need it.)
>
> Rather, I guess you removed it because it didn't fit the "types as flags"
> pattern.
I removed it because I don't like tuple: you cannot do arithmetic on
tuple, like t2-t1. Print a tuple doesn't give you a nice output. It is
> There is also the issue of the two test modules removed from the
> test suite.
>
Oh, I'm sorry, seems like the patch did contain too much of my
development stuff. (I did remove them before, because they were always
failing due to the instruction opcodes being changed because of
quickening; they p
Am 31.01.2012 16:46, schrieb stefan brunthaler:
>> If I read the patch correctly, most of it is auto-generated (and there
>> is probably a few spurious changes that blow it up, such as the
>> python-gdb.py file).
>
> Hm, honestly I don't know where the python-gdb.py file comes from, I
> thought it
Am 31.01.2012 13:08, schrieb Victor Stinner:
>> This way you don't need to maintain a
>> mapping of strings to classes, and other functions/third party can join in
>> the fun without needing access to the latest canonical mapping. Lastly there
>> will be no confusion or contention for duplicate ke
On Jan 29, 2012, at 6:11 PM, John O'Connor wrote:
> On Sat, Jan 28, 2012 at 3:07 PM, Benjamin Peterson
> wrote:
>> But why would you want to pass a float? It seems like API abuse to me.
>>
>
> Agreed. Anything else seems meaningless.
I concur. This is very much a non-problem.
There is no ne
On Tue, Jan 31, 2012 at 7:13 AM, Antoine Pitrou wrote:
> On Tue, 31 Jan 2012 21:11:37 +1000
> Nick Coghlan wrote:
>>
>> Having a low-level module like os needing to know about higher-level
>> types like decimal.Decimal and datetime.datetime (or even timedelta)
>> should be setting off all kinds o
On Mon, Jan 30, 2012 at 6:31 PM, Victor Stinner
wrote:
> Alexander Belopolsky proposed to use
> time.time(format=datetime.datetime) instead.
Just to make sure my view is fully expressed: I am against adding flag
arguments to time.time(). My preferred solution to exposing high
resolution clocks i
On 2012-01-31 00:23, Benjamin Peterson wrote:
2012/1/30 Nick Coghlan:
On Tue, Jan 31, 2012 at 8:11 AM, Matt Joiner wrote:
It's also potentially lossy if you incremented and decremented until integer
precision is lost. My vote is for an int type check. No casting.
operator.index() is built fo
On Tue, Jan 31, 2012 at 06:47, Paul Moore wrote:
> On 31 January 2012 11:11, Nick Coghlan wrote:
> > although decimal.Decimal is also a contender if backed up by
> > Stefan's C implementation.
>
> As you mention this, and given the ongoing thread about __preview__
> and "nearly ready for stdlib"
> If I read the patch correctly, most of it is auto-generated (and there
> is probably a few spurious changes that blow it up, such as the
> python-gdb.py file).
Hm, honestly I don't know where the python-gdb.py file comes from, I
thought it came with the switch from 3.1 to the tip version I was
u
> I assume "yes" here means "yes, I'm aware" and not "yes, I'm using Python
> 2", right? And you're building on top of the existing support for threaded
> code in order to improve it?
>
Your assumption is correct, I'm sorry for the sloppiness (I was
heading out for lunch.) None of the code is 2.x c
Nick Coghlan, 31.01.2012 12:11:
> On Tue, Jan 31, 2012 at 7:42 PM, Victor Stinner wrote:
>>> I think this is definitely worth elaborating in a PEP (to recap the
>>> long discussion in #11457 if nothing else).
>>
>> The discussion in issues #13882 and #11457 already lists many
>> alternatives with t
> - use datetime (bad idea for the reasons Martin mentioned)
It is only a bad idea if it is the only available choice.
> - use timedelta (not mentioned on the tracker, but a *much* better fit
> for a timestamp than datetime, since timestamps are relative to the
> epoch while datetime objects try
On Tue, 31 Jan 2012 21:11:37 +1000
Nick Coghlan wrote:
>
> Having a low-level module like os needing to know about higher-level
> types like decimal.Decimal and datetime.datetime (or even timedelta)
> should be setting off all kinds of warning bells.
Decimal is ideally low-level (it's a number),
Hi,
2012/1/31 Matt Joiner :
> Sounds good, but I also prefer Alexander's method. The type information is
> already encoded in the class object.
Ok, I posted a patch version 6 to use types instead of strings. I also
prefer types because it solves the "hidden import" issue.
> This way you don't ne
On 31 January 2012 11:11, Nick Coghlan wrote:
> although decimal.Decimal is also a contender if backed up by
> Stefan's C implementation.
As you mention this, and given the ongoing thread about __preview__
and "nearly ready for stdlib" modules, what is the current position on
cdecimal? I seem to
On Tue, Jan 31, 2012 at 7:42 PM, Victor Stinner
wrote:
>> I think this is definitely worth elaborating in a PEP (to recap the
>> long discussion in #11457 if nothing else).
>
> The discussion in issues #13882 and #11457 already lists many
> alternatives with their costs and benefits, but I can pro
> I think this is definitely worth elaborating in a PEP (to recap the
> long discussion in #11457 if nothing else).
The discussion in issues #13882 and #11457 already lists many
alternatives with their costs and benefits, but I can produce a PEP if
you need a summary.
> In particular, I'd want to
35 matches
Mail list logo
