Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
repr() with keywords is called a method, no? Like isoformat() Victor Le lundi 21 décembre 2015, Guido van Rossum a écrit : > I still think the repr change to use keywords has a good chance for 3.6. > > --Guido (mobile) > On Dec 21, 2015 2:09 PM, "Chris Barker" > wrote: > >> On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico > > wrote: >> >>> >>> Would there be value in changing the repr to use keyword arguments? >>> >> >> this thread got long, but it sounds like that won't be worth the >> backwards compatibility... >> >> >>> Worse, help(datetime.timedelta) in 3.6 doesn't document the >>> constructor at all. There's no mention of __init__ at all, __new__ has >>> this useless information: >>> >> >> but this seems to have gotten lost in the shuffle. >> >> and aside from there being three data descriptors, there's nothing to >>> suggest that you construct these things with timedelta(days, seconds, >>> microseconds). Definitely no indication that you can use other keyword >>> args. >>> >>> Is this something worth fixing, or is it acceptable to drive people to >>> fuller documentation than help()? >>> >> >> Absolutlye worht fixing! maybe it' sjsut my weird workflow, but I find it >> very, very useful to use iPython's ? : >> >> In [10]: datetime.timedelta? >> Docstring: Difference between two datetime values.File: >> ~/miniconda2/lib/python2.7/lib-dynload/datetime.so >> Type: type >> >> and there are a LOT of next-to worthless docstrings in the stdlib -- it >> would be nice to clean them all up. >> >> Is there any reason not to, other than someone having to do the work? >> >> -Chris >> >> >> >> -- >> >> 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 >> >> [email protected] >> >> >> ___ >> 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] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
On Tue, Dec 22, 2015 at 7:39 PM, Victor Stinner wrote: > Le lundi 21 décembre 2015, Guido van Rossum a écrit : >> >> I still think the repr change to use keywords has a good chance for 3.6. > > repr() with keywords is called a method, no? Like isoformat() > Not keyword arguments - the proposal is to change the repr from one format to another. Currently, the repr indicates a constructor call using positional arguments: >>> datetime.timedelta(1) datetime.timedelta(1) >>> datetime.timedelta(1,2) datetime.timedelta(1, 2) >>> datetime.timedelta(1,2,3) datetime.timedelta(1, 2, 3) >>> datetime.timedelta(1,2,3,4) datetime.timedelta(1, 2, 4003) The proposal is to make it show keyword args instead: >>> datetime.timedelta(days=1) datetime.timedelta(days=1) >>> datetime.timedelta(days=1,seconds=2) datetime.timedelta(days=1, seconds=2) >>> datetime.timedelta(days=1,seconds=2,microseconds=3) datetime.timedelta(days=1, seconds=2, microseconds=3) >>> datetime.timedelta(days=1,seconds=2,microseconds=3,milliseconds=4) datetime.timedelta(days=1, seconds=2, microseconds=4003) ChrisA ___ 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] New poll about a macro for safe reference replacing
On 21.12.15 17:37, Nick Coghlan wrote: Avoiding those misleading associations is a good argument in favour of Py_REPLACE over Py_SETREF - they didn't occur to me before casting my votes, and I can definitely see them causing confusion in the future. So perhaps the combination that makes the most sense is to add Py_REPLACE (uses Py_DECREF on destination) & Py_XREPLACE (uses Py_XDECREF on destination) to the existing Py_CLEAR? And we return to where we started. Although I personally prefer Py_REPLACE/Py_XREPLACE, I'm afraid that using them would look like I just ignore the results of the poll. Because Py_SETREF looks good for most developers at first glance, I hope this will not lead to confusion in the future. If there are no new objections, I will commit the trivial auto-generated patch today and will provide a patch that covers more non-trivial cases. Now is better than never, and we have been bikeshedding this too long for "right now". ___ 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] New poll about a macro for safe reference replacing
On 21.12.15 23:57, Steve Dower wrote: Was Py_MOVEREF (or MOVE_REF) ever suggested? This would be nice name. The macro moves the ownership. But I think it's too late. Otherwise we'll never finish the bikeshedding. ___ 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] New poll about a macro for safe reference replacing
Nick Coghlan writes: > Avoiding those misleading associations is a good argument in favour of > Py_REPLACE over Py_SETREF - they didn't occur to me before casting my > votes, and I can definitely see them causing confusion in the future. > > So perhaps the combination that makes the most sense is to add > Py_REPLACE (uses Py_DECREF on destination) & Py_XREPLACE (uses > Py_XDECREF on destination) to the existing Py_CLEAR? Is there a strong reason to have an X/plain pair? Py_CLEAR doesn't seem to have one. This wasn't a subject of the poll. ___ 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] New poll about a macro for safe reference replacing
On Tue, Dec 22, 2015 at 3:58 AM, Serhiy Storchaka wrote: On 21.12.15 23:57, Steve Dower wrote: > >> Was Py_MOVEREF (or MOVE_REF) ever suggested? >> > > This would be nice name. The macro moves the ownership. But I think it's > too late. Otherwise we'll never finish the bikeshedding. FWIW, I like this name the best. It is increasingly popular for languages to talk about moving ownership (e.g. move semantics in C++, Rust, etc...). -- # Meador ___ 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] Typo in PEP-0423
We've played around with robots.txt, but it's still useful for old docs to be indexed (e.g., for removed features), which just need to figure out how to get them deprecation in results. I wonder if in the old docs would help. On Sat, Dec 19, 2015, at 11:02, A.M. Kuchling wrote: > On Sat, Dec 19, 2015 at 08:55:26PM +1000, Nick Coghlan wrote: > > Even once the new docs are in place, getting them to the top of search > > of results ahead of archived material that may be years out of date is > > likely to still be a challenge - for example, even considering just > > the legacy distutils docs, the "3.1" and "2" docs appear ... > > We probably need to update https://docs.python.org/robots.txt, which > currently contains: > > # Prevent development and old documentation from showing up in search > results. > User-agent: * > # Disallow: /dev > Disallow: /release > > The intent was to allow the latest version of the docs to be crawled. > Unfortunately, with the current hierarchy we'd have to disallow each > version, e.g. > > Disallow: /2.6/* > Disallow: /3.0/* > Disallow: /3.1/* > > And we'd need to update it for each new major release. > > --amk > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/benjamin%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
