[issue46761] functools.update_wrapper breaks the signature of functools.partial objects
Ka-Ping Yee added the comment: Hmm, interesting. I wasn't involved in writing the `follow_wrapper_chains` feature, so I don't know why it's there. I wonder if some digging through the revision history of `functools.py` and `inspect.py` would yield insight. -- ___ Python tracker <https://bugs.python.org/issue46761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2736] datetime needs an "epoch" method
Ka-Ping Yee added the comment: > no one has come up with a satisfactory solution Plenty have proposed a satisfactory solution. No one has come up with a solution that is satisfactory to *you*, because you have overconstrained the problem. The reason we still have no utctotimestamp() after all these years is that you, and you alone as far as I know, refuse to accept a method that inverts utcfromtimestamp() with microsecond precision over its working range. Such a method is a perfectly reasonable and acceptable solution and would add a lot of value to Python as a language. I suspect you don't realize just how much pain you have unintentionally caused the world of Python users by singlehandedly blocking progress on this issue. I've seen them: students, friends, coworkers -- even very smart and capable people are stymied by it. No one thinks of looking in the calendar module. Maybe if you watched some of them struggle with this, you would understand. > leave it as an exercise to the reader to solve To take this perspective is to miss the point of Python. -- ___ Python tracker <http://bugs.python.org/issue2736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2736] datetime needs an "epoch" method
Ka-Ping Yee added the comment: I am extremely disappointed by what has happened here. We are talking about a very simple method that everybody needs, and that has been reimplemented over and over again. I have been frustrated countless times by the lack of a utctotimestamp() method. I have watched beginners and experienced programmers alike suffer over and over again for the lack of this method, and spend hours trying to figure out why Python doesn't have it and how it should be spelled in Python. The discussion here has been stuck on assumptions that the method must meet all of the following ideals: 1. It must produce a value that is easy to compute with 2. It must have perfect precision in representing microseconds, forever 3. It must make an exact round-trip for any possible input 4. It must let users use whatever epoch they want These ideals cannot all be met simultaneously and perfectly. The correct thing to do as an engineer is to choose a practical compromise and document the decision. The compromise that almost everyone chooses (because it is useful, convenient, has microsecond precision at least until the year 2100, and millisecond precision is frequently sufficient) is to use a floating-point number with an epoch of 1970-01-01. Floating-point seconds can be easily subtracted, added, serialized, and deserialized, and are a primitive data type in nearly every language and database. They are unmatched in ease of use. So everyone wastes time searching for the answer and figuring out how to write: import calendar calendar.timegm(dt.utctimetuple()) + dt.microsecond * 1e-6 We should use this as the definition of datetime.utctotimestamp(), document its limitations, and be done with it. Instead, this essential and useful method has now been held up for almost three YEARS by an inability to accept a simple engineering decision. Unbelievable. -- nosy: +ping ___ Python tracker <http://bugs.python.org/issue2736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2141] Pydoc interactive browser misses some docs
Ka-Ping Yee <[EMAIL PROTECTED]> added the comment: This is (currently) the intended behaviour. The rfc822 module has an __all__ attribute that lists its public functions and classes, so "pydoc rfc822" only shows these things. formatdate is not listed in __all__. If you'd like to discuss ideas for changing this behaviour, possible forums would be comp.lang.python or the python-dev list. -- resolution: -> rejected status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2141> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2282] TextIOWrapper.seekable() always returns False
Ka-Ping Yee <[EMAIL PROTECTED]> added the comment: Patch committed. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2282> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1550] help('modules') broken by several 3rd party libraries (svn patch attached)
Ka-Ping Yee added the comment: Committed the patch in revision 59939. I'm not clear how it was determined that importing every module was necessary in order to list the modules or scan their synopsis lines (this seems to have happened in revision 45510). This can probably be made more efficient in the future. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
