Am 13.02.2012 13:59, schrieb Victor Stinner:
> Hi,
>
> My work on the PEP 410 tries to unify the code to manipulate
> timestamps. The problem is that I'm unable to decide how to round
> these numbers.
>
> Functions using a resolution of 1 second (e.g. time.mktime) expects
> rounding towards zero
On Tue, Feb 14, 2012 at 5:13 PM, Gregory P. Smith wrote:
> On Tue, Feb 14, 2012 at 4:23 PM, Nick Coghlan wrote:
>> On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw wrote:
>>> My primary concern with the PEP is adding to users confusion when they have
>>> to
>>> handle (at least) 5 different types[
On Tue, Feb 14, 2012 at 4:23 PM, Nick Coghlan wrote:
> On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw wrote:
>> My primary concern with the PEP is adding to users confusion when they have
>> to
>> handle (at least) 5 different types[*] that represent time in Python.
>
> My key question to those a
On Tue, Feb 14, 2012 at 2:29 PM, Barry Warsaw wrote:
> I think I will just state my reasoning one last time and then leave it to the
> BDFL or BDFOP to make the final decision.
>
> Victor on IRC says that there is not much difference between Decimal and
> timedelta, and this may be true from an im
On Mon, Feb 13, 2012 at 4:59 AM, Victor Stinner
wrote:
> Hi,
>
> My work on the PEP 410 tries to unify the code to manipulate
> timestamps. The problem is that I'm unable to decide how to round
> these numbers.
>
> Functions using a resolution of 1 second (e.g. time.mktime) expects
> rounding towa
On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw wrote:
> My primary concern with the PEP is adding to users confusion when they have to
> handle (at least) 5 different types[*] that represent time in Python.
My key question to those advocating the use of timedelta instead of Decimal:
What should t
On Wed, Feb 15, 2012 at 12:44 AM, Barry Warsaw wrote:
> On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
>
>>> One other thing I'd like to see the PEP address is a possible migration
>>> strategy to python->python3. Even if that strategy is "don't do it, man!".
>>> IOW, can a distribution change
I think I will just state my reasoning one last time and then leave it to the
BDFL or BDFOP to make the final decision.
Victor on IRC says that there is not much difference between Decimal and
timedelta, and this may be true from an implementation point of view. From a
cognitive point of view, I
(Oops, I sent my email by mistake, here is the end of my email)
> (...) Ah, timedelta case is different. But I already replied to Nick in this
> thread about timedelta. You can also
see arguments against timedelta in the PEP 410.
Victor
___
Python-Dev
2012/2/14 Barry Warsaw :
> On Feb 13, 2012, at 07:33 PM, Victor Stinner wrote:
>
>>Oh, I forgot to mention my main concern about datetime: many functions
>>returning timestamp have an undefined starting point (an no timezone
>>information ), and so cannot be converted to datetime:
>> - time.clock()
On Feb 13, 2012, at 07:33 PM, Victor Stinner wrote:
>Oh, I forgot to mention my main concern about datetime: many functions
>returning timestamp have an undefined starting point (an no timezone
>information ), and so cannot be converted to datetime:
> - time.clock(), time.wallclock(), time.monoton
2012/2/14 Chris Withers
> On 10/02/2012 09:44, Maciej Fijalkowski wrote:
>
>> you can download the PyPy 1.8 release here:
>>
>> http://pypy.org/download.html
>>
>
> Why no Windows 64-bit build :'(
>
The win64 port was not finished. This platform is different from others
mostly because
a poin
On 10/02/2012 09:44, Maciej Fijalkowski wrote:
you can download the PyPy 1.8 release here:
http://pypy.org/download.html
Why no Windows 64-bit build :'(
Is the 32-bit build safe to use on 64-bit Windows?
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
Le 14/02/2012 08:58, Stefan Behnel a écrit :
> I'm -1 on emitting a deprecation warning just because cElementTree is being
> replaced by a bare import. That's an implementation detail, just like
> cElementTree should have been an implementation detail in the first place.
> In all currently maintain
On Mon, Feb 13, 2012 at 23:16, Nick Coghlan wrote:
> On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky wrote:
> > An open question remains on whether to deprecate cElementTree, now that
> this
> > change is in place.
> >
> > Currently in 3.3 the whole cElementTree module is:
> >
> > # Deprecated
On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
>> One other thing I'd like to see the PEP address is a possible migration
>> strategy to python->python3. Even if that strategy is "don't do it, man!".
>> IOW, can a distribution change the 'python' symlink once it's pointed to
>> python2? What
>> IMO supporting nanosecond in datetime and timedelta is an orthogonal issue.
>
> Not if you use it to cast them aside for this issue. ;)
Hum yes, I wanted to say that even if we don't keep datetime as a
supported type for time.time(), we can still patch the type to make it
support nanosecond res
FWIW, I'm with Barry on this; doing more with the datetime types seems
preferable to introducing yet more different stuff to date/time
handling.
On Mon, Feb 13, 2012 at 19:33, Victor Stinner wrote:
> Oh, I forgot to mention my main concern about datetime: many functions
> returning timestamp have
> A datetime module based approach would need to either use a mix of
> datetime.datetime() (when returning an absolute time) and
> datetime.timedelta() (when returning a time relative to an unknown
> starting point),
Returning a different type depending on the function would be
surprising and conf
On 2012-02-14, at 08:58 , Stefan Behnel wrote:
>
> These days, other Python implementations already provide the cElementTree
> module as a bare alias for ElementTree.py anyway, without emitting any
> warnings. Why should CPython be the only one that shouts at users for
> importing it?
Since all w
Nick Coghlan, 14.02.2012 05:44:
> On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote:
>> With the deprecation warning being silent, is there much to lose, though?
>
> Yes, it creates problems for anyone that deliberately converts all
> warnings to errors when running their test suites. This forc
21 matches
Mail list logo
