Utkarsh Upadhyay <musically...@gmail.com> added the comment:
:)
There's still a lot of room for improvement on documentation front, esp. the
inline __doc__s. I'll be working on that next.
~
ut
--
___
Python tracker <rep...@bugs.python.or
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
keywords: +patch
pull_requests: +3676
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
keywords: +patch
pull_requests: +3677
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Utkarsh Upadhyay:
There are some instances in the documentation of datetime where the repr of
timedelta is mentioned, which was changed in bpo-30302.
Am making a PR shortly to address them.
--
assignee: docs@python
components: Documentation
messages: 302700
nosy
Utkarsh Upadhyay added the comment:
Thanks for the merge haypo! \o/
I've also created a PR for adding an entry to 'Porting to Python 3.7' in the
documentation; I see no harm in including it in the documentation just-in-case.
--
___
Python tracker
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +2981
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Utkarsh Upadhyay added the comment:
Thanks Victor! \o/
Secretly, I'm just happy that my legacy will not be a commit which broke all
(?) the build-bots and had to be reverted. :P
W.r.t. the docs; in retrospect, that'll probably have a larger impact on the
end-users and is less likely to cause
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +2943
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Utkarsh Upadhyay:
Due to a rebase artifact (sorry!), the tests for the datetime module are being
run twice:
test_datetime.py:
[...]
cls.tearDownClass = tearDownClass
all_test_classes.extend(test_classes)
all_test_classes.extend(test_classes)
def test_main
Utkarsh Upadhyay added the comment:
@Matheus: What other languages support this? Is this (i.e. defaulting to
Sunday, or Monday?) the default behavior there?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +2868
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +2867
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +2834
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Utkarsh Upadhyay added the comment:
So it seems that running the experiments without `-utzdata` would be an
acceptable fix (assuming that there are no other interesting time-zones worthy
of explicit testing)?
Can I help in the resolution of this issue, since resolution of
http
Utkarsh Upadhyay added the comment:
Bump!
> >>> time.gmtime(1121871596)[:]
> (2005, 7, 20, 14, 59, 56, 2, 201, 0)
I wouldn't mind implementing `__getitem__` for timedeltas, such that this
becomes possible:
>> (D.fromtimestamp(1390953543.1) - D.fromtimestamp(1121871
Utkarsh Upadhyay added the comment:
This case is explicitly mentioned in the documentation:
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior
> 7. When used with the strptime() method, %U and %W are only used in
> calculations when the day of th
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +2621
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +2620
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Utkarsh Upadhyay added the comment:
Hmm, I don't know if testing every zone is necessary. However, I would not be
comfortable picking out the zones one ought to test, considering:
if ('Riyadh8' in self.zonename or
# From tzdata NEWS file:
# The files solar87
Utkarsh Upadhyay added the comment:
> [...] the extra information may be helpful the first time you see it, but if
> you deal with timedeltas a lot, it would quickly become annoying.
It seems from the discussion on the issue that there are two kinds of
developers:
- One group whic
Utkarsh Upadhyay added the comment:
Previously, test_datetime was running only `_Fast` tests (i.e. testing the C
module). Then (because of an erring commit from me), testing for `_Pure`
implementation started but all tests per time-zone started running thrice
instead of once. Hence
Utkarsh Upadhyay added the comment:
Hmm, I see; I did not know that.
I had just assumed that `./python -m test test_*` was the standard command for
running tests.
However, if one does run tests using standalone `datetimetester` (which only
imports the _Fast C extension module), then I'll
Utkarsh Upadhyay added the comment:
So the problem is occurring because a single `Test` class is being instantiated
with three different tests here in datetimetester.py:
for name in ZoneInfo.zonenames():
Test = type('ZoneInfoTest[%s]' % name, (ZoneInfoTest
Utkarsh Upadhyay added the comment:
I can reproduce the names with `_Pure_Pure_Pure` if I run the tests with
`-utzdata`. Investigating.
~
ut
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Utkarsh Upadhyay added the comment:
Are there any guides re: backporting commits?
Just to confirm verify that I'm going about it right; I’m planning on
cherry-picking relevant commits back to branch 3.5, 3.6, resolving the merge
conflicts, and then opening two separate PRs for them with `bpo
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +2597
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Utkarsh Upadhyay:
While investigating http://bugs.python.org/issue30302 it was discovered that
the Python implementation of the datetime module was not being tested correctly.
The datetimetester.py was supposed to execute tests twice, once for the _Fast
implementation (i.e
Utkarsh Upadhyay added the comment:
So, as a compromise, I'll stick to PyObjects (avoiding char* and the buffer
size calculations) but will use PyUnicode all the way instead using PyList_*
functions (thus reducing the size of the code by ~20 lines).
I've pushed this change, ready for review
Utkarsh Upadhyay added the comment:
The docstring changes ought to be easier to review since I'll only be making
the Python and C docstrings mostly identical (with some minor changes here and
there). I'll also (hopefully) need fewer pointers now that I've been through
one review process
Utkarsh Upadhyay added the comment:
@r.david.murray: I'm primarily waiting for Serhiy (and, optionally Martin) to
"Okay" the pull request.
The code seems fine (@haypo has had a through look at it), but we still were
mildly divided over whether we want to factor out the neg
Utkarsh Upadhyay added the comment:
I went through the e-mail chain discussing the changes in repr again and I have
come around to seeing that though Guido was somewhat opposed to the idea of
factoring out the minus sign because it would have meant changing the
attributes [1], what he really
Utkarsh Upadhyay added the comment:
@haypo: thanks for the input!
I will find datetime.timedelta() to be rather confusing because it does not
explicitly tell me that the interval indeed is 0.
Between datetime.timedelta(0) and datetime.timedelta(seconds=0), I am
ambivalent but I prefer
Utkarsh Upadhyay added the comment:
I've added the following tests to remove the 0 attributes from the repr:
self.assertEqual(repr(self.theclass(days=1, seconds=0)),
"%s(days=1)" % name)
self.assertEqual(repr(self.theclass(
Utkarsh Upadhyay added the comment:
So we are okay with
datetime.timedelta(minutes=-1)
# -datetime.timedelta(seconds=60)
and
datetime.timedelta(minutes=-1).seconds
# 86340
datetime.timedelta(minutes=-1).days
# -1
?
Perhaps I'm reading this incorrectly:
"If the repr() shows diff
Utkarsh Upadhyay added the comment:
> This was discussed fairly recently:
> <https://marc.info/?i=captjjmrbxpvyquyxshbc1j13m_h5or67cnbkrkysw4ef6rq...@mail.gmail.com>
That thread went deep and culminated here, as far as I can tell:
https://marc.info/?l=python-dev=145077422417
Utkarsh Upadhyay added the comment:
> The drawback is that this change increases the length of the repr.
I would argue that it is a reasonable trade-off given the increase in ease of
understanding.
I know that this is a weak argument, but, keywords are not without precedent.
Consi
Changes by Utkarsh Upadhyay <musically...@gmail.com>:
--
pull_requests: +1595
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Utkarsh Upadhyay:
Currently, the default implementation of datetime.datetime.__repr__ (the
default output string produced at the console/IPython) gives a rather cryptic
output:
from datetime import datetime as D
D.fromtimestamp(1390953543.1) - D.fromtimestamp(1121871596
New submission from Utkarsh Upadhyay:
The JSON parser currently throws exceptions which contain information about
where the error happened but this information is encoded in a string and not
available to the programmer. This leads to issues like this:
http://stackoverflow.com/questions
Utkarsh Upadhyay added the comment:
Excellent!
Is there an issue for merging Simplejson into stdlib?
If so, can this issue be linked to that issue?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19361
40 matches
Mail list logo
