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
