Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Wed, Dec 10, 2014 at 5:59 PM, Bruno Cauet wrote: > Hi all, > Last year a survey was conducted on python 2 and 3 usage. > Here is the 2014 edition, slightly updated (from 9 to 11 questions). > It should not take you more than 1 minute to fill. I would be pleased if > you took that time. > > Here's the url: http://goo.gl/forms/tDTcm8UzB3 > I'll publish the results around the end of the year. > > Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey > > Thank you > Bruno > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > I still think the only *real* obstacle remains the lack of important packages such as twisted, gevent and pika which haven't been ported yet. With those ones ported switching to Python 3 *right now* is not only possible and relatively easy, but also convenient. -- Giampaolo - http://grodola.blogspot.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
As I didn't hear any objections, I'm officially stating that I expect initial draft PEPs to be in by February 1 to know who is in the running to focus discussion. I then expect complete PEPs by April 1 so I can read them before PyCon and have informed discussions while I'm there. I will then plan to make a final decision by May 1 so that we can try to have the changes ready for Python 3.6 development (currently scheduled for Sep 2015). On Fri Dec 05 2014 at 3:04:48 PM Brett Cannon wrote: > This is a bit long as I espoused as if this was a blog post to try and > give background info on my thinking, etc. The TL;DR folks should start at > the "Ideal Scenario" section and read to the end. > > P.S.: This is in Markdown and I have put it up at > https://gist.github.com/brettcannon/a9c9a5989dc383ed73b4 if you want a > nicer formatted version for reading. > > # History lesson > Since I signed up for the python-dev mailing list way back in June 2002, > there seems to be a cycle where we as a group come to a realization that > our current software development process has not kept up with modern > practices and could stand for an update. For me this was first shown when > we moved from SourceForge to our own infrastructure, then again when we > moved from Subversion to Mercurial (I led both of these initiatives, so > it's somewhat a tradition/curse I find myself in this position yet again). > And so we again find ourselves at the point of realizing that we are not > keeping up with current practices and thus need to evaluate how we can > improve our situation. > > # Where we are now > Now it should be realized that we have to sets of users of our development > process: contributors and core developers (the latter whom can play both > roles). If you take a rough outline of our current, recommended process it > goes something like this: > > 1. Contributor clones a repository from hg.python.org > 2. Contributor makes desired changes > 3. Contributor generates a patch > 4. Contributor creates account on bugs.python.org and signs the >[contributor agreement]( > https://www.python.org/psf/contrib/contrib-form/) > 4. Contributor creates an issue on bugs.python.org (if one does not > already exist) and uploads a patch > 5. Core developer evaluates patch, possibly leaving comments through our > [custom version of Rietveld](http://bugs.python.org/review/) > 6. Contributor revises patch based on feedback and uploads new patch > 7. Core developer downloads patch and applies it to a clean clone > 8. Core developer runs the tests > 9. Core developer does one last `hg pull -u` and then commits the changes > to various branches > > I think we can all agree it works to some extent, but isn't exactly > smooth. There are multiple steps in there -- in full or partially -- that > can be automated. There is room to improve everyone's lives. > > And we can't forget the people who help keep all of this running as well. > There are those that manage the SSH keys, the issue tracker, the review > tool, hg.python.org, and the email system that let's use know when stuff > happens on any of these other systems. The impact on them needs to also be > considered. > > ## Contributors > I see two scenarios for contributors to optimize for. There's the simple > spelling mistake patches and then there's the code change patches. The > former is the kind of thing that you can do in a browser without much > effort and should be a no-brainer commit/reject decision for a core > developer. This is what the GitHub/Bitbucket camps have been promoting > their solution for solving while leaving the cpython repo alone. > Unfortunately the bulk of our documentation is in the Doc/ directory of > cpython. While it's nice to think about moving the devguide, peps, and even > breaking out the tutorial to repos hosting on Bitbucket/GitHub, everything > else is in Doc/ (language reference, howtos, stdlib, C API, etc.). So > unless we want to completely break all of Doc/ out of the cpython repo and > have core developers willing to edit two separate repos when making changes > that impact code **and** docs, moving only a subset of docs feels like a > band-aid solution that ignores the big, white elephant in the room: the > cpython repo, where a bulk of patches are targeting. > > For the code change patches, contributors need an easy way to get a hold > of the code and get their changes to the core developers. After that it's > things like letting contributors knowing that their patch doesn't apply > cleanly, doesn't pass tests, etc. As of right now getting the patch into > the issue tracker is a bit manual but nothing crazy. The real issue in this > scenario is core developer response time. > > ## Core developers > There is a finite amount of time that core developers get to contribute to > Python and it fluctuates greatly. This means that if a process can be found > which allows core developers to spend less time doing mechanical work and > more time doing things t
Re: [Python-Dev] My thinking about the development process
> On Dec 11, 2014, at 9:59 AM, Brett Cannon wrote: > > As I didn't hear any objections, I'm officially stating that I expect initial > draft PEPs to be in by February 1 to know who is in the running to focus > discussion. I then expect complete PEPs by April 1 so I can read them before > PyCon and have informed discussions while I'm there. I will then plan to make > a final decision by May 1 so that we can try to have the changes ready for > Python 3.6 development (currently scheduled for Sep 2015). Is it OK to adapt my current PEP or should I create a whole new one? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
Just adapt your current PEP. On Thu Dec 11 2014 at 10:02:23 AM Donald Stufft wrote: > > On Dec 11, 2014, at 9:59 AM, Brett Cannon wrote: > > As I didn't hear any objections, I'm officially stating that I expect > initial draft PEPs to be in by February 1 to know who is in the running to > focus discussion. I then expect complete PEPs by April 1 so I can read them > before PyCon and have informed discussions while I'm there. I will then > plan to make a final decision by May 1 so that we can try to have the > changes ready for Python 3.6 development (currently scheduled for Sep 2015). > > > Is it OK to adapt my current PEP or should I create a whole new one? > > --- > Donald Stufft > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
Thanks Stephen elaborating on the process. and apologies, I was dismissing the last point only half jokingly. I read the comment for strftime / strptime in the report as meant to remember to implement it. It seems picking a new format letter (or keep using "%f" if acceptable) that would accept/produce up to 9 characters instead of 6 for nanoseconds would do most of the trick. Maybe there's no issue or I don't understand it. That completes my chant to awaken the Elderers! Regards, Matthieu On 12/10/14 9:10 PM, Stephen J. Turnbull wrote: mdcb808 writes: > These are typically discussed on this list or using the bug > tracker? I think this discussion belongs on python-dev because the requirement is clear, but a full specification involves backward compatibility with older interfaces, and clearly different people place different values on the various aspects of the problem. It makes sense to go straight to tracker when the design is done or obvious, or backward compatibility is clearly not involved. The tracker is also the place to record objective progress (patches, tests, bug reports). Python-Dev is where minds meet. What Nick is saying is that more design needs to be done to resolve differences of opinion on the best way to move forward. > maybe YNGTNI applied, Evidently not. If a senior developer really thought it's a YAGNI, the issue would have been closed WONTFIX. It seems the need is believable. > not clear why it's not there after 2 eyars. There's only one reason you need to worry about: nobody wrote a patch that meets the concerns of the senior developers (one of which is that concerns raised by anybody remain unresolved; they don't always have strong opinions themselves).[1] > - not sure what's at stake with the strp/ftime() but cant imagine > it's a biggie If you want something done, you don't necessarily need to supply a patch. But you have to do more to move things forward that just say "I can't imagine why anybody worries about that." You have to find out what their worries are, and explain that their worries won't be realized in the case of the obvious design (eg, the one you presented), or provide a design that avoids realizing those worries. Or you can get the senior developers to overrule the worriers, but you need a relatively important use case to make that fly. Or you can get somebody else to do some of the above, but that also requires presenting an important use case (to that somebody). Footnotes: [1] That's not 100% accurate: there is a shortage of senior developer time for reviewing patches. If it's simply that nobody has looked at the issue, simply bringing it up may be sufficient to get attention and then action. But Nick's response makes it clear that doesn't apply to this issue; people have looked at the issue and have unresolved concerns. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec wrote: > ...or keep using "%f" if acceptable... That might be a problem. While it will probably work most of the time, there are likely to be situations where the caller assumes it generates a six-digit string. I did a little poking around. It seems like "%N" isn't used. Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
Another issue to consider here is that parsing and printing should be symmetrical. The %f format gobbles up exactly 6 digits. Finally, strptime and strftime are not invented by Python, the same functions with (mostly) the same format characters are defined by other languages. Is there not a single other language that has added support for nanoseconds to its strftime/strptime? (I wouldn't be surprised if there wasn't -- while computer clocks have a precision in nanoseconds, that doesn't mean they are that *accurate* at all (even with ntpd running). On Thu, Dec 11, 2014 at 10:33 AM, Skip Montanaro wrote: > On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec wrote: > > ...or keep using "%f" if acceptable... > > That might be a problem. While it will probably work most of the time, > there are likely to be situations where the caller assumes it > generates a six-digit string. I did a little poking around. It seems > like "%N" isn't used. > > Skip > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
I think strftime / strptime support is a low-priority concern on this topic, and can probably be discussed independently of the core nanosecond support. Regards Antoine. On Thu, 11 Dec 2014 11:14:27 -0800 Guido van Rossum wrote: > Another issue to consider here is that parsing and printing should be > symmetrical. The %f format gobbles up exactly 6 digits. > > Finally, strptime and strftime are not invented by Python, the same > functions with (mostly) the same format characters are defined by other > languages. Is there not a single other language that has added support for > nanoseconds to its strftime/strptime? (I wouldn't be surprised if there > wasn't -- while computer clocks have a precision in nanoseconds, that > doesn't mean they are that *accurate* at all (even with ntpd running). > > On Thu, Dec 11, 2014 at 10:33 AM, Skip Montanaro > wrote: > > > On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec wrote: > > > ...or keep using "%f" if acceptable... > > > > That might be a problem. While it will probably work most of the time, > > there are likely to be situations where the caller assumes it > > generates a six-digit string. I did a little poking around. It seems > > like "%N" isn't used. > > > > Skip > > ___ > > Python-Dev mailing list > > [email protected] > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
I disagree. I know there's a huge focus on The Big Libraries (and wholesale migration is all but impossible without them), but the long tail of libraries is still incredibly important. It's like saying that migrating the top 10 Perl libraries to Perl 6 would allow people to completely ignore all of CPAN. It just doesn't make sense. -Mark On Thu, Dec 11, 2014 at 6:47 AM, Giampaolo Rodola' wrote: > > > On Wed, Dec 10, 2014 at 5:59 PM, Bruno Cauet wrote: > >> Hi all, >> Last year a survey was conducted on python 2 and 3 usage. >> Here is the 2014 edition, slightly updated (from 9 to 11 questions). >> It should not take you more than 1 minute to fill. I would be pleased if >> you took that time. >> >> Here's the url: http://goo.gl/forms/tDTcm8UzB3 >> I'll publish the results around the end of the year. >> >> Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey >> >> Thank you >> Bruno >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com >> > > I still think the only *real* obstacle remains the lack of important > packages such as twisted, gevent and pika which haven't been ported yet. > With those ones ported switching to Python 3 *right now* is not only > possible and relatively easy, but also convenient. > > > -- > Giampaolo - http://grodola.blogspot.com > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/wizzat%40gmail.com > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On 12/11/2014 11:23 AM, Antoine Pitrou wrote: > > I think strftime / strptime support is a low-priority concern on this > topic, and can probably be discussed independently of the core > nanosecond support. Agreed. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On 12/11/2014 11:14 AM, Guido van Rossum wrote: > > (I wouldn't be surprised if there wasn't -- while computer clocks have a > precision in > nanoseconds, that doesn't mean they are that *accurate* at all (even with > ntpd running). [reading issue] The real-world use cases deal with getting this information from other devices (network cards, GPS, particle accelerators, etc.), so it's not really a matter of cross-computer accurancy, but relative accuracy (i.e. how long did something take?). All in all, looks like a good idea. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou wrote: > I think strftime / strptime support is a low-priority concern on this > topic, and can probably be discussed independently of the core > nanosecond support. Might be low-priority, but with %f support as a template, supporting something to specify nanoseconds should be pretty trivial. The hardest question will be to convince ourselves that we aren't choosing a format code which some other strftime/strptime implementation is already using. In addition, ISTR that one of the use cases was analysis of datetime data generated by other applications which has nanosecond resolution. Unless those values are stored as epoch seconds, you're going to need to parse them. It's not clear to me why you'd give people only half the solution they need. Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On Thu, 11 Dec 2014 13:43:05 -0600 Skip Montanaro wrote: > On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou wrote: > > I think strftime / strptime support is a low-priority concern on this > > topic, and can probably be discussed independently of the core > > nanosecond support. > > Might be low-priority, but with %f support as a template, supporting > something to specify nanoseconds should be pretty trivial. The hardest > question will be to convince ourselves that we aren't choosing a > format code which some other strftime/strptime implementation is > already using. > > In addition, ISTR that one of the use cases was analysis of datetime > data generated by other applications which has nanosecond resolution. One of the use cases is to deal with OS-generated timestamps without losing information. As long as you don't need to represent or parse those timestamps, strptime / strftime don't come into the picture. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts wrote: > I disagree. I know there's a huge focus on The Big Libraries (and wholesale > migration is all but impossible without them), but the long tail of > libraries is still incredibly important. It's like saying that migrating the > top 10 Perl libraries to Perl 6 would allow people to completely ignore all > of CPAN. It just doesn't make sense. Things in the Python 2.x vs 3.x world aren't that bad. See: https://python3wos.appspot.com/ and https://wiki.python.org/moin/PortingPythonToPy3k http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code to run on 2.x and 3.x) I believe just about everything I've written over the last few years either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go the former route, you don't need to wait for your libraries to be updated. I usually run pylint twice for my projects (after each change, prior to checkin), once with a 2.x interpreter, and once with a 3.x interpreter (using http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but I gather pylint has the option of running on a 2.x interpreter and warning about anything that wouldn't work on 3.x. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
Ethan Furman : > On 12/11/2014 11:14 AM, Guido van Rossum wrote: >> (I wouldn't be surprised if there wasn't -- while computer clocks >> have a precision in nanoseconds, that doesn't mean they are that >> *accurate* at all (even with ntpd running). > > The real-world use cases deal with getting this information from other > devices (network cards, GPS, particle accelerators, etc.), so it's not > really a matter of cross-computer accurancy, but relative accuracy > (i.e. how long did something take?). It would be nice if it were possible to deal with high-precision epoch times and time deltas without special tricks. I have had to deal with femtosecond-precision IRL (albeit in a realtime C application, not in Python). Quad-precision floats (http://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format>) would do it for Python: * just do it in seconds * have enough precision for any needs * have enough renge for any needs Marko ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Thu Dec 11 2014 at 3:14:42 PM Dan Stromberg wrote: > On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts wrote: > > I disagree. I know there's a huge focus on The Big Libraries (and > wholesale > > migration is all but impossible without them), but the long tail of > > libraries is still incredibly important. It's like saying that migrating > the > > top 10 Perl libraries to Perl 6 would allow people to completely ignore > all > > of CPAN. It just doesn't make sense. > > Things in the Python 2.x vs 3.x world aren't that bad. > > See: > https://python3wos.appspot.com/ and > https://wiki.python.org/moin/PortingPythonToPy3k > http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code > to run on 2.x and 3.x) > > I believe just about everything I've written over the last few years > either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go > the former route, you don't need to wait for your libraries to be > updated. > > I usually run pylint twice for my projects (after each change, prior > to checkin), once with a 2.x interpreter, and once with a 3.x > interpreter (using > http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but > I gather pylint has the option of running on a 2.x interpreter and > warning about anything that wouldn't work on 3.x. > Pylint 1.4 has a --py3k flag to run only checks related to Python 3 compatibility under Python 2. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
On 2014-12-11 18:33, Skip Montanaro wrote: On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec wrote: ...or keep using "%f" if acceptable... That might be a problem. While it will probably work most of the time, there are likely to be situations where the caller assumes it generates a six-digit string. I did a little poking around. It seems like "%N" isn't used. Could the number of digits be specified? You could have "%9f" for nanoseconds, "%3f" for milliseconds, etc. The default would be 6 microseconds for backwards compatibility. Maybe, also, strptime could support "%*f" to gobble as many digits as are available. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
2014-12-11 22:00 GMT+01:00 MRAB : > > On 2014-12-11 18:33, Skip Montanaro wrote: >> >> >> there are likely to be situations where the caller assumes it >> generates a six-digit string. I did a little poking around. It seems >> like "%N" isn't used. >> >> Could the number of digits be specified? You could have "%9f" for > nanoseconds, "%3f" for milliseconds, etc. The default would be 6 > microseconds for backwards compatibility. Ruby does that, but use %9N. (a plain %N consume 9 digits by default). GNU date also use %N, but doesn't allow to specify the number of digits to consume. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
2014-12-11 15:47 GMT+01:00 Giampaolo Rodola' : > I still think the only *real* obstacle remains the lack of important > packages such as twisted, gevent and pika which haven't been ported yet. twisted core works on python 3, right now. Contribute to Twisted if you want to port more code... Or start something new, asyncio (with trollius, it works on Python 2 too). The develpoment branch of gevent supports Python 3, especially if you dont use monkey patching. Ask the developers to release a version, at least with "experimental" Python 3 support. I don't know pika. I read "Pika Python AMQP Client Library". You may take a look at https://github.com/dzen/aioamqp if you would like to play with asyncio. > With those ones ported switching to Python 3 *right now* is not only > possible and relatively easy, but also convenient. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
MRAB wrote: Maybe, also, strptime could support "%*f" to gobble as many digits as are available. The * would suggest that the number of digits is being supplied as a parameter. Maybe "%?f". -- Greg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
