Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
The better is the enemy of the good here. Given the history of this issue, I
would rather accept a well documented restrictive parser than wait for a more
general code to be written. Note that we can always
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
Isn't this a duplicate of issue 13305?
--
status: pending -> open
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
> The documentation only says “datetime.timestamp” calls “mktime”
Indeed. See
<https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp>.
This is a documentation bug. Since 3.6 the
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
I am not sure. This is a system bug and we often provide work-arounds
or even reimplementations of buggy time functions in the time and
datetime modules. Whether or not this is something that is worth
fixing is a qu
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
I posted a wrong command, but fortunately I am in New York, so it did not matter
$ TZ=EST+05EDT,M3.2.0,M11.1.0 python -c 'import
time;print(time.localtime(14400)[:])'
(1969, 12, 31, 23, 0, 0, 2,
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
I hate this long form display!
Next time please use time.localtime(14400)[:].
Do you agree that this is a system bug? On my Mac, I get
$ python -c 'import time; print(time.localtime(14400)[:])'
(1969, 12, 31, 23
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
I don't have access to NetBSD and this looks like a bug in the system
implementation of localtime. The timestamp method is implemented by probing
system localtime in the vicinity of UTC timestamp.
Wha
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
Brian, is this still relevant? If so, cab you submit a pull request?
--
versions: +Python 3.7 -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
New changeset 66c88ce30ca2b23daa37038e1a3c0de98f241f50 by Alexander Belopolsky
in branch 'master':
Closes bpo-28281: Remove year (1-) limits on the weekday() function. (#4109)
https://github.com/python/cpython/
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
New changeset 32318930da70ff03320ec50813b843e7db6fbc2e by Alexander Belopolsky
(Mario Corchero) in branch 'master':
Closes bpo-31800: Support for colon when parsing time offsets (#4015)
https://github.com/python/c
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
I am going to merge PR 4015 submitted for issue 31800. That issue asks to make
%z strptime format accept offsets with : separators. Given that a similar
feature has been added to glibc several years ago, I don
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
I would like to add my voice to MAL's objections. I was not aware of
time.clock() depreciation before Victor brought this issue to my attention.
time.clock() is a very well-known API eponymous to a venerable UNIX
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
I submitted Mark's patch unchanged as PR 4109. If we don't hear from Mark, I
will address my own comments and merge.
--
___
Python tracker <rep...@bugs.python.or
Change by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
pull_requests: +4079
stage: commit review -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
New changeset fdd9b217c60b454ac6a82f02c8b0b551caeac88b by Alexander Belopolsky
in branch 'master':
Closes bpo-28292: Implemented Calendar.itermonthdays3() and itermonthdays4().
(#4079)
https://github.com/python/c
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
Note that #5288 relaxed the whole number of minutes restriction on UTC offsets.
Since the goal is to be able to parse the output of .isoformat(), I think %z
should accept sub-minute offsets.
--
nosy: +belo
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
I submitted PR 4079. Serhiy, please review the logic and if this matches what
we discussed a year ago, I will add the docs and NEWS entries.
--
___
Python tracke
Change by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
keywords: +patch
pull_requests: +4049
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
> 1. Raise OverflowError at both ends (revert issue15421patch). The method
> becomes unusable for two extreme months.
The issue 15421 patch was committed in 85710a40e7e9eab86060bedc3762
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
Let me look into this. It's been a while ...
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
Is this similar to issue 29097?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Alexander Belopolsky added the comment:
> It still seems like this shouldn't give an error (especially when the
> timezone of the local machine is UTC)
This is the part where I agree with you. I suspect the error in the UTC case
is an artifact of PEP 495 fold calculations that r
Alexander Belopolsky added the comment:
BTW, I was originally against introducing .timestamp() method and this issue
illustrates why it is problematic: people use it without understanding what it
does. If you want the distance between datetime.min and datetime(1970,1,1) in
seconds - compute
Alexander Belopolsky added the comment:
It your use case, the input "0001-01-01T00:00:00" was in what timezone?
I suspect what you want is
>>> datetime.min.replace(tzinfo=timezone.utc).timestamp()
-62135596800.0
And not -62135658000.0. If you work with naive date
Alexander Belopolsky added the comment:
On the second thought, a reasonable design can use datetime.min/max as
placeholders for unknown times far in the past/future compensating for the lack
datetime ±inf. In this use case, it may be annoying to see errors from
timestamp() instead of some
Alexander Belopolsky added the comment:
The question is whether -62135658000.0 is the "correct" or even meaningful
value:
>>> datetime.utcfromtimestamp(-62135658000.0)
Traceback (most recent call last):
File "", line 1, in
ValueError: year is out of range
(
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
resolution: -> fixed
stage: test needed -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://b
Alexander Belopolsky added the comment:
New changeset 018d353c1c8c87767d2335cd884017c2ce12e045 by Alexander Belopolsky
in branch 'master':
Closes issue bpo-5288: Allow tzinfo objects with sub-minute offsets. (#2896)
https://github.com/python/cpython/commit
Alexander Belopolsky added the comment:
> My concern is that it makes timestamp parsing more complex
To the contrary. The timezone field can now be parsed the same way as the time
field plus the sign.
--
___
Python tracker <rep...@bugs.pyth
Alexander Belopolsky added the comment:
Victor,
Tim called for removal of all restrictions on the offsets. See msg248468. I
left the range restriction intact because we have some algorithms that rely on
that, but in general I agree with Tim. There is nothing to be gained from
restricting
Alexander Belopolsky added the comment:
John,
An RFC3339 parser is beyond the scope of this issue which is limited to adding
str[fp]time code(s) to produce and consume RFC3339-formatted timezones.
We can still have fromisoformat() constructor implemented in 3.7, but someone
needs to address
Alexander Belopolsky added the comment:
In PR 2896, I've modified %z formatting code to output sub-minute data if
present. I think %z parsing should be also modified to accept sub-minute data,
but I would like to do it in the context of issue 24954. Thoughts
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
assignee: -> belopolsky
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Alexander Belopolsky added the comment:
Most of the code supporting arbitrary offsets has already been committed. The
only part left was to remove the checks and implement printing.
--
___
Python tracker <rep...@bugs.python.org>
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
pull_requests: +2949
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
priority: low ->
versions: +Python 3.7 -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
nosy: +gvanrossum
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
Alexander Belopolsky added the comment:
This issue is waiting for the final decision on #5288. If sub-minute offsets
support is accepted, I still don't think we need %::z because %:z can simply
add non-zero :seconds as needed. There are also some review comments on the
latest patch
Alexander Belopolsky added the comment:
I agree. The documentation can be improved here. The note about x - y not
being quite the same as x + (-y) belongs to the timedelta - timedelta
operation. It should be removed from both date - timedelta and
datetime-timedelta footnotes
Alexander Belopolsky added the comment:
> Why is it so slow?
The tests enabled by "-utzdata" check UTC to local and back conversions at
several points around *every* time transition in *every* timezone. On systems
with a complete installation of IANA tzdata, this is a lot o
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
nosy: +tim.peters
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Alexander Belopolsky added the comment:
Sorry for being late to the discussion, but please allow me to add a -1 vote.
The time.struct_time precedent is indeed comically verbose. Whenever I need to
inspect a struct_time, I cast it to a plain tuple
Compare
>>> time.gmtime(1
Alexander Belopolsky added the comment:
> I just ran the following script to check if there are any folds from
> timestamps [0, 86399] in any timezone.
Ammar, I am not sure pytz timezones support PEP 495 conventions. Can you repeat
your experiment using the latest dateu
Alexander Belopolsky added the comment:
The current behavior is intentional. Please see PEP 495 for details.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
keywords: -3.2regression
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Alexander Belopolsky added the comment:
> The datetime module ..
Yes, the datetime module documentation can be improved, but let's keep this
issue focused on the time module. Please open a new issue for the datetime
module improveme
Alexander Belopolsky added the comment:
Cheryl,
There is no need to apologize. I assigned this issue to myself when I created
it because I had a few ideas about refactoring the time module documentation
and thought I would get to it soon. As often happens other priorities
interfered
Alexander Belopolsky added the comment:
A question for Victor: Should we split the "Constants" section into "Clock ID
constants" and "Timezone constants"? (See PR 928.)
--
___
Python tracker <rep...@bugs.py
Alexander Belopolsky added the comment:
The time and math modules are probably the oldest Python modules, but math have
seen more development recently, so it should serve as a good model for how
things should be organized. Yes, I believe re-listing module functions and
constants
Alexander Belopolsky added the comment:
> This is because math.e is not the same as e.
Right. That's why I think it would be nice to distinguish math.e and the base
of the natural logarithm typographically in the docs. Can we use sphinx math
mode? If not, I would use ita
New submission from Alexander Belopolsky:
The math.exp(x) function is documented to "Return e**x"
<https://docs.python.org/3/library/math.html#math.exp>. This is misleading
because even in the simplest case, math.exp(x) is not the same as math.e ** x:
>>> import math
Alexander Belopolsky added the comment:
New changeset 661ca8843fed1183e38db06e52d59ac300bf1c2a by Lev Abalkin in branch
'master':
Fixes bpo-29680: Older gdb does not have gdb.error. (#363)
https://github.com/python/cpython/commit/661ca8843fed1183e38db06e52d59ac300bf1c2a
Alexander Belopolsky added the comment:
@xiang.zhang - I am the OP for this issue, so naturally I expect this to be
fixed. I have a work-around in place for my own code, so I have no opinion on
the particular versions. I guess the normal policy on bug fixes should apply
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
resolution: -> rejected
stage: patch review -> resolved
status: pending -> closed
___
Python tracker <rep...@bugs.python.org>
<http://b
Alexander Belopolsky added the comment:
Victor, the gdb commit that you mentioned introduced gdb.GdbError which is
different from gdb.error. [1] The correct commit is
621c83642d17cf523c20f55f2ed945a7ec95ea6a. [2]
[1]
https://sourceware.org/gdb/current/onlinedocs/gdb/Exception-Handling.html
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
components: +Demos and Tools
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
pull_requests: +308, 309
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
pull_requests: +308
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
nosy: +haypo
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Alexander Belopolsky:
Printing the backtrace in gdb results in Python errors:
(gdb) bt
...
#6 0x77ba9745 in _PyEval_EvalCodeWithName (_co=, globals=Traceback (most recent call last):
File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 1358, in
Alexander Belopolsky added the comment:
I tried to simply replace _PyUnicode_AsString with PyUnicode_AsUTF8, but it
looks like code structure has changed and the pyframe and pystack macros don't
work anymore.
--
___
Python tracker <
New submission from Alexander Belopolsky:
Some gdb macros defined in Misc/gdbinit got broken when _PyUnicode_AsString was
renamed to PyUnicode_AsUTF8.
(gdb) pystack
No symbol "_PyUnicode_AsString" in current context.
--
messages: 288684
nosy: belopolsky
priority: norma
New submission from Alexander Belopolsky:
I had it done in my fork of cpython-mirror:
https://github.com/abalkin/cpython/tree/ci
--
assignee: belopolsky
components: Tests
messages: 287710
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Add c code coverage
Alexander Belopolsky added the comment:
This looks like a duplicate of issue #29100 ("datetime.fromtimestamp() doesn't
check min/max year anymore: regression of Python 3.6").
--
keywords: +3.6regression
nosy: +haypo
___
Python tr
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
status: closed -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Alexander Belopolsky added the comment:
Committed in ec3b08b361c0. Thanks, Greg.
Leaving open until 2.7 docs are fixed as well.
--
resolution: -> fixed
stage: -> resolved
versions: +Python 2.7 -Python 3.6
___
Python tracke
Alexander Belopolsky added the comment:
On the other hand, the documentation for the bytearray constructor [1] lists
integer argument first.
[1]: https://docs.python.org/3/library/functions.html#bytearray
--
___
Python tracker <
Alexander Belopolsky added the comment:
@inada.naoki
Sorry, I still don't understand the role of OverflowError.
With respect to my earlier suggestion that buffer protocol should have priority
over __index__, note that the documentation implies the same order:
>>> help(bytes)
cl
Alexander Belopolsky added the comment:
Inada,
Can you explain what your patch does? I don't understand why you single out
the OverflowError. When is __index__ expected to raise it?
>>> (2**300).
Alexander Belopolsky added the comment:
Also relevant:
* #20895 - Add bytes.empty_buffer and deprecate bytes(17) for the same purpose
* PEP 467 - Minor API improvements for binary sequences
--
___
Python tracker <rep...@bugs.python.org>
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Alexander Belopolsky added the comment:
I don't think we should put too much effort into preserving numpy behavior.
Consider this python 3.5 session:
>>> import numpy
>>> a = numpy.array([1])
>>> bytes(a)
__main__:1: VisibleDeprecationWarning: converting an array
Alexander Belopolsky added the comment:
My test code may seem contrived, but numpy arrays exhibit similar behavior:
>>> a = numpy.array([2, 2])
>>> bytes(a)
Traceback (most recent call last):
File "", line 1, in
TypeError: only integer arrays with one element
New submission from Alexander Belopolsky:
Consider the following code:
$ cat bug.py
from array import array
class C(array):
def __new__(cls):
return array.__new__(cls, 'B', b'abc')
def __index__(self):
raise TypeError
x = C()
print(bytes(x))
It works under python 3.5
Alexander Belopolsky added the comment:
I think we should just clip the negative lower probe value to 0 on Windows
before passing it to local(). Also, if we still care about platforms with
32-bit time_t, we should check for over/under flow *before* calling local
New submission from Alexander Belopolsky:
Python 3.7.0a0 (default:be70d64bbf88, Dec 1 2016, 21:21:25)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Alexander Belopolsky added the comment:
It looks like Serhiy has already committed it. Thanks!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Alexander Belopolsky added the comment:
> If you can push this in the next hour or two ...
I'll do it now.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Alexander Belopolsky added the comment:
The patch LGTM. I'll commit it tonight unless Serhiy beats me to it.
--
nosy: +alexandre.vassalotti, haypo, tim.peters
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
assignee: -> belopolsky
stage: patch review -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Alexander Belopolsky added the comment:
> On Nov 20, 2016, at 12:34 PM, Serhiy Storchaka <rep...@bugs.python.org> wrote:
>
> The only way is to define both __reduce_ex__ and __reduce__ for time and
> datewtime.
OK. I'll review your patch and get it
Alexander Belopolsky added the comment:
> On Nov 20, 2016, at 11:10 AM, Serhiy Storchaka <rep...@bugs.python.org> wrote:
>
> Other way is to define __reduce_ex__ instead of __reduce__ in datetime.date.
I would prefer this solution.
--
___
Alexander Belopolsky added the comment:
Keeping localtime as a convenience function in email.util is fine, but isdst
argument should be eliminated at some point. There is a fundamental problem
with disambiguating fold times with isdst: some folds do not involve the change
in dst or happen
Alexander Belopolsky added the comment:
> On Nov 18, 2016, at 8:49 AM, Serhiy Storchaka <rep...@bugs.python.org> wrote:
>
> But there are two drawbacks.
It is not too late to make improvements. If you have specific proposals -
please bring them up on t
Alexander Belopolsky added the comment:
> On Nov 18, 2016, at 7:04 AM, Serhiy Storchaka <rep...@bugs.python.org> wrote:
>
> Yet one doubtful detail is that the fold bit is added to the hour bit in
> datetime.time, but to the month field in datetime.datetime.
The reason
Alexander Belopolsky added the comment:
I spotted a small typo in the "PEP 495: Local Time Disambiguation" section:
"The values of the fold attribute have the value 0 all instances ..." should be
"The values of the fold attribute have the value 0 *for* all instan
Alexander Belopolsky added the comment:
Paul (p-ganssle), based on your recent experience implementing PEP 495, what
are the main points that we should cover in What's New? Also, any
comments/criticism on the recent changes to the datetime module documentation
are welcome
New submission from Alexander Belopolsky:
See also #27595.
--
assignee: belopolsky
components: Documentation
messages: 280320
nosy: belopolsky, p-ganssle, tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: Describe PEP 495 features in "What'
Alexander Belopolsky added the comment:
> I can't think of a single actual downside to this change - all it does is
> preserve the original behavior of `fromutc()`.
You've got me on the fence here. If what you are saying is correct, it would
make sense to make this change and bet
Alexander Belopolsky added the comment:
Paul G at Github:
"""
To be clear, I'm just saying that fromutc() goes from returning something
meaningful (the correct date and time, with no indication of what side of the
fold it's on) to something useless (an incorrect date and ti
Alexander Belopolsky added the comment:
I don't think timezones that satisfy the invariant expected by the default
fromutc() is common enough that we need to provide special support for them.
Note that in most cases it is the UTC to local conversion that is
straightforward while Local
Alexander Belopolsky added the comment:
See Datetime-SIG thread
<https://mail.python.org/pipermail/datetime-sig/2016-November/001010.html>.
--
assignee: -> belopolsky
nosy: +tim.peters
stage: -> needs patch
___
Python
Alexander Belopolsky added the comment:
Never mind the second question.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
Shouldn't "time part" underlined in my previous note be "date part" instead?
Also, does non-zero mean non-empty?
--
___
Python tracker <rep...@bugs.python.org>
<http:/
Alexander Belopolsky added the comment:
The patch should include an update to documentation.
1. We should probably explain that python -mcalendar does not reproduce the
output of UNIX cal. For example, on Mac OS (and various Linux variants):
$ cal 9 1752
September 1752
Su Mo Tu We Th Fr
Changes by Alexander Belopolsky <alexander.belopol...@gmail.com>:
--
assignee: docs@python -> belopolsky
stage: patch review -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs
Alexander Belopolsky added the comment:
None is passed to tzinfo.dst() when it is called from time.dst() method. This
is documented in the relevant section:
<https://docs.python.org/3.5/library/datetime.html#datetime.time.dst>.
I am not sure whether if it is worth repeating in the ab
Alexander Belopolsky added the comment:
This makes sense. Note that this is the way hashes are implemented for the
datetime objects:
<https://hg.python.org/cpython/file/v3.6.0b1/Lib/datetime.py#l635>.
--
nosy: +belopolsky
___
Python tracke
101 - 200 of 3523 matches
Mail list logo
