On 07/24/2012 08:47 PM, Guido van Rossum wrote:
>
> So what functionality specifically do you require? You speak in
> generalities but I need specifics.
The ability of thinking datetime.datetime as a flexible class that can
give you the representation you need when you need. To be more specific
th
Am 25.07.2012 03:46, schrieb Guido van Rossum:
> First you will have to show how you'd have to code this *without*
> nanosecond precision in datetime and how tedious that is. (I expect
> that representing the timestamp as a long integer expressing a posix
> timestamp times a billion would be very r
On Wed, 25 Jul 2012 11:24:14 +0200
Christian Heimes wrote:
> Am 25.07.2012 03:46, schrieb Guido van Rossum:
> > First you will have to show how you'd have to code this *without*
> > nanosecond precision in datetime and how tedious that is. (I expect
> > that representing the timestamp as a long in
On Wed, Jul 25, 2012 at 7:24 PM, Christian Heimes wrote:
> Am 25.07.2012 03:46, schrieb Guido van Rossum:
> I'd vote for two separate numbers, the first similar to JDN (Julian Day
> Number [1]), the second for nanoseconds per day. 3600 * 100 fit
> nicely into an unsigned 32bit int. This approa
Am 25.07.2012 13:48, schrieb Antoine Pitrou:
>> I'd vote for two separate numbers, the first similar to JDN (Julian Day
>> Number [1]), the second for nanoseconds per day. 3600 * 100 fit
>> nicely into an unsigned 32bit int.
>
> But 24 * 3600 * 1e9 doesn't. Perhaps I didn't understand your pro
Am 25.07.2012 14:11, schrieb Nick Coghlan:
> 1. For the reasons presented, I think it's worth attempting to define
> a common API that is based on datetime, but is tailored towards high
> precision time operations (at least using a different internal
> representation, perhaps supporting TAI).
This
Christian Heimes wrote:
>
> days
>
> 32bit signed integer
>
> numbers of days since Jan 1, 1 AD in proleptic Gregorian calendar (aka
> modern civil calendar). That's Rata Die minus one day since it defines
> Jan 1, 1 AD as day 1. This allows days between year 5.8 Mio in the past
> and 5.8 M
On Wed, Jul 25, 2012 at 7:11 AM, Christian Heimes wrote:
> Am 25.07.2012 14:11, schrieb Nick Coghlan:
>> 1. For the reasons presented, I think it's worth attempting to define
>> a common API that is based on datetime, but is tailored towards high
>> precision time operations (at least using a diff
1. For the reasons presented, I think it's worth attempting to define
a common API that is based on datetime, but is tailored towards high
precision time operations (at least using a different internal
representation, perhaps supporting TAI).
IIUC, the concern is about the DB-API, which does sor
I have a few questions about feature freeze:
(1) Is increasing test coverage acceptable during feature freeze, even
if it does not involve fixing a bug?
(2) When adding new tests (e.g. in the course of fixing a bug or
increasing test coverage), are we allowed to refactor other tests so
that suppo
2012/7/25 Chris Jerdonek :
> I have a few questions about feature freeze:
>
> (1) Is increasing test coverage acceptable during feature freeze, even
> if it does not involve fixing a bug?
>
> (2) When adding new tests (e.g. in the course of fixing a bug or
> increasing test coverage), are we allowe
On Thu, Jul 26, 2012 at 4:20 AM, vinay.sajip wrote:
> + .. note:: Because portions of the configuration are passed through
> + :func:`eval`, use of this function may open its users to a security
> risk.
> + While the function only binds to a socket on ``localhost``, and so does
> +
12 matches
Mail list logo
