Re: [Python-Dev] Status on PEP-431 Timezones
Hi, As it's very hard to keep up with the pace of this thread, instead of addressing any particular response I would like to add some (hopefully) useful context. While Java was historically known for the worst date/time handling ever (e.g. months starting with 0), in Java 8 a new module was added named javax.time[1]; It contains (amongst others) the following classes: LocalTime (= datetime.time) LocalDate (= datetime.date) LocalDateTime (= datetime.datetime without tzinfo) OffsetDateTime (= datetime.datetime + datetime.timezone) ZonedDateTime (AFAIU equivalent to how Lenart wants the datetime.datetime + IANA timezone to work) Instant (a calendar independent representation of a point in time using UTC-SLS) Duration (= datetime.timedelta) Period (e.g. 1 year, 2 months and 3 days - no real counterpart in Python) (I'm not sure which class would be equivalent to what Tim describes.) While having some Java-style boilerplate, this API is both pure and very practical. Each class serves a bit different purpose and covers different use cases without ambiguity and implicit assertions. Maybe instead of trying to decide who is "wrong" and which approach is "broken", Python just needs a more clear separation between timezone aware objects and "naive" ones? [1]: https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html Best Reagards, Łukasz Rekucki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Data descriptor doc/implementation inconsistency
> Date: Mon, 11 Jan 2010 01:51:09 +0100 > From: "Amaury Forgeot d'Arc" > To: Benjamin Peterson > Cc: Python Dev > Subject: Re: [Python-Dev] Data descriptor doc/implementation > inconsistency > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > 2010/1/11 Benjamin Peterson : >> Consider this program: >> >> class Descr(object): >> ? ?def __init__(self, name): >> ? ? ? ?self.name = name >> ? ?def __set__(self, instance, what): >> ? ? ? ?instance.__dict__[self.name] = what >> >> class X(object): >> ? ?attr = Descr("attr") >> >> x = X() >> print(x.attr) >> x.attr = 42 >> print(x.attr) >> >> It gives in output: >> >> <__main__.Descr object at 0x7fe1c9b28150> >> 42 >> >> The documentation [1] says that Descr is a data descriptor because it >> defines the __set__ method. It also states that data descriptors >> always override the value in the instance dictionary. So, the second >> line should also be the descriptor object according to the >> documentation. >> >> My question is: Is this a doc bug or a implementation bug? If the >> former, it will be the description of a data descriptor much less >> consistent, since it will require that a __get__ method be present, >> too. If the latter, the fix may break some programs relying on the >> ability to "cache" a value in the instance dictionary. >> >> [1] http://docs.python.org/reference/datamodel#invoking-descriptors > > Quoting the documentation: > """Normally, data descriptors define both __get__() and __set__(), > while non-data descriptors have just the __get__() method. > """ > Your example is neither a data descriptor nor a non-data descriptor... Actually, there is this footnote [1]: """ A descriptor can define any combination of __get__(), __set__() and __delete__(). If it does not define __get__(), then accessing the attribute even on an instance will return the descriptor object itself. If the descriptor defines __set__() and/or __delete__(), it is a data descriptor; if it defines neither, it is a non-data descriptor. """ Which would mean Descr is actually a data descriptor without a __get__(), so x.attr should always return the descriptor object itself (at least in the docs). > The thing that worries me a bit is the "x.attr" returning the Descr > object. Descriptors should remain at the class level, and instance > should only see values. I'd prefer an AttributeError in this case. > > -- > Amaury Forgeot d'Arc [1] http://docs.python.org/reference/datamodel#id7 -- Lukasz Rekucki ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doctest and pickle
On 8 June 2013 17:41, Ethan Furman wrote: > On 06/08/2013 03:09 AM, Serhiy Storchaka wrote: >> >> Is it possible to add "invisible" code which doesn't displayed in the >> resulting documentation, but taken into account by >> doctest? > > > I have no idea. This is my first time using doctest. > AFAIK, stdlib uses Sphinx, so you can provide a testsetup block[1]. At least if you're running them via Sphinx. [1]: http://sphinx-doc.org/ext/doctest.html -- Łukasz Rekucki ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
On 21 March 2012 13:38, Ned Batchelder wrote: > On 3/21/2012 6:16 AM, Oleg Broytman wrote: >> >> On Wed, Mar 21, 2012 at 09:33:13AM +, Jonathan Hartley wrote: >>> >>> On 21/03/2012 08:25, Dirkjan Ochtman wrote: >>>> >>>> On Wed, Mar 21, 2012 at 07:00, Georg Brandl wrote: >>>>> >>>>> OK, that seems to be the main point people make... let me see if I can >>>>> come up with a better compromise. >>>> >>>> Would it be possible to limit the width of the page? On my 1920px >>>> monitor, the lines get awfully long, making them harder to read. >>> >>> I realise this is bikeshedding by now, but FWIW, please don't. If >>> people want shorter lines, they can narrow their browser, without >>> forcing that preference on the rest of us. >> >> Seconded. My display is 1920x1200 but I use very large fonts and I'm >> satisfied with line lengths. > > The best thing to do is to set a max-width in ems, say 50em. This leaves the > text at a reasonable width, but adapts naturally for people with larger > fonts. > > --Ned. FYI, the current paragraph font size on docs.python.org is 16px, while for http://www.python.org/~gbrandl/build/html/ it's 13px, so increasing that should help readability :) You can use @media queries to adjust it to screen resolution, which should solve the problem with long lines. -- Łukasz Rekucki ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] chained assignment weirdity
On 7 November 2012 15:16, Chris Angelico wrote: > On Thu, Nov 8, 2012 at 1:11 AM, Nick Coghlan wrote: >> "The implementation is right, the docs are wrong" sounds good to me, >> as it's easy to justify the out of order evaluation in terms of the >> equivalent item assignment statements: > > What do other Pythons than CPython do currently? Or is it "The > reference implementation is right, the docs are wrong"? PyPy and IronPython are the same as CPython. Only Jython (both 2.5 and 2.7a) follows the docs. Regards, Łukasz Rekucki ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
Hi, I posted this (by accident) off the list: > On 2012-11-14, at 23:43 , Chris Withers wrote: > >> On 14/11/2012 22:37, Chris Withers wrote: >>> On 14/11/2012 10:11, mar...@v.loewis.de wrote: >>>> def xdict(**kwds): >>>> return kwds >>> >>> Hah, good call, this trumps both of the other options: >>> >>> 100 -r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' >>> raw times: 0.548 0.533 0.55 0.577 0.539 >>> 100 loops, best of 5: 0.533 usec per loop No, this just doesn't execute the right code: >>> def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7) ... >>> import dis >>> dis.dis(md) 1 0 LOAD_FAST0 (kw) 3 RETURN_VALUE 4 LOAD_GLOBAL 0 (md) 7 LOAD_CONST 1 ('a') 10 LOAD_CONST 2 (1) 13 LOAD_CONST 3 ('b') 16 LOAD_CONST 4 (2) 19 LOAD_CONST 5 ('c') 22 LOAD_CONST 6 (3) 25 LOAD_CONST 7 ('d') 28 LOAD_CONST 8 (4) 31 LOAD_CONST 9 ('e') 34 LOAD_CONST 10 (5) 37 LOAD_CONST 11 ('f') 40 LOAD_CONST 12 (6) 43 LOAD_CONST 13 ('g') 46 LOAD_CONST 14 (7) 49 CALL_FUNCTION 1792 52 POP_TOP Also: Python 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> dict({1: "foo"}, **{frozenset([2]): "bar"}) Traceback (most recent call last): File "", line 1, in TypeError: keyword arguments must be strings While: Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> dict({1: "foo"}, **{2: "bar"}) {1: 'foo', 2: 'bar'} >>> dict({1: "foo"}, **{frozenset([2]): "bar"}) {1: 'foo', frozenset([2]): 'bar'} If you're worrying about global lookup, you should stop (in this case): $ py -3.3 -m timeit -n 100 -r 5 -v -s "def xdict(): return dict()" "xdict()" raw times: 0.477 0.47 0.468 0.473 0.469 100 loops, best of 5: 0.468 usec per loop $ py -3.3 -m timeit -n 100 -r 5 -v -s "def xdict(dict=dict): return dict()" "xdict()" raw times: 0.451 0.45 0.451 0.45 0.449 100 loops, best of 5: 0.449 usec per loop $ py -3.3 -m timeit -n 100 -r 5 -v -s "def xdict(dict=lambda **kw: kw): return dict()" "xdict()" raw times: 0.433 0.434 0.435 0.435 0.431 100 loops, best of 5: 0.431 usec per loop $ py -3.3 -m timeit -n 100 -r 5 -v -s "def xdict(dict=dict): return {}" "xdict()" raw times: 0.276 0.279 0.279 0.277 0.275 100 loops, best of 5: 0.275 usec per loop And using non-empty dicts doesn't change much and the first one is roughly the sum of the latter two (as expected): C:\Users\lrekucki>py -3.3 -m timeit -n 100 -r 5 -v -s "def xdict(dict=dict): return dict(a=1, b=2, c=3, d=4, e=5, f=6)" "xdict()" raw times: 1.72 1.71 1.71 1.71 1.71 100 loops, best of 5: 1.71 usec per loop C:\Users\lrekucki>py -3.3 -m timeit -n 100 -r 5 -v -s "def xdict(dict=lambda **kw: kw): return dict(a=1, b=2, c=3, d=4, e=5, f=6)" "xdict()" raw times: 1.01 1.01 1.01 1.01 1.01 100 loops, best of 5: 1.01 usec per loop C:\Users\lrekucki>py -3.3 -m timeit -n 100 -r 5 -v -s "def xdict(dict=dict): return {'a': 1, 'b': 2, 'c': 3, 'd': 4, 'e': 5, 'f': 6}" "xdict()" raw times: 0.744 0.736 0.735 0.733 0.733 100 loops, best of 5: 0.733 usec per loop I hope that this helps move python-dev's focus to some more useful discussion. -- Łukasz Rekucki ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com