New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pure Python strptime() (PEP 42) #35391
Comments
The attached file contains a pure Python version of PEP-42 makes a request for a portable, consistent
This module attempts to close that feature request. The code has been tested thoroughly by myself as well It is available at the Python Cookbook A PyUnit testing suite for the module is available at If the code needs to have its license changed, I am -Brett Cannon |
Logged In: YES I'm pretty sure this code needs a different license before |
Logged In: YES Oops. I thought I had removed the clause. Feel free to I am going to be cleaning up the module, though, so if you Speaking of which, should I just reply to this bugfix when I |
Logged In: YES Go ahead and reuse this item. I'll wait for the updated |
Logged In: YES Version 2 of strptime() has now been uploaded. This nearly |
Logged In: YES Overall, the patch looks pretty good.
Also, note that PEP-42 has a comment about a python strptime. |
Logged In: YES I'm afraid you looked at the wrong patch! My fault since I I realized the other day that since the time module is a C As for the suggestions, here are my replies to the ones that
-Brett C. |
Logged In: YES Brett, Please see the drastically shortened test_strptime.py. (Basically all I'm parsetime = time.strptime
#parsetime = strptime.strptime Regardless which version of parsetime I get, I get some errors. If ====================================================================== Traceback (most recent call last):
File "test_strptime.py", line 69, in test_timezone
strp_output = parsetime(strf_output, "%Z")
ValueError: unconverted data remains: 'CDT' If parsetime == strptime.strptime I get ERROR: *** Test %c directive. *** Traceback (most recent call last):
File "test_strptime.py", line 75, in test_date_time
self.helper('c', position)
File "test_strptime.py", line 17, in helper
strp_output = parsetime(strf_output, '%'+directive)
File "strptime.py", line 380, in strptime
found_dict = found.groupdict()
AttributeError: NoneType object has no attribute 'groupdict' ====================================================================== Traceback (most recent call last):
File "test_strptime.py", line 31, in test_month
self.helper(directive, 1)
File "test_strptime.py", line 17, in helper
strp_output = parsetime(strf_output, '%'+directive)
File "strptime.py", line 393, in strptime
month = list(locale_time.f_month).index(found_dict['b'])
ValueError: list.index(x): x not in list This is with a very recent interpreter (updated from CVS in the past Can you reproduce either or both problems? Got fixes for the Thx, Skip |
Logged In: YES I have uploaded a verision 2.0.1 which fixes the %b format As for the %c directive, I pass that test. Can you please As for the time.strptime() failure, I don't have I don't know how much %Z should be worried about since its -Brett |
Logged In: YES Here ya go... % ./python
Python 2.3a0 (#185, Jun 1 2002, 23:19:40)
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> now = time.localtime(time.time())
>>> now
(2002, 6, 4, 0, 53, 39, 1, 155, 1)
>>> time.strftime("%c", now)
'Tue Jun 4 00:53:39 2002'
>>> time.tzname
('CST', 'CDT')
>>> time.strftime("%Z", now)
'CDT' |
Logged In: YES Thanks for being so prompt with your response, Skip. I found the problem with your %c. If you look at your Now the question becomes do we follow the spec and chaulk As for the test error from time.strptime(), I don't know One last thing. Should I wait until the bugs are worked out |
Logged In: YES Hopefully, I'm looking at the correct patch this time. :-) To answer one question you had (re: 'yY' vs. ('y', 'Y')), In order to try to reduce the lines where you raise an error Generally, it would be nice to make sure none of the lines Instead of doing: you could do: In __init__ do you want to check the params against 'is None' What is the magic date used in __calc_weekday()? __calc_month() doesn't seem to take leap year into account? Are you supposed to use __init__ when deriving from In __tupleToRE.sorter(), instead of the last 3 lines, you Note: you can do x = y = z = -1, instead of x = -1 ; y = -1 It could be problematic to compare x is -1. You should This docstring seems backwards: BTW, protocol on python-dev is pretty loose and friendly. :-) |
Logged In: YES I went ahead an implemented most of Neal's suggestions. On For the 'yY' vs. ('y', 'Y'), I went with 'yY'. If it gives The tests in the __init__ for LocaleTime have been reworked I have gone through and tried to catch all the lines that For the adding of '' to tuples, I created a method that I explained why the various magic dates were used. I in no way have to worry about leap year. Since it is not date_time[offset] has been replaced with current_format and You are only supposed to use __new__ when it is immutable. Used Neal's suggested shortening of the sorter helper fxn. I also used the suggestion of doing x = y = z = -1. Now it All numerical compares use == and != instead of is and is The doc string was backwards. Thanks for catching that, Neal. I also went through and added True and False where And I completely understand being picky about minute details And I will query python-dev about how to go about to get |
Logged In: YES I am back from my vacation and ready to email python- Before then, though, I am going to make two changes. If there is any reason anyone thinks I should hold back on |
Logged In: YES I uploaded v.2.0.3. Beyond implementing what I mentioned For one, I added a special " \d" to the numeric month regex. I changed all attributes in LocaleTime to lists. A recent I also added a method that raises a TypeError if you try to It does require 2.2.1 now since I used True and False I also updated the overly exhaustive PyUnit suite that I |
Logged In: YES I have uploaded v. 2.0.4. It now uses the calendar module |
Logged In: YES 2.1.0 is now up and ready for use. I only changed two One, I removed the ability to pass in your own LocaleTime The other reason was that I don't want to force users to In retrospect, though, people will probably never parse log The second change was what triggers strptime() to return an Now, to have an re object returned, you pass in False. I I debated about removing this feature from strptime(), but I |
Logged In: YES I have uploaded a contextual diff of timemodule.c with a It's my first extension module, so I am not totally sure of |
Logged In: YES 2.1.1 is now uploaded. Almost a purely syntatical change. I also put all of the imports on their own line as per PEP-8. The only semantical change I did was directly import These changes required tweaking of my exhaustive testing |
Logged In: YES Uploaded 2.1.2 (but accidentally labelled it 2.1.3 down I also fiddled with the regexes so that the groups were |
Logged In: YES The actual 2.1.3 edition of strptime is now up. I don't I also uploaded a new contextual diff of the time module |
Logged In: YES Hm. This isn't done yet. I get these problems: (a) the patch for timemodule.c doesn't apply cleanly in (b) it still tries to import strptime (no leading '_') (also (c) so does test_strptime.py (also trivial) (d) the simplest of simple examples fails: With Linux's strptime: >>> time.strptime("7/12/02", "%m/%d/%y")
(2002, 7, 12, 0, 0, 0, 4, 193, 0)
>>> With yours: >>> time.strptime("7/12/02", "%m/%d/%y")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/home/guido/python/dist/src/Lib/_strptime.py", line
392, in strptime
raise ValueError("time data did not match format")
ValueError: time data did not match format
>>> Perhaps you should write a regression test suite for the |
Logged In: YES To respond to your points, Guido: (a) I accidentally uploaded the old file. Sorry about that. (b) See (a) (c) Oops. That is a complete oversight on my part. Now in (d) The reason this test failed is because your input is not Month as a decimal number [01,12] Notice the leading 0 for the single digit month. My In other words, either strptime stays as it is and follows |
Logged In: YES Hm, the new diff_time *still* fails to apply. But don't I'd love to see regression tests for time.strptime. Please I think your interpretation of the docs is overly |
Logged In: YES Uploaded 2.1.4. I added \d to the end of all relevant I also made the regex case-insensitive. As for the diff failing, I am wondering if I am doing I will work on merging my strptime tests into the time I will do a patch for the docs since it is not consistent I tried finding XPG docs, but the best Google came up with Personally, I don't like either difference. If they were Also, I noticed that your little test returned 0 for all |
Logged In: YES Two things have been uploaded. First, test_time.py w/ a The other file is version 2.1.5 of strptime. I made two I decided not to write a patch for the docs to make them I think that is everything. If you want more in-depth |
Logged In: YES
====================================================================== Traceback (most recent call last):
File "../Lib/test/test_strptime.py", line 124, in test_pattern
self.failUnless(pattern_string.find("(?P<d>(3[0-1])|([0-2]\d)|\d|(
\d))") != -1, "did not find 'd' directive pattern string
'%s'" % pattern_string)
File "/home/guido/python/dist/src/Lib/unittest.py", line
262, in failUnless
if not expr: raise self.failureException, msg
AssertionError: did not find 'd' directive pattern string
'(?P<a>(?:Mon)|(?:Tue)|(?:Wed)|(?:Thu)|(?:Fri)|(?:Sat)|(?:Sun))\s*(?P<A>(?:Wednesday)|(?:Thursday)|(?:Saturday)|(?:Tuesday)|(?:Monday)|(?:Friday)|(?:Sunday))\s*(?P<d>3[0-1]|[0-2]\d|\d|
\d)' I haven't looked into this deeper. Back to you... |
Logged In: YES God I wish I could delete those old files! Poor Neal I am terribly sorry about this whole name mix-up. I have I removed the __future__ import. And thanks for the piece As for your error, that is because the test_strptime.py you That's it this time. Now I await the next drama in this |
Logged In: YES OK, deleting all old files as promised. All tests succeed. I |
Logged In: YES Wonderful! About the docs; do you want me to email Fred or upload a |
Logged In: YES Since I had the time, I went ahead and did a patch for |
Logged In: YES Brett, I'm still following. It wasn't that bad. :-) Docs are fine to upload here. I can change PEP-42 also. |
Logged In: YES Thanks! All checked in. |
Logged In: YES _strptime still doesn't handle case correctly. Although it >>> import _strptime as strptime
>>> strptime.strptime( 'Aug', '%b' )
(-1, 8, -1, -1, -1, -1, -1, -1, -1)
>>> strptime.strptime( 'AUG', '%b' )
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Program Files\Python\Lib\site-
packages\strptime.py", line 410, in strptime
month = locale_time.a_month.index(found_dict['b'])
ValueError: list.index(x): x not in list The same result is encountered using any variation of 'aug' I imagine the solution to this problem is as simple as As a general note, I believe the test suite should also test for I will only suggest these changes, not implement them Regards, |
Logged In: YES Reopening to address Jason's bug report. Brett, can you provide a patch? |
Logged In: YES Yep, I will patch it. I will add it to patch 593560 which |
Logged In: YES OK, all patched and attached to the other patch entry. I |
Logged In: YES Closing. Refer to patch 593560 for further details. |
Logged In: YES I'm assuming Barry really meant to keep this closed. :-) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: