Re: [Python-ideas] Top 10 Python modules that need a redesign Was: Geo coordinates conversion in stdlib
On Mon, Mar 23, 2015 at 2:08 AM, anatoly techtonik <techtonik@gmail.com> 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. 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. In my view, if anyone is to blame for the "human usability" of the datetime module, it would be Pope Gregory XIII, Benjamin Franklin and scores of unnamed astronomers who made modern timekeeping such a mess.
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 3/23/2015 1:21 PM, Alexander Belopolsky wrote:
On Mon, Mar 23, 2015 at 2:08 AM, anatoly techtonik <techtonik@gmail.com <mailto:techtonik@gmail.com>> 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.
...
in what sense does it not "pass human usability check"? ...
Please don't feed the troll. He is known for opinionated digs like the above and historically, nothing good comes from trying to discuss them. -- Terry Jan Reedy
On Mon, Mar 23, 2015 at 9:59 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 3/23/2015 1:21 PM, Alexander Belopolsky wrote:
On Mon, Mar 23, 2015 at 2:08 AM, anatoly techtonik <techtonik@gmail.com <mailto:techtonik@gmail.com>> 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.
...
in what sense does it not "pass human usability check"?
...
Please don't feed the troll. He is known for opinionated digs like the above and historically, nothing good comes from trying to discuss them.
Well, I admit that it takes a really bad mood and anger to write stuff about anything, and it is not very constructive state of mind. The rest of the things I could just probably silently enjoy (or spend time on something else). Whatever. To make anything constructive out of it, people need to accept the "usability" and "user experience" as a study disciplines, and that the studies could be and should be applied to Python (in this case to stdlib). -- anatoly t.
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 <techtonik@gmail.com> 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 <techtonik@gmail.com> 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 6:21 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
On Fri, Mar 27, 2015 at 10:54 AM, anatoly techtonik <techtonik@gmail.com> 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.
I don't think PEP8 matters at all. Python is not PHP - it has namespaces and consistency between modules never was so important issue for me at least, and I am pretty picky. But it is only a guess. I let data change my mind if there will be some. My theory is that these modules are just full of warts for specific but very common scenarios. 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. Usually you're just left a feeling that something suxx and this feeling is reinforced every time you hit the wart again and again. It's like AI learning. -- anatoly t.
On Fri, Mar 27, 2015 at 12:13 PM, anatoly techtonik <techtonik@gmail.com> 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 <techtonik@gmail.com> 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 <techtonik@gmail.com> 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
Note also that a PEP does not need to be the first step. Write the code, ask people to try it out, if others like it, they may test and contribute, etc. While a PEP may be necessary to get something into the stdlib or core, it can be a document that captures the interactive, "agile" process -- it does not need to be design up-front. -CHB On Saturday, April 4, 2015, Chris Angelico <rosuav@gmail.com> 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"
current PEP process assumes and people accuse me of being lazy and
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
On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik <techtonik@gmail.com <javascript:;>> wrote: like trolling 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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org <javascript:;> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
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 05/04/2015 08:32, Stephen J. Turnbull wrote:
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.)
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? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
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 04/04/2015 05:18, Chris Angelico wrote:
On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik <techtonik@gmail.com> 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 Sat, Apr 4, 2015 at 2:25 PM, Mark Lawrence <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
On 2015-04-04 21:16, Alexander Belopolsky wrote:
On Sat, Apr 4, 2015 at 2:25 PM, Mark Lawrence <breamoreboy@yahoo.co.uk <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.
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 4, 2015 at 7:28 PM, MRAB <python@mrabarnett.plus.com> wrote:
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
I am genuinely interested in the ways to improve date/time formatting in 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'
On 2015-04-05 01:45, Alexander Belopolsky wrote:
On Sat, Apr 4, 2015 at 7:28 PM, MRAB <python@mrabarnett.plus.com <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).
On Apr 5, 2015, at 06:13, MRAB <python@mrabarnett.plus.com> wrote:
On 2015-04-05 01:45, Alexander Belopolsky wrote:
On Sat, Apr 4, 2015 at 7:28 PM, MRAB <python@mrabarnett.plus.com <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 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.
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
On Sun, Apr 5, 2015 at 12:00 AM, Steven D'Aprano <steve@pearwood.info> wrote:
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.
That's easy. We added format codes to help('time.strftime') a couple years ago [1]. We can easily add the same to datetime.strftime. Feel free to open an issue. We don't need a PEP for that. :-) [1] http://bugs.python.org/issue9650
On Sat, Apr 4, 2015 at 9:25 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 04/04/2015 05:18, Chris Angelico wrote:
On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik <techtonik@gmail.com> 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.
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?
On Mon, Apr 6, 2015 at 1:47 PM, <random832@fastmail.us> 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 7:18 AM, Chris Angelico <rosuav@gmail.com> 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"
current PEP process assumes and people accuse me of being lazy and
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
On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik <techtonik@gmail.com> wrote: like trolling 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?
Don't have time and limited energy for such discussions. Switching to discussion requires unloading all other information, remembering the last point, tracking what people think. If you switch to discussion few days later (because you don't have time) it needs more time to refresh the data about the state. This is highly inefficient. Expanding on that below..
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*
I don't believe in the process, right. I need data. How many people actually read the PEPs through the end? How many say that they fully support the PEP decision? How many people read the diffs after they've read the PEP and can validate that none of their previous usage cases were broken? I assume that None. That's my belief, but I'd be happy to see that data that proves me wrong. I also don't believe in the PEP process, because I can't even validate my own usage cases using the layout of information proposed by the PEP. PEP is a compression and optimization of the various usage cases expressed in verbal form that is easy to implement, but not easy to understand or argue about decisions. Especially about ones that seem not-well-thought, because of the flawed process above. I also have problems with reading specifications without diagrams and with drawing concepts on a virtual canvas in my head. I also find that some stuff in PEP is confusing, but there is no channel like StackOverflow to ask question about design decisions. Maybe I am just a poor reader, but that is the reality. I'd prefer cookbook to PEP approach.
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.
The concept of "proposal" is completely fine. But the form is dated and ineffective. And I can't deal with people who are afraid of new concepts and can't see a rationale behind the buzzwords like agile, story, roadmap, user experience. These are all the de-facto tools of the new generation, and if somebody prefers to ride the steam engine, I don't mind, but me personally don't have the lifetime to move so slow.
On Mar 27, 2015, at 08:21, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Fri, Mar 27, 2015 at 10:54 AM, anatoly techtonik <techtonik@gmail.com> 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'm not sure how much weight to put on an informal poll of 176 people self-selected as readers of a particular blog in the first place, but... Back in those days, I think most people had no idea what they wanted from a redesign of distutils, and until at least one of the competing projects to extend/fix/replace it was ready for prime time (at least design-wise) the idea of changing the stdlib to follow one of them was a bit scary.
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.
Interesting point. And I think you're right--but I think you can take it farther. Even beyond the PEP 8 renaming, what kinds of things did people really want from those modules? People also wanted the 90%-compatible formatting/parsing functions to be 100% Java-compatible for logging and 100% my-plafform's-C-lib-compatible for datetime. And they wanted to be able to plug pytz into datetime without making it so easy to write what looks like correct timezone-aware code but actually isn't. And they wanted easier conversion between datetime's types and those in time and elsewhere. Those changes aren't as trivial as PEP 8 renaming, but they're still simple to express, concrete, and unambiguous (while still potentially requiring a backward-incompatible change). Who wouldn't vote for that?
On Sat, Mar 28, 2015 at 3:21 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Mar 27, 2015, at 08:21, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
On Fri, Mar 27, 2015 at 10:54 AM, anatoly techtonik <techtonik@gmail.com> 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'm not sure how much weight to put on an informal poll of 176 people self-selected as readers of a particular blog in the first place, but...
Back in those days, I think most people had no idea what they wanted from a redesign of distutils, and until at least one of the competing projects to extend/fix/replace it was ready for prime time (at least design-wise) the idea of changing the stdlib to follow one of them was a bit scary.
You're absolutely right that 176 people is hardly a honest poll. It is just an example that this thing is useful, so in ideal world PSF contact somebody who did that and support him with contacts, money, space, and other resources necessary to bring this to the level of representative and authoritative research.
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.
Interesting point. And I think you're right--but I think you can take it farther.
Even beyond the PEP 8 renaming, what kinds of things did people really want from those modules? People also wanted the 90%-compatible formatting/parsing functions to be 100% Java-compatible for logging and 100% my-plafform's-C-lib-compatible for datetime. And they wanted to be able to plug pytz into datetime without making it so easy to write what looks like correct timezone-aware code but actually isn't. And they wanted easier conversion between datetime's types and those in time and elsewhere.
Those changes aren't as trivial as PEP 8 renaming, but they're still simple to express, concrete, and unambiguous (while still potentially requiring a backward-incompatible change). Who wouldn't vote for that?
I totally agree with all above, except that "Those changes aren't as trivial as PEP 8 renaming, but they're still simple to express" - my opinion is that they are not simple to express. If something is missing, it is absolutely not easy to spot and it requires relatively a lot of time to reach a level of confidence that "no, that's impossible". Thanks to StackOverflow, it is less of a problem today. And still, while it is possible to *express* the changes or the problem somewhere in mailing list, it is absolutely impossible to make an **action item** or at least a **concept to consider for module redesign** out of that. Because you know that happens to those issues and bugs - they are closed, because "it works for me" or "it will break backward compatibility". -- anatoly t.
participants (13)
-
Alexander Belopolsky -
Alexander Walters -
anatoly techtonik -
Andrew Barnert -
Chris Angelico -
Chris Barker -
Chris Kaynor -
Mark Lawrence -
MRAB -
random832＠fastmail.us -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy