Re: Pickle file and send via socket
On Wednesday, August 8, 2012 at 8:37:33 PM UTC+5:30, lipska the kat wrote:
> On 08/08/12 14:50, S.B wrote:
> > On Wednesday, August 8, 2012 3:48:43 PM UTC+3, lipska the kat wrote:
> >> On 06/08/12 14:32, S.B wrote:
> >>
> [snip]
> > Thank you so much !
> > The examples are very helpful.
> > What happens if I have a regular text file I want to send via the network.
> > Do I need to read the file and then dump it into the "stargate" file object?
> Well according to the documentation at
>
> http://docs.python.org/py3k/tutorial/inputoutput.html#reading-and-writing-files
>
>
> it should be straightforward to read and write pickled files
> Not sure why you want to pickle a text file over the network when you
> could just stream it between ports !
>
> however ...
>
> I'm currently getting a Unicode decode error on the first byte in the
> stream when it gets to the other end, no idea why so I guess I have to
> continue searching, read the documentation above and see if you can
> figure it out, that's what I'm doing.
> lipska
>
> --
> Lipska the Kat: Troll hunter, sandbox destroyer
> and farscape dreamer of Aeryn Sun
Directly read bytes from file and send it over the socket object from client
side in while loop until all content from file is read.
Something like this.
Client side
import socket
s = socket.socket()
PORT = 9898
s.connect(("192.168.0.101",PORT))
file = open("turnover.csv","rb")
SendData = file.read(1024)
while SendData:
s.send(SendData)
SendData = file.read(1024)
s.close()
Server side
import socket
s = socket.socket()
PORT =9898
print("Server is listening on port :",PORT,"\n")
s.bind(("192.168.0.101",PORT))
s.listen(10)
file = open("recv.csv","wb")
print("\n Copied file name will be recv.txt at server side\n")
while True:
conn,addr = s.accept()
RecvData = conn.recv(1024)
while RecvData:
file.write(RecvData)
RecvData = conn.recv(1024)
file.close()
print("\n File has been copied successfully \n")
conn.close()
print("\n Server is closing the connection \n")
break
--
https://mail.python.org/mailman/listinfo/python-list
[issue41115] Codecs should raise precise UnicodeDecodeError or UnicodeEncodeError
utkarsh added the comment: @thatiparthy These were the most logical changes, standard error messages, which were already there in the existing code, I just edited them as mentioned here. What part of your "work" do you think i copied? Sent this PR to get familiar to the process mostly, i will close it if you feel insecure. No need to be rude. thanks. -- ___ Python tracker <https://bugs.python.org/issue41115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41115] Codecs should raise precise UnicodeDecodeError or UnicodeEncodeError
Change by utkarsh : -- nosy: +utk nosy_count: 8.0 -> 9.0 pull_requests: +20329 pull_request: https://github.com/python/cpython/pull/21170 ___ Python tracker <https://bugs.python.org/issue41115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36008] [good first issue] Update documentation for 3.8
Utkarsh Gupta added the comment: Sure, but ultimately (soon enough) it is going to happen, no? -- ___ Python tracker <https://bugs.python.org/issue36008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35329] Documentation - capitalization issue
Utkarsh Gupta added the comment: Hey, I'd be happy to submit one :) -- nosy: +utkarsh2102 ___ Python tracker <https://bugs.python.org/issue35329> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35329] Documentation - capitalization issue
Change by Utkarsh Gupta : -- keywords: +patch pull_requests: +12929 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue35329> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36008] [good first issue] Update documentation for 3.8
Change by Utkarsh Gupta : -- keywords: +patch pull_requests: +12813 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue36008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36008] [good first issue] Update documentation for 3.8
Utkarsh Gupta added the comment: Hey, I am a new contributor, looking for an issue to start with. Since this is a "good first issue", I wanted to know if I could take it? I am myself at a dev sprint and would like to get it fixed :) Mariatta, let me know if you have any problems with the same? -- nosy: +utkarsh2102 ___ Python tracker <https://bugs.python.org/issue36008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35297] untokenize documentation is not correct
Utkarsh Gupta added the comment: I am not sure if that's a documentation problem, is it? If so, I'll be happy to send a PR :) -- nosy: +utkarsh2102 ___ Python tracker <https://bugs.python.org/issue35297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30951] Documentation error in inspect module
Utkarsh Gupta added the comment: Serhiy: What change d'you possibly suggest then? -- ___ Python tracker <https://bugs.python.org/issue30951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30951] Documentation error in inspect module
Change by Utkarsh Gupta : -- nosy: +utkarsh2102 ___ Python tracker <https://bugs.python.org/issue30951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30951] Documentation error in inspect module
Change by Utkarsh Gupta : -- keywords: +patch pull_requests: +9921 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue30951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31545] Fixing documentation for timedelta.
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.org> <https://bugs.python.org/issue31545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31545] Fixing documentation for timedelta.
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- keywords: +patch pull_requests: +3676 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- keywords: +patch pull_requests: +3677 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31545] Fixing documentation for timedelta.
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: docs@python, musically_ut priority: normal severity: normal status: open title: Fixing documentation for timedelta. versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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 <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +2981 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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 disagreement. I probably should have led with that. :) ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31043] Tests running twice.
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +2943 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31043] Tests running twice.
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(): run_unittest(*all_test_classes) [...] Fix coming shortly. -- components: Tests messages: 299218 nosy: musically_ut priority: normal severity: normal status: open title: Tests running twice. type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30802] datetime.datetime.strptime('200722', '%Y%U')
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/issue30802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +2868 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +2867 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +2834 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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://bugs.python.org/issue30302 is tangentially conditioned on it. (-: -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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(1121871596))[:] (3114, 28747, 10) (Though, TBH, it does feel a little weird that `time.struct_time` allows indexing). ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30802] datetime.datetime.strptime('200722', '%Y%U')
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 the week and the calendar year (%Y) are > specified. The documentation also says that the %u (day of the week) format specifier was added only in Python 3.6. ~ ut -- nosy: +musically_ut ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +2621 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +2620 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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, solar88, and solar89 are no longer distributed.
# They were a negative experiment - that is, a demonstration that
# tz data can represent solar time only with some difficulty and
error.
# Their presence in the distribution caused confusion, as Riyadh
# civil time was generally not solar time in those years.
self.zonename.startswith('right/')):
and:
> # Iran had a sub-minute UTC offset before 1946.
in
https://github.com/python/cpython/blob/master/Lib/test/datetimetester.py#L4865
Perhaps @belopolsky can suggest something? (Already in Nosy List).
~
ut
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30822>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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 which uses timedeltas so often that they will find it annoying if the repr was longer, which takes up more screen space. - The other group which occasionally uses timedelta but may forget what the arguments stood for. I suspect that the distribution of programmers who use timedeltas binned by their frequency of usage will follow the Pareto principle: only 20% of the developers will account for 80% of uses of timedelta, and the remaining 80% of the developers will use it the remaining 20% of the time. Out of those 80% developers who use it sparingly, some fraction will find the repr with the keywords more informative than the current version and be a tiny bit happier. I personally belong to the second group of developers. IMHO, Guido too may belong the second group https://marc.info/?l=python-dev=145066335824146=2 : > Well it would have saved me an embarrassing moment -- I typed > `datetime.timedelta(seconds=1e6)` at the command prompt and when the response > came as `datetime.timedelta(11, 49600)` I mistook that as 11 years (I was in > a hurry and trying hard not to have to think :-). @haypo: in the same mail, Guido also talks (jokes?) about improving timedeltas from grounds up: > I might still go for it [i.e. changing the attributes], if it wasn't too late > by over a decade (as Tim says). :) Though I think the discussion there stopped before anyone could raise the objection about verbosity and clarity, Guido, IMO, was optimistic about this change: > I still think the repr change to use keywords has a good chance for 3.6. https://marc.info/?l=python-dev=145073617109654=2 ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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, the timeouts while testing were triggered, breaking the buildbots. (Err ... sorry about that.) However, the latest fix by Serihy now runs each test only once. The `_Pure` tests, nevertheless, are significantly slower than `_Fast` tests and, hence, the slowdown. Running the tests take ~ 10 minutes on my system with -utzdata enabled; 19 minutes does sound like a bit much but I'm not aware of the specs of the buildbot machines. ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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 have to rewrite some of the
self.skipTest conditions such that they are more defensive, i.e.:
if '_Pure' not in self.__class__.__name__:
self.skipTest('...')
instead of:
if '_Fast' in self.__class__.__name__:
self.skipTest('...')
because some (one?) of the tests fail otherwise.
Shall I make that change?
Also, here is an alternate fix which is a tiny bit less murky than straight up
de-duplication of test-classes:
https://github.com/musically-ut/cpython/pull/1/files
I'm not sure whether this is any clearer or less fragile, though.
~
ut
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30822>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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,), {})
Test.zonename = name
for method in dir(Test):
if method.startswith('test_'):
tests.append(Test(method))
here:
https://github.com/python/cpython/blob/master/Lib/test/datetimetester.py#L4853
The `Test` class which is being dynamically created is being instantiated with
the test methods: test_folds, test_gaps, test_system_transitions and is being
appended to tests. This makes that class to appear thrice in `test_classes` in
`test_datetime.py`:
elif issubclass(cls, unittest.TestSuite):
suit = cls()
test_classes.extend(type(test) for test in suit)
here:
https://github.com/python/cpython/blob/master/Lib/test/test_datetime.py#L34
Hence, the class gets `_Pure` and `_Fast` appended to its name thrice and gets
executed thrice, making the tests take 3 times as long to run.
This is confirmed by changing the code to the following:
for name in ZoneInfo.zonenames():
Test = type('ZoneInfoTest[%s]' % name, (ZoneInfoTest,), {})
Test.zonename = name
tests.append(Test())
# for method in dir(Test):
#if method.startswith('test_'):
#tests.append(Test(method))
However, I'm not sure what implications this has w.r.t. unittests and the
advanced cases.
The other way to fix it is to create a set out of the classes, as suggested in
PR #2534.
~
ut
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30822>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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-30822` in their titles. Sounds about right? ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +2597 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30822] Python implementation of datetime module is not being tested correctly.
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. C extension code in _datetimemodule.c) and once for the _Pure implementation (i.e the Python code). The fix is contained in the following two commits: - https://github.com/python/cpython/pull/1493/commits/08e7548f56838fca43b488cefe51de4bdd600f3d - https://github.com/python/cpython/pull/1493/commits/94d5a4e4d33a1d14a2bb1be8fbff5e1e4cd2b7a6 The bug does not effect Python 2.7 as the C version of the datetime module had not been introduced back then. However, as fas as I can tell, the fix needs to be applied to all Python 3.x branches. -- components: Tests messages: 297455 nosy: musically_ut, serhiy.storchaka priority: normal severity: normal status: open title: Python implementation of datetime module is not being tested correctly. type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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! :) (haypo has already approved the change while I am still writing this.) ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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 (thanks @haypo!). To answer your question, the changes in this PR are completely orthogonal to the changes in the docstring needed. Hence, I'm counting one more vote towards making the docstring changes in a separate PR. Thanks! :-) ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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 negative sign or not. re: thoughts and opinions; I wanted to have them on: - Whether to factor out the negative sign. - Whether to throw in the doc-string/documentation changes into this PR or in a new one. Current position on these questions: - In favor of factoring out the -ve sign: Martin Not in favor of factoring out the -ve sign: Victor, R. David - DocString changes: (@haypo's opinion) in a separate PR. ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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 didn't want was perhaps adding attributes in repr which don't exist on the object [2]. Changing to keyword arguments was a 'go', though [3]. Esp. after it has been pointed out how easy it would be do implement, my opposition to the idea of factoring out the negative sign has somewhat come down. Personally, I prefer the current version. Further, this PR has also come to fix a couple of issues in the testing framework and it is becoming rather unwieldy to throw in doc-string changes into it as well. Hence, after some discussion with @haypo, I think I'll make a separate PR for fixing the docstrings after this PR is merged; there was general consensus that the docstrings should be fixed [4,5]. @haypo has, thankfully, showed me how and where to do that using Argument Clinic, which was the show-stopper the last time [6]. Thoughts and opinions? ~ ut [1]: https://marc.info/?l=python-dev=145066335824146=2 [2]: https://marc.info/?l=python-dev=145066934224955=2 [3]: https://marc.info/?l=python-dev=145073617109654=2 [4]: https://marc.info/?l=python-dev=145073579109548=2 [5]: https://marc.info/?l=python-dev=145073612409626=2 [6]: https://marc.info/?l=python-dev=145075173412963=2 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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 the latter for consistency with the other repr. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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(seconds=60)), "%s(seconds=60)" % name) self.assertEqual(repr(self.theclass()), "%s(seconds=0)" % name) self.assertEqual(repr(self.theclass(microseconds=100)), "%s(microseconds=100)" % name) self.assertEqual(repr(self.theclass(days=1, microseconds=100)), "%s(days=1, microseconds=100)" % name) self.assertEqual(repr(self.theclass(seconds=1, microseconds=100)), "%s(seconds=1, microseconds=100)" % name) I am still ambivalent about factoring the minus sign outside, though. I've also fixed a bug in test_datetime.py which prevented execution of the Python implementation in Lib/datetime.py. TODO: - Decide about factoring the minus sign. - Drop description of timedelta.__repr__ from the documentation. ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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 different numbers than the attributes things are worse than now." ~ Guido, https://marc.info/?l=python-dev=145066934224955=2 Maybe he was only talking about: datetime.timedelta(minutes=-1) # datetime.timedelta(minutes=-1) but I would like a second opinion on it. :) Also, I'll just drop the description of .repr from the .RST documentation because it is not to be relied on anyway. Any objections to that? ~ ut -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
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=145077422417470=2 (I may not have explored all the branches, though.) So there indeed seems to be general agreement about changing this. It was heartening to know that I wasn't the only one to stumble. \o/ > The built-in help was also discussed in that thread. I don’t think it got > fixed yet, did it? No, the doc-string is as uninformative as then, as far as I can tell: In [178]: datetime.timedelta? Init signature: datetime.timedelta(self, /, *args, **kwargs) Docstring: Difference between two datetime values. File: ~/miniconda3/lib/python3.5/datetime.py Type: type I'll investigate what documentation for other functions looks like and see if I can come up with something better. The exact documentation would be best discussed over diffs on Github. Then there is the issue of repr being explicitly documented, as you had pointed out on the Github issue. Guido thinks that any breakage is _unlikely_ but "asked around" here: https://marc.info/?l=python-dev=145065347022557=2 As far as I can tell, he didn't see an explicit response. > The size of the repr could be reduced a bit by dropping the module name: > datetime.timedelta vs just timedelta. Although that would be inconsistent > with the other classes; I’m not sure about this. Personally, I don't see a big problem either way but having datetime.timedelta in the repr feels reassuring to me that I have the 'right' type instead of some other 'timedelta' from a non-stdlib module (e.g. moments or pandas). > 1. Drop leading zeros: timedelta(seconds=60) rather than timedelta(days=0, > seconds=60). This would also help reduce the size. This sounds reasonable. I'll make this change and add corresponding tests. > 2. Factor out the negative sign: -timedelta(seconds=60) rather than > timedelta(days=-1, seconds=86340). I'm not sure there was consensus about this; if I understand correctly, Guido thinks that it is important that the repr return what the attributes hold: https://marc.info/?l=python-dev=145066934224955=2 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.datetime.timedelta
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. Consider the comically more verbose example: import time time.gmtime(1121871596) # time.struct_time(tm_year=2005, tm_mon=7, tm_mday=20, tm_hour=14, tm_min=59, tm_sec=56, tm_wday=2, tm_yday=201, tm_isdst=0) > datetime.datetime has more arguments, and its repr doesn't use keywords. I think that guessing the meaning of values is much harder when it comes to timedelta. > Users of datetime.timedelta know what arguments mean. If they don't know they > always can look in the documentation or builtin help. I created the issue after ... a friend ... spent an embarrassing amount of time debugging because he thought that the third argument represented milliseconds and not microseconds. <_< I could, of course, tell him: > In the face of ambiguity, resist the temptation to guess. But he could retort: > Explicit is better than implicit. and > Readability counts. I think he has a point. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.datetime.timedelta
Changes by Utkarsh Upadhyay <musically...@gmail.com>: -- pull_requests: +1595 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.datetime.timedelta
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) # datetime.timedelta(3114, 28747, 10) For the uninitiated, it is not obvious that the numeric values here are `days`, `seconds` and `microsecond` respectively. Would there be any pushback against changing this to: # datetime.timedelta(days=3114, seconds=28747, microseconds=10) ? -- components: Library (Lib) messages: 293212 nosy: musically_ut priority: normal severity: normal status: open title: Improve .__repr__ implementation for datetime.datetime.timedelta type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19361] Specialize exceptions thrown by JSON parser
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/19519409/how-to-get-error-location-from-json-loads-in-python Would it be a problem if the errors thrown were specialized exceptions, e.g. JSONParsingError, which has ValueError as a base class with these details (line number, char number, etc.) exposed as public members? The changes required seem to be limited to changing http://hg.python.org/cpython/file/4c4f31a1b706/Lib/json/decoder.py and the related documentation. -- components: Extension Modules messages: 201015 nosy: musically_ut priority: normal severity: normal status: open title: Specialize exceptions thrown by JSON parser type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19361 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19361] Specialize exceptions thrown by JSON parser
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
