It works fine for me. It does not do EVERYTHING I need, but with dateutil and pytz, I am satisfied with the datetime infrastructure in python. Sure, I would like things changed in it, but its not like I expect the every module in the standard library to work exactly how I want. On 3/23/2015 13:21, Alexander Belopolsky wrote:

Speaking of the datetime module, in what sense does it not "pass human usability check"? It does have a few quirks, for example I would rather see date accept a single argument in the constructor which may be a string, another date or a tuple, but I am not even sure this desire is shared by many other humans. It would be nice if datetime classes were named in CamelCase according to PEP 8 conventions, but again this is a very minor quirk.

On Mon, Mar 23, 2015 at 8:21 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

On Mon, Mar 23, 2015 at 2:08 AM, anatoly techtonik wrote:

...

That's nice to know, but IIRC datetime is from the top 10 Python modules that need a redesign. Things contained therein doesn't pass human usability check, and are not used as a result.

Where have you been when PEP 3108 was discussed? I have not seen any other list of Python modules that needed a redesign, so I cannot tell what's on your top ten list.

http://sayspy.blogspot.com/2009/07/informal-poll-what-python-stdlib.html

On Fri, Mar 27, 2015 at 10:54 AM, anatoly techtonik wrote:

Where have you been when PEP 3108 was discussed? I have not seen any

...

other list of Python modules that needed a redesign, so I cannot tell what's on your top ten list.

http://sayspy.blogspot.com/2009/07/informal-poll-what-python-stdlib.html

Interesting. I did not see this back in the day. The top entry (urllib and friends) makes sense and there were heavily redesigned in Python 3. I am surprised that distutils redesign got less support than logging and datetime. I suspect that this may have to do with logging and datetime APIs not being PEP8 compliant. Popular votes tend to exaggerate the importance of trivial things such as the spelling of class and method names and brush off more subtle, but important design flaws.

On Fri, Mar 27, 2015 at 12:13 PM, anatoly techtonik wrote:

Here is something that can be used as an example that it is not about

PEP8 https://code.google.com/p/rainforce/wiki/WartsOfPython#measure_time And it takes a lot of energy to collect something like that for the reference. Well, in that document, I see the total of four "warts" related to the datetime module. If four warts bring a module to the top of the "worst designed stdlib modules" list, it can only mean that stdlib is almost perfect! For each "wart" the author has a "What can be done?" section, but no suggested solution involves a major redesign of the datetime module. The author complains about non-obviousness of strftime and indeed, for users without C background, neither name nor semantics is familiar. But the proposed solution

...

...

time.format('{{hours}}:{{minutes}}:{{seconds}}', 1090) '00:18:10'

Does not look like a big win over the already available solution:

...

...

'{t.hour}:{t.minute}:{t.second}'.format(t=datetime.now()) '12:37:38'

Overall, while I agree that there are a few warts in the datetime module, I have not seen any serious enough to warrant a major redesign or even any non backward compatible changes. Maintaining backward compatibility in the datetime module is indeed non-trivial, but this is the way I think it should be developed.

On Fri, Mar 27, 2015 at 7:55 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

On Fri, Mar 27, 2015 at 12:13 PM, anatoly techtonik wrote:

...

Here is something that can be used as an example that it is not about

PEP8 https://code.google.com/p/rainforce/wiki/WartsOfPython#measure_time And it takes a lot of energy to collect something like that for the reference.

Well, in that document, I see the total of four "warts" related to the datetime module. If four warts bring a module to the top of the "worst designed stdlib modules" list, it can only mean that stdlib is almost perfect!

This is just a personal list of one person for the stuff that is the most annoying to be worthy of spending 4 hours on research and documentation. I've spent at least one working day tracing and recording this down, needless to say that I had to invent the whole concept of wart for the stuff that is neither a bug, nor a feature. The quantity argument that you using doesn't not apply to usability issues. Take any of your gadgets for example. Remember non-USB cables for your phone? How you'd be running around and asking people if anybody has Nokia or Sony or whatever-brand-is-so-smart cable around. This is the wart, and no matter how do you like the phone and your brand and justify Apple use their own cables, for the rest of the world with normal phones this looks weird.

For each "wart" the author has a "What can be done?" section, but no suggested solution involves a major redesign of the datetime module.

Author is me, so you can ask directly. Why I didn't propose to redesign? Because people will assume that somebody will need to write PEP and will force me to write one. I don't believe in "redesign by specification" like current PEP process assumes and people accuse me of being lazy and trolling them, because I don't want to write the PEPs. Damn, I believe in iterative development and evolution, and I failed to persuade coredevs that practices digged up by people under the "agile" label is not some sort of corporate bullshit. So it is not my problem now. I did all I am capable of. The author complains about non-obviousness of strftime and indeed, for

users without C background, neither name nor semantics is familiar. But the proposed solution

...

...

...

time.format('{{hours}}:{{minutes}}:{{seconds}}', 1090) '00:18:10'

Does not look like a big win over the already available solution:

...

...

...

'{t.hour}:{t.minute}:{t.second}'.format(t=datetime.now()) '12:37:38'

You're evaluating the "big win" using your own biased criteria, not the one that are used by OP. I do not see how this solution makes statement "no obvious way to format time in seconds" false.

Overall, while I agree that there are a few warts in the datetime module, I have not seen any serious enough to warrant a major redesign or even any non backward compatible changes. Maintaining backward compatibility in the datetime module is indeed non-trivial, but this is the way I think it should be developed.

You're hijacking the issue into BC black hole leaving no chance to provide a better alternative. Let's state that it is obvious that the *behaviour of modules that need a redesign will not change* - the best thing that could happen is that they will get replacements without chronic disease encoded in their DNA. And to engineer that DNA, a proper "scientific method" should be used. "Writing a PEP" is not a method, and "it works for me" is not an argument. -- anatoly t.

On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik wrote:

Author is me, so you can ask directly. Why I didn't propose to redesign? Because people will assume that somebody will need to write PEP and will force me to write one. I don't believe in "redesign by specification" like current PEP process assumes and people accuse me of being lazy and trolling them, because I don't want to write the PEPs. Damn, I believe in iterative development and evolution, and I failed to persuade coredevs that practices digged up by people under the "agile" label is not some sort of corporate bullshit. So it is not my problem now. I did all I am capable of.

Why, exactly, is it that you don't want to author a PEP? Is it because you don't have the time to devote to chairing the discussion and all? If so, you could quite possibly persuade someone else to. I'd be willing to take on the job; convince me that your core idea is worth pursuing (and make clear to me precisely what your core idea is), and I could do the grunt-work of writing. But you say that you "don't *believe in*" the process, which suggests a more philosophical objection. What's the issue, here? Why are you holding back from such a plan? *cue the troll music* There are many Pythons in the world. You can't just hack on CPython and expect everything to follow on from there. Someone has to explain to the Jython folks what they'll have to do to be compatible. Someone has to write something up so MicroPython can run the same code that CPython does. Someone, somewhere, has to be able to ensure that Brython users aren't caught out by your proposed change. PEPs provide that. (They also provide useful pointers for the "What's New" lists, eg PEP 441.) So, are you proposing a change to Python? Then propose it. ChrisA

On 04/04/2015 05:18, Chris Angelico wrote:

On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik wrote:

...

Author is me, so you can ask directly. Why I didn't propose to redesign? Because people will assume that somebody will need to write PEP and will force me to write one. I don't believe in "redesign by specification" like current PEP process assumes and people accuse me of being lazy and trolling them, because I don't want to write the PEPs. Damn, I believe in iterative development and evolution, and I failed to persuade coredevs that practices digged up by people under the "agile" label is not some sort of corporate bullshit. So it is not my problem now. I did all I am capable of.

Why, exactly, is it that you don't want to author a PEP? Is it because you don't have the time to devote to chairing the discussion and all? If so, you could quite possibly persuade someone else to. I'd be willing to take on the job; convince me that your core idea is worth pursuing (and make clear to me precisely what your core idea is), and I could do the grunt-work of writing. But you say that you "don't *believe in*" the process, which suggests a more philosophical objection. What's the issue, here? Why are you holding back from such a plan? *cue the troll music*

There are many Pythons in the world. You can't just hack on CPython and expect everything to follow on from there. Someone has to explain to the Jython folks what they'll have to do to be compatible. Someone has to write something up so MicroPython can run the same code that CPython does. Someone, somewhere, has to be able to ensure that Brython users aren't caught out by your proposed change. PEPs provide that. (They also provide useful pointers for the "What's New" lists, eg PEP 441.)

So, are you proposing a change to Python? Then propose it.

ChrisA

I don't understand why people bother with this gentleman. All talk, no action, but expects others to do his bidding. I would say "Please go take a running jump", but that would get me into trouble with the CoC aficionados, so I won't. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On 2015-04-04 21:16, Alexander Belopolsky wrote:

On Sat, Apr 4, 2015 at 2:25 PM, Mark Lawrence mailto:breamoreboy@yahoo.co.uk> wrote:

...

I don't understand why people bother with this gentleman.

I did see constructive input from Anatoly on the bug tracker before. I believe other developers did too. Granted, in the last few years signal-to-noise ratio in his posts was rather low, but I usually ignore the "from:" header in the technical discussions.

I am genuinely interested in the ways to improve date/time formatting in Python. There are certainly better ways than stftime. For example, ICU has a date/time format syntax that is much more readable: instead of "%Y-%m-%d %H:%M:%S", ICU format is "yyyy-MM-dd HH:mm:ss".

I don't think it is hard to find a way to introduce ICU format in datetime.__format__ while preserving backward compatibility. For example, we may require that % is always "escaped" as '%' in ICU format and the presence of unescaped % can trigger strftime interpretation.

[1] http://userguide.icu-project.org/formatparse/datetime

Personally, I prefer some kind of escaping, possibly in the style of .format, e.g. "{year}-{month}-{day} {hour}:{minute}:{second}". (It'll probably need a little tinkering to shorten it! :-))

On Sat, Apr 04, 2015 at 04:16:47PM -0400, Alexander Belopolsky wrote:

I am genuinely interested in the ways to improve date/time formatting in Python. There are certainly better ways than stftime. For example, ICU has a date/time format syntax that is much more readable: instead of "%Y-%m-%d %H:%M:%S", ICU format is "yyyy-MM-dd HH:mm:ss".

I don't think it is hard to find a way to introduce ICU format in datetime.__format__ while preserving backward compatibility. For example, we may require that % is always "escaped" as '%' in ICU format and the presence of unescaped % can trigger strftime interpretation.

[1] http://userguide.icu-project.org/formatparse/datetime

That would be much more understandable to anyone who has used Excel or Excel-compatible spreadsheets. I wouldn't even *attempt* to add it to datetime.__format__, I would create either: - a new datetime method which uses ICU/Excel syntax directly: today = datetime.datetime.now().format_picture("yyyy-MM-dd") - or a new module function which converts ICU/Excel syntax to strftime format, which would allow post-processing in full generality: fmt = "Today is: " + datetime.make_format("yyyy-MM-dd") today = datetime.now().strftime(fmt, datetime.now()) Either is much more explicit and less magical than something which tries to guess whether a format string is ICU format or strftime format from the format string. But frankly, I would be satisfied with the list and meaning of format codes being documented somewhere where I can inspect it at runtime using help(), without having to run `man strftime` on a Linux system or search the Internet. Even something as trivial as giving the datetime module a list of format codes would work for me: print(datetime.CODES) -> [('%y', 'two digit year'), ('%Y', 'four digit year'), ... ] although having it pretty-print by default would be nice :-) As I understand it, the list of codes accepted is platform-dependent. While many codes are standard from machine to machine, some are not available on some systems. -- Steve

Chris Barker writes:

Note also that a PEP does not need to be the first step.

Please do not feed the troll. Anatoly's technical ideas can be reasonably interesting, and as you see in the "datetime format" subthread, can trigger useful discussion. His ideas about workflow, however, are completely self-centered and inappropriate for Python. They do not deserve any more discussion in public. Already he has wasted many hours of several developers' time. You're welcome to try again, but please keep it off-list until you have some movement on his part to show. Nor does he ever share any content with the community; historically he has been a CLA refusenik. (To be fair, he may have changed in the interval since he was banned from the list and when the ban was lifted, but he hasn't said so yet.) Ironically enough, a PEP is about the only thing he's willing to provide the necessary legal authority to incorporate in Python! (At least, I don't recall being asked for a CLA to contribute to a PEP.)

On Sun, Apr 05, 2015 at 08:48:15AM +0100, Mark Lawrence wrote:

Rather difficult to have legal problems with the PEP copyright notice that always states "This document has been placed in the public domain.", or is that tempting fate? :)

According to the Creative Commons legal department, it is not always possible to attribute a work into the public domain. You can say it is public domain, but it isn't, it's still copyrighted, and even if you never enforce it, your heirs might. http://creativecommons.org/about/cc0 -- Steve

On Apr 5, 2015, at 06:13, MRAB wrote:

...

On 2015-04-05 01:45, Alexander Belopolsky wrote:

On Sat, Apr 4, 2015 at 7:28 PM, MRAB mailto:python@mrabarnett.plus.com> wrote:

I am genuinely interested in the ways to improve date/time formatting in Python. There are certainly better ways than stftime. For example, ICU has a date/time format syntax that is much more readable: instead of "%Y-%m-%d %H:%M:%S", ICU format is "yyyy-MM-dd HH:mm:ss".

I don't think it is hard to find a way to introduce ICU format in datetime.__format__ while preserving backward compatibility. For example, we may require that % is always "escaped" as '%' in ICU format and the presence of unescaped % can trigger strftime interpretation.

[1] http://userguide.icu-project.org/formatparse/datetime

Personally, I prefer some kind of escaping, possibly in the style of .format, e.g. "{year}-{month}-{day} {hour}:{minute}:{second}". (It'll probably need a little tinkering to shorten it! :-))

Can someone explain to me why something like this or Anatoly's double-curly-brace variant is an improvement over

...

...

...

from datetime import * "{0.year}-{0.month}-{0.day} {0.hour}:{0.minute}:{0.second}".format(datetime.now()) '2015-4-4 20:43:23' Maybe it just needs the addition of attributes for '%A' and '%a' (name of day) and '%B' and '%b' (name of month).

It probably needs most of the fields in strftime. While some of them may only be there because one guy at one Unix company needed it one time, things like 12-hour time and AM/PM, tz offset, month abbreviation, week number, etc. are not exactly rare, just a little uncommon; it would less than ideal to write most of your program with format, but have to fall back to strftime a couple times with a comment explaining that datetime is insufficient. (On the other hand, it is nice that you can do things like 0 prefix the same as any other format element, instead of needing to remember separate codes for with and without prefix.)

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Apr 6, 2015 at 1:47 PM, wrote:

On Sat, Apr 4, 2015, at 00:18, Chris Angelico wrote:

...

There are many Pythons in the world. You can't just hack on CPython and expect everything to follow on from there. Someone has to explain to the Jython folks what they'll have to do to be compatible. Someone has to write something up so MicroPython can run the same code that CPython does.

I thought that was the point of having pure python modules. If this can't be "figure it out, or use the pure python reference implementation already provided" then what's the point?

Many of the other Python instances may have optimized versions of the libraries (CPython itself often does so, as does PyPy), or be using APIs from their base language (Jython and IronPython are good examples). In any of those cases, they have to update their versions/wrappers to support the new documented behavior. One of the points of a PEP is to document the changes so that those other versions know what they must change in their libraries, which may not be merely a port of the Python implementation. In fact, without a PEP system, it is likely that the changes could just fall under the rug and be completely missed, causing each implementation to have its effectively have its own standard library version, none of which are fully compatible with each other (and worse when may generally seem compatible). In addition to documenting the changes, the PEP process also allows the maintainers of other implementations (as well as the CPython core developers and anybody else interested) to officially provide feedback and concerns about the purposed changes. That all said, one of the common steps of PEP writing is to fork/branch the CPython code base and create a reference implementation of the proposal. The could be done merely by making a PyPi package or other third-party library for simpler changes or additions, or an actual fork/branch for more detailed or root changes (such as attempts to remove the GIL or changing syntax). Additionally, the pure python modules have other benefits. Namely, they can act as a fallback for when the optimized C modules cannot function, such as running on a platform which has not been fully optimized for. Chris

On Sat, Apr 4, 2015 at 9:25 PM, Mark Lawrence wrote:

On 04/04/2015 05:18, Chris Angelico wrote:

...

On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik wrote:

...

Author is me, so you can ask directly. Why I didn't propose to redesign? Because people will assume that somebody will need to write PEP and will force me to write one. I don't believe in "redesign by specification" like current PEP process assumes and people accuse me of being lazy and trolling them, because I don't want to write the PEPs. Damn, I believe in iterative development and evolution, and I failed to persuade coredevs that practices digged up by people under the "agile" label is not some sort of corporate bullshit. So it is not my problem now. I did all I am capable of.

Why, exactly, is it that you don't want to author a PEP? Is it because you don't have the time to devote to chairing the discussion and all? If so, you could quite possibly persuade someone else to. I'd be willing to take on the job; convince me that your core idea is worth pursuing (and make clear to me precisely what your core idea is), and I could do the grunt-work of writing. But you say that you "don't *believe in*" the process, which suggests a more philosophical objection. What's the issue, here? Why are you holding back from such a plan? *cue the troll music*

There are many Pythons in the world. You can't just hack on CPython and expect everything to follow on from there. Someone has to explain to the Jython folks what they'll have to do to be compatible. Someone has to write something up so MicroPython can run the same code that CPython does. Someone, somewhere, has to be able to ensure that Brython users aren't caught out by your proposed change. PEPs provide that. (They also provide useful pointers for the "What's New" lists, eg PEP 441.)

So, are you proposing a change to Python? Then propose it.

ChrisA

I don't understand why people bother with this gentleman. All talk, no action, but expects others to do his bidding. I would say "Please go take a running jump", but that would get me into trouble with the CoC aficionados, so I won't.

What action can I do if I point that CLA is invalid, and nobody answers to my call? I don't agree that people are signing it without understanding the content in detail, and I got banned for it. I sent a few patches to tracker, but what's the point if people are afraid to apply even the doc fixes. Instead of obeying the order of copyright lawyers from the paper age, the role of any Internet Community is to understand and guard its own interests and protect its way of doing things. Instead of that, the community is just places a roadblock, because "lawyers know better". Anti-offtopic. If you want to see, what I do, and want to enable some of the big things that can come up in the future, please help resolve this issue with Jinja2, Python 2 and setdefaultencoding utf-8 - http://issues.roundup-tracker.org/issue2550811 - just as a core developer, send us a patch that we should commit to enable Roundup work with Jinja2 again. This a key to add "modules" field to tracker to track patches submitted to different modules (using modstats.py from https://bitbucket.org/techtonik/python-stdlib) and split the work for different interested parties. This key lower the barrier to entry by removing the need to learn XML and TAL stuff from designers who want to experiment with Python tracker to add stuff, like marking modules that need a redesign. -- anatoly t.