Alexander Belopolsky added the comment:
> You can use self._to_microseconds().
Right. Did that and added a simple test.
--
Added file: http://bugs.python.org/file38235/issue23521-2.patch
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
> the bug in C implementation should be fixed.
In the past (see #8860) we were not able to reach a consensus on which behavior
is correct and which has a bug:
>>> timedelta(seconds=1)*0.6112295
datetime.timedelta(0, 0, 611229)
>>&
Alexander Belopolsky added the comment:
I eliminated floating point arithmetics from the calculation completely and it
now matches C.
--
Added file: http://bugs.python.org/file38236/issue23521-3.patch
___
Python tracker
<http://bugs.python.
Alexander Belopolsky added the comment:
> Maybe we should also use divide_and_round for __truediv__
You mean in timedelta / float case, right? You are probably right, but can you
provide a test case in which it matters?
--
___
Python trac
Alexander Belopolsky added the comment:
>>> td = timedelta(seconds=1)
>>> print(td / (1/0.6112295))
0:00:00.611229
What is wrong with this answer? It is the same as in
>>> print(td * 0.6112295)
0:00:00.611229
--
__
Alexander Belopolsky added the comment:
I've got it:
>>> import sys
>>> sys.modules['_datetime'] = None
>>> from datetime import *
>>> td = timedelta(seconds=1)
>>> print(td / (1/0.6112295))
0:00:00.611230
--
_
Alexander Belopolsky added the comment:
Fixed truediv in issue23521-4.patch.
--
Added file: http://bugs.python.org/file38237/issue23521-4.patch
___
Python tracker
<http://bugs.python.org/issue23
Alexander Belopolsky added the comment:
Can someone provide instructions for compiling python with AddressSanitizer?
My naive attempt to run ./configure CC="clang -fsanitize=address" did not work.
--
nosy: +belopolsky
___
Python trac
Alexander Belopolsky added the comment:
I addressed review comments and fixed the case of negative divisor. There may
be a better solution than calling the function recursively, but I wanted an
easy to understand code.
--
Added file: http://bugs.python.org/file38247/issue23521-5
Alexander Belopolsky added the comment:
> You saw the demo python implementation of divmod_near in Objects/longobject.c?
I was looking for it, but could not find. Thanks for the pointer. (See also
#8817.)
In issue23521-6.patch, I've used a slightly optimized variant of divmod_near
Alexander Belopolsky added the comment:
We can further optimize _divide_and_round by changing r*=2 to r<<=1 and q % 2
== 1 to (q & 1), but this will obfuscate the algorithm and limit arguments to
ints. (As written, _divide_and_round will work with any num
Alexander Belopolsky added the comment:
> RFCs are just RFCs and not standards
RFCs have a standards track which includes steps such as "Proposed Standard",
"Draft Standard", and "Internet Standard". Once they become Internet
Standards, they get an additional
Changes by Alexander Belopolsky :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Alexander Belopolsky added the comment:
I like Akira's documentation patch. Will apply unless hear objections from
documentation folks.
--
assignee: -> belopolsky
components: +Documentation -Library (Lib)
___
Python tracke
Changes by Alexander Belopolsky :
--
stage: needs patch -> commit review
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue23521>
___
___
Py
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22752>
___
___
Python-bugs-list mailing list
Un
Changes by Alexander Belopolsky :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
Mark,
Issue #17960 ("Clarify the required behaviour of locals()") does not seem to be
relevant here. I think you meant to refer to a changeset, not issue number.
If so please use hash number such as d8
Alexander Belopolsky added the comment:
As far as I can tell, the original report was about a test failing due to a
system-dependent behavior of time.asctime(). However, since changeset
1e62a0cee092 (see issue #8013), we no longer call system asctime. I believe
the test disabled in
Alexander Belopolsky added the comment:
We still have the following in Lib/test/test_time.py:
# Issue #13312: it may return wrong value for year < TIME_MINYEAR + 1900
# Skip the value test, but check that no error is raised
self.yearstr(TIME_MINYEAR)
I reviewed
Alexander Belopolsky added the comment:
Attached patch eliminates undefined behavior, but I am not sure fixing this is
worth the trouble.
--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file38290/issue13312.patch
___
Python
Alexander Belopolsky added the comment:
Didn't Guido veto the idea of math.py?
In my opinion, isclose() is way too simple to justify refactoring.
If math.py is ever deemed to be a good idea, it should be vetted and
implemented on its own merits on not use PEP 485 as a bac
Alexander Belopolsky added the comment:
I am attaching a quick implementation of math.isclose in C. It may not cover
all corner cases correctly, but that should be easy to fix.
--
Added file: http://bugs.python.org/file38354/math-isclose.patch
Alexander Belopolsky added the comment:
> POSIX is a ``standard'' designed by a vendor consortium several years ago to
> eliminate progress and protect the installed base.
No, POSIX is an attempt to bring some sanity to the installed base of human
calendars. The established
Alexander Belopolsky added the comment:
Peter,
Can you attach your demo script to the issue? Better yet, is it possible to
explain the issue without referring to 100 lines of code?
--
___
Python tracker
<http://bugs.python.org/issue23
Alexander Belopolsky added the comment:
Serhiy,
Your latest patch LGTM.
--
stage: patch review -> commit review
type: -> behavior
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
"including Jan 30" - did you mean Dec 31?
--
___
Python tracker
<http://bugs.python.org/issue23136>
___
___
Alexander Belopolsky added the comment:
I don't think it is worth the effort to try to fix the commit message, but it
would be nice to have the NEWS text corrected.
--
___
Python tracker
<http://bugs.python.org/is
Alexander Belopolsky added the comment:
It would be nice to get this in for 3.5. Does anyone have time/interest to
address the last two comments?
--
nosy: +serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue12
Alexander Belopolsky added the comment:
Probably not.
--
___
Python tracker
<http://bugs.python.org/issue23136>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
It looks like if it was not for Raymond's mild dissent, [1], we would
have a consensus last time this was raised on python-dev, [2-7].
[1] -? Raymond Hettinger
https://mail.python.org/pipermail/python-dev/2010-December/106782.html
[2] +0 Guido van R
Alexander Belopolsky added the comment:
.. and a couple more -1's on the tracker:
msg123851 - Martin v. Löwis
msg123848 - Brett Cannon
It looks like a round on python-ideas is needed before this can move forward.
--
___
Python tracker
Alexander Belopolsky added the comment:
Python 2 line is closed for new features, but you can start with the main line
Lib/datetime.py which will probably work with python 2.7.9 after some minor
tweaks. You should be able to publish the result on PyPI. Note that many new
in 3.x modules are
Alexander Belopolsky added the comment:
I have no doubt this will get into 3.x once we have a working patch and
backward compatibility issues are addressed. Given the amount of effort Victor
has recently put in #22117 to rework CPython internal time handling to support
nanoseconds, it will
Alexander Belopolsky added the comment:
Matthieu,
I don't see you adding nanoseconds to timedelta in your patch. Doesn't this
mean that you would loose nanoseconds when you subtract one datetime from
another?
To anyone who wants to contribute to this effort, I would recommend star
Alexander Belopolsky added the comment:
>From <https://mail.python.org/pipermail/python-ideas/2015-April/033018.html>:
>>>>>>> GvR <<<<<<<<<<
I think you've found an unintended and undocumented backdoor. I admit I don't
u
Alexander Belopolsky added the comment:
> But somehow defining them with @property works (I guess because @property is
> in the class).
IMO, this is the bug and not the callable() behavior.
--
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
Mark,
Unicode C-APIs have changed a lot since this issue was opened, but I think many
of the listed functions are still present but not properly documented.
You can help by checking the Include/unicode.h file and compiling a list of
functions that are
Alexander Belopolsky added the comment:
Sorry for the broken link, the correct header file is Include/unicodeobject.h
--
___
Python tracker
<http://bugs.python.org/issue10
Alexander Belopolsky added the comment:
I am -1 on the patch. (int)PyLong_AsLong(value) can silently convert non-zero
error code to zero.
I would leave 2.7 as is and limit allowable values to a range supported by
the platform.
Note that ANSI C standard only specifies two values
Alexander Belopolsky added the comment:
The key issue here is not to report success for nonzero values.
I consider the following a bug:
$ python3
Python 3.4.2 (default, Oct 30 2014, 08:51:12)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin
Type "help", "copyr
Alexander Belopolsky added the comment:
"errors should not pass silently"
The "fix" makes the problem worse.
Why would anyone want to pass a long integer to exit?
I bet the user who discovered this problem had something like 0L or 1L coming
from a lazily
Alexander Belopolsky added the comment:
Passing anything other than one of the os.EX_* constants to sys.exit() is a bad
idea. In most cases you can get away with 0 and ±1. Anything beyond 8 bit
signed range is a gamble. Passing a computed integer value is even more
problematic. With the
New submission from Alexander Belopolsky:
$ python3
Python 3.4.3 (default, Mar 2 2015, 11:08:35)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>>
Alexander Belopolsky added the comment:
> Alexander, create a new issue for the problem of converting non-zero values
> to zero.
See #24052.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Alexander Belopolsky:
Python defines some BSDish exit codes in the os module:
EX_CANTCREAT = 73
EX_CONFIG = 78
EX_DATAERR = 65
EX_IOERR = 74
EX_NOHOST = 68
EX_NOINPUT = 66
EX_NOPERM = 77
EX_NOUSER = 67
EX_OK = 0
EX_OSERR = 71
Alexander Belopolsky added the comment:
I am attaching a patch implementing these constants. If this is well-received,
I will add documentation.
--
assignee: -> belopolsky
keywords: +easy, patch
stage: -> patch review
versions: +Python 3.5
Added file: http://bugs.pyth
Changes by Alexander Belopolsky :
--
nosy: +ethan.furman, mark.dickinson, serhiy.storchaka, terry.reedy
___
Python tracker
<http://bugs.python.org/issue24
Alexander Belopolsky added the comment:
> The value of exit returned to the parent should be status & 0377.
Apparently, this is not so on Windows. See msg241903 in #24045.
POSIX defines [1] exit to return status & 0377, but that does not mean that
sys.exit(256) must return
Changes by Alexander Belopolsky :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue24053>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
title: sys.exit(code) returns "success" to the OS for some values of code ->
sys.exit(code) returns "success" to the OS for some nonzero values of code
___
Python tracker
<http://
Alexander Belopolsky added the comment:
I agree that the truncation limits should be OS dependent and preserve the
values to the extent possible on a given platform. I just want to avoid a
situation when sys.exit(code) returns zero for a non-zero code.
BTW, what does sys.exit(2**63) return
Alexander Belopolsky added the comment:
> Where are EXIT_FAILURE and EXIT_SUCCESS defined?
In C stdlib:
$ grep EXIT_ /usr/include/stdlib.h
#define EXIT_FAILURE1
#define EXIT_SUCCESS0
> we should probably call them EX_FAILURE and EX_SUCESS to match what's already
> t
Alexander Belopolsky added the comment:
--> sys.exit(2**63)
9223372036854775808
Interesting. So it is probably not unheard of in the Windows world to use
errors codes like 1000,1001,..1024,.. to avoid conflicts with "system" codes.
Maybe on POSIX systems, sys.code(code) should p
Alexander Belopolsky added the comment:
I would say, they are there to support *humans*. I am not aware of any human
language where "success" is spelled 0. (1 is a failing mark in some schools -
so there is a precedent for that. :-)
--
Alexander Belopolsky added the comment:
> Those should be in the os module, not in sys.
I disagree. The whole point of this proposal is to have platform-independent
status codes available next to the sys.exit() function.
We already have over a dozen BSDish exit codes in os that are har
Alexander Belopolsky added the comment:
> Then precisely, those new codes should go in the os module as well.
What is your logic? Having os.EX_ codes in os does not help as far as
sys.exit() is concerned: no-one is using them and they are not available on all
platforms. If we
Alexander Belopolsky added the comment:
Ethan> all the exit codes should be in one place.
Do you realize that os.EX_* codes are not available on Windows? Having
platform-independent EXIT_* codes next to posix-only EX_* codes will send the
wrong message about their availabil
Alexander Belopolsky added the comment:
Antoine> Since I don't really get the usability argument of adding those
constants ..
If I am alone in finding exit(EXIT_FAILURE) clearer than exit(1), I should
certainly drop my proposal.
--
__
Alexander Belopolsky added the comment:
Stefan> I've seen academic code written by well-known researchers
Stefan> that used 1 for a successful exit.
Thank you! What I've seen more than once was exit(True) to indicate success
where True is not necessarily a literal, but so
Alexander Belopolsky added the comment:
> This can be implemented as separate module on PyPI.
Sure! Make them even less discoverable!
Let me try to state my motivations for adding these constants:
1. I find exit(EXIT_FAILURE) much clearer than exit(1).
2. I want people to standardize
Alexander Belopolsky added the comment:
> the convention should be between your program and the other program(s) you
> are trying communicate with.
This may be true in general, but Python stdlib sets the convention in its
subprocess.check_call and subprocess.check_output methods.
Alexander Belopolsky added the comment:
>> I want people to standardize on status=1 for a generic failure code.
> Why that? Multiple error codes can be used by the same program, depending on
> the kind of error.
Antoine, please read what I write carefully before disagreeing.
Alexander Belopolsky added the comment:
> And even GNU tools usually use multiple error codes for different kinds of
> errors.
And how often do they not give them symbolic names?
--
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
> will confuse inexperienced users when they unexpectedly encounter with
> sys.exit(sys.EXIT_FAILURE) instead of sys.exit(1).
Are you serious? I've seen senior programmers who thought that status < 0
means failure and status >= 0 me
Alexander Belopolsky added the comment:
> if you use them, your code won't work with long time
> supported CPython versions like 3.4 for the next decade or so.
This would be a generic argument against any new feature. I don't think it is
very compelling in this case. For pe
New submission from Bob Alexander:
Here is simple example of failure to parse arguments that should parse OK. In
the following little program, the second from last line contains an aargument
sequence that parses OK, but the last line should but doesn't.
import argpar
Bob Alexander added the comment:
Thanks for the note, Martin. I agree that it's a duplicate. (I had done a
brief search for possible dups, but didn't find that one!)
Bob
On Sun, May 17, 2015 at 8:29 PM, Martin Panter
wrote:
>
> Martin Panter added the comment:
>
&g
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
versions: -Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/issue2380>
___
_
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
versions: +Python 3.7 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue15390>
___
_
Changes by Alexander Belopolsky :
--
versions: +Python 3.7 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue8915>
___
___
Python-bugs-list mailin
Changes by Alexander Belopolsky :
--
versions: +Python 3.7 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue5516>
___
___
Python-bugs-list mailin
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
versions: -Python 3.5
___
Python tracker
<http://bugs.python.org/issue9398>
___
___
Python-
Changes by Alexander Belopolsky :
--
assignee: belopolsky ->
versions: +Python 3.7 -Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue
Changes by Alexander Belopolsky :
--
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue9004>
___
___
Python-bugs-list mailin
Changes by Alexander Belopolsky :
--
versions: +Python 3.7 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue10342>
___
___
Python-bugs-list mailin
New submission from Alexander Belopolsky:
POSIX localtime function mutates global state which leads to subtle bugs on
some platforms. We should call localtime_r or localtime_s instead.
See issue 22627.
--
assignee: belopolsky
messages: 275678
nosy: belopolsky
priority: normal
Alexander Belopolsky added the comment:
Superseded by #28067.
--
resolution: -> duplicate
status: open -> closed
superseder: -> Do not call localtime in datetime module
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
keywords: +patch
stage: -> commit review
Added file: http://bugs.python.org/file44537/issue28067.diff
___
Python tracker
<http://bugs.python.org/issu
Changes by Alexander Belopolsky :
--
title: Do not call localtime in datetime module -> Do not call localtime
(gmtime) in datetime module
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
> What is gmime_s?
A typo. Should be gmtime_s.
--
___
Python tracker
<http://bugs.python.org/issue28067>
___
___
Py
Changes by Alexander Belopolsky :
--
keywords: +patch
stage: needs patch -> commit review
Added file: http://bugs.python.org/file44539/issue25283.diff
___
Python tracker
<http://bugs.python.org/issu
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue27806>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Alexander Belopolsky:
After running ./configure on Linux or MacOS X, check the generated pyconfig.h
header:
$ grep TZNAME pyconfig.h
/* #undef HAVE_DECL_TZNAME */
/* #undef HAVE_TZNAME */
However, tzname exists and is declared in time.h on Linux and MacOS X as can be
seen
Changes by Alexander Belopolsky :
--
nosy: +haypo, lemburg
___
Python tracker
<http://bugs.python.org/issue28108>
___
___
Python-bugs-list mailing list
Unsub
Alexander Belopolsky added the comment:
> HAVE_TZNAME is only set iff struct tm does not have a tm_zone member ...
I've figured that much from reading the generated configure script, but thanks
for the pointer to the documentation.
--
__
Alexander Belopolsky added the comment:
The real issue is that when setting the tzname tuple in the time module, we use
a guess based on the value of tm_zone probed in June and January. I am not
sure whether this is wise. Shouldn't we just use C tzname is it is avai
Alexander Belopolsky added the comment:
> I don't think tzname is really all that useful.
I agree. More so after issue 25283 (Make tm_gmtoff and tm_zone available on all
platforms). That's why I don't see why the time module need to set tzname to
anything other than what
Changes by Alexander Belopolsky :
--
versions: +Python 3.7 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue22426>
___
___
Python-bugs-list mailin
New submission from Alexander Belopolsky:
Reported by MAL in #22798 (msg251840):
"The fact that tzset() does update the module globals is
not documented."
The documentation should explicitly list timezone, daylight, altzone and tzname
as the globals that are updated when time.
Alexander Belopolsky added the comment:
MAL> The fact that tzset() does update the module globals is
not documented.
See #28130.
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Alexander Belopolsky :
--
versions: +Python 3.7 -Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue22798>
___
___
Pytho
Alexander Belopolsky added the comment:
I ran the attached test-mktime.c program on Linux and MacOS X with the
following results (TZ=America/New_York):
$ cat test-mktime.c
#include
#include
static void
print_globals(struct tm *tm)
{
printf("%04d-%02d: %s/%s (%s) %d %ld (%
Alexander Belopolsky added the comment:
> What would be the right location for [the Windows wrappers]?
I would say Include/pytime.h:
/**
Symbols and macros to supply platform-independent interfaces to time rela
Alexander Belopolsky added the comment:
Yes, I think this is a good idea. I was hesitant to make this change while
#22798 was open because I thought we may end up exposing changes to tzname
caused by localtime and friends.
I also believe we can classify this as a bug-fix because side-effects
Alexander Belopolsky added the comment:
> we should likely introduce full wrappers that have a name starting with
> _PyTime_, right?
Yes, and I would like to give some thought to what the best API would be. The
two choices are to emulate localtime_r on Windows or emulate localtim
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
stage: -> needs patch
type: -> behavior
___
Python tracker
<http://bugs.python.or
3901 - 4000 of 4097 matches
Mail list logo
