I think I've said all I can say in this thread; I'm sure you will come
up with a satisfactory solution.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
R. David Murray writes:
> I believe that we have had several cases where Windows "crashed" when
> out-of-range values were passed to the CRT that other platforms
> accepted.
XEmacs had crashes due to strftime on Windows native with VC++. Never
went so far as to BSOD, but a couple of users los
On Thu, Jan 6, 2011 at 6:47 AM, Victor Stinner
wrote:
> Le mercredi 05 janvier 2011 à 23:48 -0500, Alexander Belopolsky a
> écrit :
>> I would be happy with just
>>
>> if accept2dyear:
>> if 69 <= y <= 99:
>> y += 1900
>> elif 0 <= y <= 68:
>> y += 2000
>>
On 01/06/2011 11:08 AM, Victor Stinner wrote:
Le jeudi 06 janvier 2011 à 10:47 -0500, R. David Murray a écrit :
On Thu, 06 Jan 2011 12:55:24 +0100, Victor
Stinner wrote:
Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
If calling specific system functions such as strf
Le jeudi 06 janvier 2011 à 10:47 -0500, R. David Murray a écrit :
> On Thu, 06 Jan 2011 12:55:24 +0100, Victor Stinner
> wrote:
> >Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
> >> If calling specific system functions such as strftime with tm_year <
> >> 0 is deemed uns
On Thu, 06 Jan 2011 12:55:24 +0100, Victor Stinner
wrote:
>Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
>> If calling specific system functions such as strftime with tm_year <
>> 0 is deemed unsafe, we can move the check to where the system function
>> is called.
>
>W
Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
> If calling specific system functions such as strftime with tm_year <
> 0 is deemed unsafe, we can move the check to where the system function
> is called.
What do you mean by "unsafe"? Does it crash? On my Linux box,
strftim
Le mercredi 05 janvier 2011 à 23:48 -0500, Alexander Belopolsky a
écrit :
> I would be happy with just
>
>if accept2dyear:
>if 69 <= y <= 99:
>y += 1900
>elif 0 <= y <= 68:
>y += 2000
># call system function with tm_year = y - 1900
Perfect. That's w
On Wed, Jan 5, 2011 at 10:50 PM, Guido van Rossum wrote:
..
> But what guarantees do we have that the system functions accept
> negative values for tm_year on all relevant platforms?
>
Also note that the subject of this thread is limited to "time.asctime
and time.ctime." The other functions came
On Wed, Jan 5, 2011 at 10:50 PM, Guido van Rossum wrote:
..
>> I propose to change that to
>>
>> if y < 1000:
>> if accept2dyear:
>> if 69 <= y <= 99:
>> y += 1900
>> elif 0 <= y <= 68:
>> y += 2000
>> else:
>> raise ValueError("year out of
On Wed, Jan 5, 2011 at 6:46 PM, Alexander Belopolsky
wrote:
> On Wed, Jan 5, 2011 at 9:18 PM, Guido van Rossum wrote:
>> I'm sorry, but at this point I'm totally confused about what you're
>> asking or proposing. You keep referring to various implementation
>> details and behaviors. Maybe if you
On Wed, Jan 5, 2011 at 9:18 PM, Guido van Rossum wrote:
> I'm sorry, but at this point I'm totally confused about what you're
> asking or proposing. You keep referring to various implementation
> details and behaviors. Maybe if you summarized how the latest
> implementation (say python 3.2) works
I'm sorry, but at this point I'm totally confused about what you're
asking or proposing. You keep referring to various implementation
details and behaviors. Maybe if you summarized how the latest
implementation (say python 3.2) works and what you propose to change
that would be quicker than this ba
On Wed, Jan 5, 2011 at 6:12 PM, Guido van Rossum wrote:
..
> If they both impose some arbitrary limits, it would be easier for
> users to remember the limits if they were the same for both modules.
>
Unfortunately, that is not possible on 32-bit systems where range
supported by say time.ctime() is
On Wed, Jan 5, 2011 at 2:55 PM, Alexander Belopolsky
wrote:
> On Wed, Jan 5, 2011 at 4:33 PM, Guido van Rossum wrote:
> ..
>>> Why >= 1?
>>
>> Because that's what the datetime module accepts.
>
> What the datetime module accepts is irrelevant here.
Not completely -- they are both about dates and
On Wed, Jan 5, 2011 at 4:33 PM, Guido van Rossum wrote:
..
>> Why >= 1?
>
> Because that's what the datetime module accepts.
What the datetime module accepts is irrelevant here. Note that
functions affected by accept2dyear are: time.mktime(), time.asctime(),
time.strftime() and indirectly time.c
On Jan 5, 2011, at 4:33 PM, Guido van Rossum wrote:
> Shouldn't the logic be to take the current year into account? By the
> time 2070 comes around, I'd expect "70" to refer to 2070, not to 1970.
> In fact, I'd expect it to refer to 2070 long before 2070 comes around.
>
> All of which makes me t
On Wed, Jan 5, 2011 at 12:58 PM, Alexander Belopolsky
wrote:
> On Wed, Jan 5, 2011 at 2:19 PM, Guido van Rossum wrote:
> ..
>>> extending accepted range is a borderline case IMO.
>>
>> I like accepting all years >= 1 when accept2dyear is False.
>>
>
> Why >= 1?
Because that's what the datetime m
On Wed, Jan 5, 2011 at 2:19 PM, Guido van Rossum wrote:
..
>> extending accepted range is a borderline case IMO.
>
> I like accepting all years >= 1 when accept2dyear is False.
>
Why >= 1? Shouldn't it be >= 1900 - maxint? Also, what is your take
on always accepting [1000 - 1899]?
Now, to play
On Wed, Jan 5, 2011 at 10:12 AM, Alexander Belopolsky
wrote:
> On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou wrote:
> ..
>> Couldn't we deprecate and remove time.accept2dyear? It has been there
>> for "backward compatibility" since Python 1.5.2.
>>
>
> It will be useful for another 50 years or
On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou wrote:
..
> Couldn't we deprecate and remove time.accept2dyear? It has been there
> for "backward compatibility" since Python 1.5.2.
>
It will be useful for another 50 years or so. (POSIX 2-digit years
cover 1969 - 2068.) In any case, this is not
On Wed, 5 Jan 2011 12:33:55 -0500
Alexander Belopolsky wrote:
> On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum wrote:
> > Given the rule garbage in -> garbage out, I'd do the most useful
> > thing, which would be to produce a longer output string (and update
> > the docs). This would match the
On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum wrote:
> Given the rule garbage in -> garbage out, I'd do the most useful
> thing, which would be to produce a longer output string (and update
> the docs). This would match the behavior of e.g. '%04d' % y when y >
> . If that means the platform
On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum wrote:
> Given the rule garbage in -> garbage out, I'd do the most useful
> thing, which would be to produce a longer output string (and update
> the docs).
I did not know that GIGO was a design rule, but after thinking about
it some more, I agree.
Given the rule garbage in -> garbage out, I'd do the most useful
thing, which would be to produce a longer output string (and update
the docs). This would match the behavior of e.g. '%04d' % y when y >
. If that means the platform libc asctime/ctime can't be used, too
bad.
--Guido
On Mon, Jan
25 matches
Mail list logo
