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] doctest and pickle
On 8 June 2013 17:41, Ethan Furman et...@stoneleaf.us 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
[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 stdin, line 1, in module
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\lrekuckipy -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\lrekuckipy -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\lrekuckipy -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
Re: [Python-Dev] chained assignment weirdity
On 7 November 2012 15:16, Chris Angelico ros...@gmail.com wrote: On Thu, Nov 8, 2012 at 1:11 AM, Nick Coghlan ncogh...@gmail.com 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
Re: [Python-Dev] Playing with a new theme for the docs
On 21 March 2012 13:38, Ned Batchelder n...@nedbatchelder.com 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 Brandlg.bra...@gmx.net 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] Data descriptor doc/implementation inconsistency
Date: Mon, 11 Jan 2010 01:51:09 +0100 From: Amaury Forgeot d'Arc amaur...@gmail.com To: Benjamin Peterson benja...@python.org Cc: Python Dev python-dev@python.org Subject: Re: [Python-Dev] Data descriptor doc/implementation inconsistency Message-ID: e27efe131001101651y68e1da25je2a8d02f5c62e...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, 2010/1/11 Benjamin Peterson benja...@python.org: 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
