From robert.s.cohn at intel.com  Wed Jul  1 15:38:07 2015
From: robert.s.cohn at intel.com (Cohn, Robert S)
Date: Wed, 1 Jul 2015 13:38:07 +0000
Subject: [Python-Dev] Backporting the 3.5+ Windows build project files
	to 2.7
Message-ID: <017981773BBEDE44A0F34FBEE7EAF2DA32001276@ORSMSX113.amr.corp.intel.com>

Please contact Robert.S.Cohn at intel.com if you want a free license to intel compilers or tools.

From: "M.-A. Lemburg" <mal at egenix.com<mailto:mal at egenix.com>>

?  BTW: I remember there was some discussion a while ago to get ICC licenses to core devs. Has there been any progress
on this ?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150701/8a63023f/attachment.html>

From greg.ewing at canterbury.ac.nz  Thu Jul  2 00:02:52 2015
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 02 Jul 2015 10:02:52 +1200
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <5592F074.7010904@mail.de>
References: <558AF376.30607@mail.de> <558B1034.6080504@gmail.com>
 <558B1F72.9000409@mail.de> <20150625021659.GS20701@ando.pearwood.info>
 <558C2489.2080305@mail.de>
 <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de>
Message-ID: <5594638C.1060401@canterbury.ac.nz>

Sven R. Kunze wrote:
> I like the 'await' syntax to mark suspension points. But the 'async' 
> coloring makes no sense to me. It is an implementation details of 
> asyncio (IMHO).

Functions containing an "await" are going to be coloured
in any case -- that's unavoidable, given that await is
built on the iterator protocol. The only question is
whether to have an explicit marker for it.

-- 
Greg

From srkunze at mail.de  Thu Jul  2 22:55:09 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Thu, 02 Jul 2015 22:55:09 +0200
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <5594638C.1060401@canterbury.ac.nz>
References: <558AF376.30607@mail.de> <558B1034.6080504@gmail.com>
 <558B1F72.9000409@mail.de> <20150625021659.GS20701@ando.pearwood.info>
 <558C2489.2080305@mail.de>
 <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de> <5594638C.1060401@canterbury.ac.nz>
Message-ID: <5595A52D.9040909@mail.de>

My understanding of coloring is "needs special treatment".

Being special or not (containing an 'await' or not), as long as I don't 
need to care, I can call them either way (with 'await' or not) and each 
case works sensibly that's fine with me.

Sensible would be something similar to:

call function: business as usual
await function: suspension point and runs the function until completion
call awaitable: runs the awaitable until completion
await awaitable: suspension point and could be suspended internally as well

On 02.07.2015 00:02, Greg Ewing wrote:
> Sven R. Kunze wrote:
>> I like the 'await' syntax to mark suspension points. But the 'async' 
>> coloring makes no sense to me. It is an implementation details of 
>> asyncio (IMHO).
>
> Functions containing an "await" are going to be coloured
> in any case -- that's unavoidable, given that await is
> built on the iterator protocol. The only question is
> whether to have an explicit marker for it.
>


From ncoghlan at gmail.com  Fri Jul  3 11:40:04 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 3 Jul 2015 19:40:04 +1000
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <5595A52D.9040909@mail.de>
References: <558AF376.30607@mail.de> <558B1034.6080504@gmail.com>
 <558B1F72.9000409@mail.de>
 <20150625021659.GS20701@ando.pearwood.info>
 <558C2489.2080305@mail.de>
 <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de> <5594638C.1060401@canterbury.ac.nz>
 <5595A52D.9040909@mail.de>
Message-ID: <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>

On 3 July 2015 at 06:55, Sven R. Kunze <srkunze at mail.de> wrote:
> My understanding of coloring is "needs special treatment".
>
> Being special or not (containing an 'await' or not), as long as I don't need
> to care, I can call them either way (with 'await' or not) and each case
> works sensibly that's fine with me.

I'm afraid you're going to be disappointed in that regard, as wishing
that event driven programs behaved more like synchronous programs is
like wishing that complex numbers behaved like real numbers. There's
an extra level of complexity that is being deliberately introduced in
order to improve Python's ability to express certain kinds of
algorithms, and it isn't effective to just try to wish that complexity
away.

The payoff is that code that otherwise needs to be written as a long
series of disconnected callback chains (as has long been possible with
Twisted) can instead be written to look more like comparable
synchronous code (and this approach should bring with it much improved
introspection support, at least in 3.5+ now that gi_yieldfrom and
cr_await are being exposed at the Python level).

> Sensible would be something similar to:
> await function: suspension point and runs the function until completion
> call awaitable: runs the awaitable until completion

These both fail, and deliberately so: we don't know what they're
supposed to mean, and we refuse the temptation to guess. They're also
quite likely to indicate a bug (e.g. forgetting to call a native
coroutine function to get the coroutine out of it, forgetting to wait
for an awaitable) rather than something folks have done deliberately.

It's possible shorthand adapters may emerge over time, like:

    # Call awaitable from synchronous code
    def wait_for_result(awaitable):
        """Usage: result = asyncio.wait_for_result(awaitable)"""
       return asyncio.get_event_loop().run_until_complete(awaitable.__await__())

    # Call blocking operation from asynchronous code
   def blocking_call(f, *args, **kwds):
        """Usage: result = await asyncio.blocking_call(f, *args, **kwds))"""
        cb = functools.partial(f, *args, **kwds)
        return asyncio.get_event_loop().run_in_executor(cb)

However, those can be written already as utility functions, so we can
wait and see how strong the demand is for them as adapters. (They may
also be potentially useful to have as recipes in the documentation)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From status at bugs.python.org  Fri Jul  3 18:08:22 2015
From: status at bugs.python.org (Python tracker)
Date: Fri,  3 Jul 2015 18:08:22 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150703160822.BFF7656675@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-06-26 - 2015-07-03)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4922 (+14)
  closed 31399 (+30)
  total  36321 (+44)

Open issues with patches: 2255 


Issues opened (27)
==================

#3530: ast.NodeTransformer doc bug
http://bugs.python.org/issue3530  reopened by terry.reedy

#24400: Awaitable ABC incompatible with functools.singledispatch
http://bugs.python.org/issue24400  reopened by r.david.murray

#24458: Documentation for PEP 489
http://bugs.python.org/issue24458  reopened by ncoghlan

#24518: json.dumps should accept key function for ``sort_keys``
http://bugs.python.org/issue24518  opened by catherinedevlin

#24520: Stop using deprecated floating-point environment functions on 
http://bugs.python.org/issue24520  opened by Andrew Turner

#24524: python crash using Tkinter
http://bugs.python.org/issue24524  opened by tomnor

#24525: [doc] missing word
http://bugs.python.org/issue24525  opened by vincent-legoll

#24527: The MimeTypes class cannot ignore global files per instance
http://bugs.python.org/issue24527  opened by Sebastian Noack

#24531: please document that no code preceding encoding declaration is
http://bugs.python.org/issue24531  opened by jwilk

#24532: asyncio.sock_recv() blocks normal ioloop actions.
http://bugs.python.org/issue24532  opened by mmarkk

#24533: Increased Test Coverage for Lib/random.py
http://bugs.python.org/issue24533  opened by Charles Nodell

#24536: os.pipe() should return a structsequence (or namedtuple.)
http://bugs.python.org/issue24536  opened by jonathan.slenders

#24538: os.setxattr PermissionError on panfs propagates up causing `co
http://bugs.python.org/issue24538  opened by Gerrit.Holl

#24539: StreamReaderProtocol.eof_received() should return True to keep
http://bugs.python.org/issue24539  opened by gvanrossum

#24540: Documentation about skipkeys parameter for json.dumps is incor
http://bugs.python.org/issue24540  opened by Matthew Havard

#24542: ssl - SSL_OP_NO_TICKET not reimplemented
http://bugs.python.org/issue24542  opened by miniCruzer

#24544: Race condition and crash when embedding multi-thread script
http://bugs.python.org/issue24544  opened by Oleksiy Markovets

#24545: Issue with ssl package
http://bugs.python.org/issue24545  opened by kxl561

#24546: sequence index bug in random.choice
http://bugs.python.org/issue24546  opened by Serge Anuchin

#24548: Broken link in the unittest documentation
http://bugs.python.org/issue24548  opened by wau

#24549: string.format() should have a safe_substitute equivalent, to b
http://bugs.python.org/issue24549  opened by azrdev

#24550: maxint on 64 bit platforms breaks os.read
http://bugs.python.org/issue24550  opened by Brian Mingus

#24553: improve test coverage for subinterpreters
http://bugs.python.org/issue24553  opened by eric.snow

#24554: GC should happen when a subinterpreter is destroyed
http://bugs.python.org/issue24554  opened by eric.snow

#24555: Python logic error when deal with re and muti-threading
http://bugs.python.org/issue24555  opened by bee13oy

#24557: Refactor LibreSSL / EGD detection
http://bugs.python.org/issue24557  opened by spil

#24560: codecs.StreamReader doesn't work with nonblocking streams: Typ
http://bugs.python.org/issue24560  opened by yac



Most recent 15 issues with no replies (15)
==========================================

#24560: codecs.StreamReader doesn't work with nonblocking streams: Typ
http://bugs.python.org/issue24560

#24557: Refactor LibreSSL / EGD detection
http://bugs.python.org/issue24557

#24550: maxint on 64 bit platforms breaks os.read
http://bugs.python.org/issue24550

#24548: Broken link in the unittest documentation
http://bugs.python.org/issue24548

#24542: ssl - SSL_OP_NO_TICKET not reimplemented
http://bugs.python.org/issue24542

#24539: StreamReaderProtocol.eof_received() should return True to keep
http://bugs.python.org/issue24539

#24527: The MimeTypes class cannot ignore global files per instance
http://bugs.python.org/issue24527

#24525: [doc] missing word
http://bugs.python.org/issue24525

#24524: python crash using Tkinter
http://bugs.python.org/issue24524

#24520: Stop using deprecated floating-point environment functions on 
http://bugs.python.org/issue24520

#24512: multiprocessing should log a warning when forking multithreade
http://bugs.python.org/issue24512

#24499: Python Installer text piles up during installation process
http://bugs.python.org/issue24499

#24498: Should ptags and eptags be removed from repo?
http://bugs.python.org/issue24498

#24477: In argparse subparser's option goes to parent parser
http://bugs.python.org/issue24477

#24466: extend_path explanation in documentation is ambiguous
http://bugs.python.org/issue24466



Most recent 15 issues waiting for review (15)
=============================================

#24557: Refactor LibreSSL / EGD detection
http://bugs.python.org/issue24557

#24536: os.pipe() should return a structsequence (or namedtuple.)
http://bugs.python.org/issue24536

#24533: Increased Test Coverage for Lib/random.py
http://bugs.python.org/issue24533

#24520: Stop using deprecated floating-point environment functions on 
http://bugs.python.org/issue24520

#24518: json.dumps should accept key function for ``sort_keys``
http://bugs.python.org/issue24518

#24508: Backport 3.5's Windows build project files to 2.7
http://bugs.python.org/issue24508

#24506: make fails with gcc 4.9 due to fatal warning of unused variabl
http://bugs.python.org/issue24506

#24485: Function source inspection fails on closures
http://bugs.python.org/issue24485

#24483: Avoid repeated hash calculation in C implementation of functoo
http://bugs.python.org/issue24483

#24468: Expose C level compiler flag constants to Python code
http://bugs.python.org/issue24468

#24465: Make tarfile have deterministic sorting
http://bugs.python.org/issue24465

#24464: Got warning when compiling sqlite3 module on Mac OS X
http://bugs.python.org/issue24464

#24458: Documentation for PEP 489
http://bugs.python.org/issue24458

#24452: Make webbrowser support Chrome on Mac OS X
http://bugs.python.org/issue24452

#24451: Add metrics to future objects (concurrent or asyncio?)
http://bugs.python.org/issue24451



Top 10 most discussed issues (10)
=================================

#24400: Awaitable ABC incompatible with functools.singledispatch
http://bugs.python.org/issue24400  18 msgs

#24546: sequence index bug in random.choice
http://bugs.python.org/issue24546  15 msgs

#24432: Upgrade windows builds to use OpenSSL 1.0.2b
http://bugs.python.org/issue24432   9 msgs

#24554: GC should happen when a subinterpreter is destroyed
http://bugs.python.org/issue24554   9 msgs

#24536: os.pipe() should return a structsequence (or namedtuple.)
http://bugs.python.org/issue24536   8 msgs

#23496: Steps for Android Native Build of Python 3.4.2
http://bugs.python.org/issue23496   7 msgs

#18543: urllib.parse.urlopen shouldn't ignore installed opener when ca
http://bugs.python.org/issue18543   6 msgs

#24325: Speedup types.coroutine()
http://bugs.python.org/issue24325   6 msgs

#20387: tokenize/untokenize roundtrip fails with tabs
http://bugs.python.org/issue20387   5 msgs

#23517: datetime.utcfromtimestamp parses timestamps incorrectly
http://bugs.python.org/issue23517   5 msgs



Issues closed (32)
==================

#19176: DeprecationWarning for doctype() method when subclassing _elem
http://bugs.python.org/issue19176  closed by serhiy.storchaka

#19235: Add a dedicated subclass for recursion errors
http://bugs.python.org/issue19235  closed by yselivanov

#22126: mc68881 fpcr inline asm breaks clang -flto build
http://bugs.python.org/issue22126  closed by skrah

#23974: random.randrange() biased output
http://bugs.python.org/issue23974  closed by rhettinger

#24336: Allow arbitrary keywords to @contextmanager functions
http://bugs.python.org/issue24336  closed by serhiy.storchaka

#24450: Add cr_await calculated property to coroutine object
http://bugs.python.org/issue24450  closed by yselivanov

#24456: audioop.adpcm2lin Buffer Over-read
http://bugs.python.org/issue24456  closed by serhiy.storchaka

#24462: bytearray.find Buffer Over-read
http://bugs.python.org/issue24462  closed by serhiy.storchaka

#24467: bytearray pop and remove Buffer Over-read
http://bugs.python.org/issue24467  closed by serhiy.storchaka

#24481: hotshot pack_string Heap Buffer Overflow
http://bugs.python.org/issue24481  closed by python-dev

#24514: tarfile fails to extract archive (handled fine by gnu tar and 
http://bugs.python.org/issue24514  closed by lars.gustaebel

#24515: docstring of isinstance
http://bugs.python.org/issue24515  closed by steven.daprano

#24517: %z does not work in time.strftime()
http://bugs.python.org/issue24517  closed by r.david.murray

#24519: multiprocessing.Pool with maxtasksperchild starts too many pro
http://bugs.python.org/issue24519  closed by Zahari.Dim

#24521: Integer overflow in _pickle.c
http://bugs.python.org/issue24521  closed by benjamin.peterson

#24522: Integer overflow in _json_encode_unicode leads to crash (heap-
http://bugs.python.org/issue24522  closed by python-dev

#24523: coroutine asyncio.wait() does not preserve order of elements
http://bugs.python.org/issue24523  closed by gvanrossum

#24526: Exponent function bug
http://bugs.python.org/issue24526  closed by r.david.murray

#24528: Misleading exeption for await in comprehensions.
http://bugs.python.org/issue24528  closed by yselivanov

#24529: Same MemoryError object gets thrown from different places.
http://bugs.python.org/issue24529  closed by r.david.murray

#24530: `import..as` fails where `import` does not
http://bugs.python.org/issue24530  closed by vadmium

#24534: disable executing code in .pth files
http://bugs.python.org/issue24534  closed by minrk

#24535: SELinux reporting writes, executes, and dac_overwrites
http://bugs.python.org/issue24535  closed by ned.deily

#24537: Py_Initialize unable to load the file system codec
http://bugs.python.org/issue24537  closed by tim.golden

#24541: test_eightteen() in test_inspect out of sync with documentatio
http://bugs.python.org/issue24541  closed by yselivanov

#24543: Configure script wrongly detects x64/x87/mc68881 with -flto op
http://bugs.python.org/issue24543  closed by skrah

#24547: What???s New In Python 3.4: stray "("
http://bugs.python.org/issue24547  closed by python-dev

#24551: byte conversion
http://bugs.python.org/issue24551  closed by steven.daprano

#24552: use after free in load_newobj_ex
http://bugs.python.org/issue24552  closed by python-dev

#24556: Getopt overwrites variables unexpectedly
http://bugs.python.org/issue24556  closed by r.david.murray

#24558: shutil.copytree with symlinks=True opens vulnerabilities
http://bugs.python.org/issue24558  closed by spaceone

#24559: online Python docs scroll in a godawful ugly fashion
http://bugs.python.org/issue24559  closed by skrah

From tjreedy at udel.edu  Sat Jul  4 09:54:20 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 4 Jul 2015 03:54:20 -0400
Subject: [Python-Dev] Should asyncio ignore KeyboardInterrupt?
Message-ID: <mn83fd$rkm$1@ger.gmane.org>

Should the loop.run... methods of asyncio respect KeyboardInterrupt (^C)?

Developer and user convenience and this paragraph in PEP

"However, exceptions deriving only from BaseException are typically not 
caught, and will usually cause the program to terminate with a 
traceback. In some cases they are caught and re-raised. (Examples of 
this category include KeyboardInterrupt and SystemExit ; it is usually 
unwise to treat these the same as most other exceptions.) "

and this examples in the doc (two places)

TCP echo server
     # Serve requests until CTRL+c is pressed
     print('Serving on {}'.format(server.sockets[0].getsockname()))
     try:
         loop.run_forever()
     except KeyboardInterrupt:
         pass

suggest yes.  On the other hand, the section on
"Set signal handlers for SIGINT and SIGTERM"
suggests not, unless an explicit handler is registered and then only on 
Unix.

In any case, Adam Bartos, python-list, "An asyncio example", today asks.
'''
This is a minimal example:

import asyncio

async def wait():
     await asyncio.sleep(5)

loop = asyncio.get_event_loop()
loop.run_until_complete(wait())

Ctrl-C doesn't interrupt the waiting, instead KeyboardInterrupt occurs 
after those five seconds. It's 3.5.0b2 on Windows. Is it a bug?
'''

Using run_forever instead, I found no way to stop other than killing the 
process (Idle or Command Prompt).

-- 
Terry Jan Reedy


From guido at python.org  Sat Jul  4 17:46:34 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 4 Jul 2015 17:46:34 +0200
Subject: [Python-Dev] Should asyncio ignore KeyboardInterrupt?
In-Reply-To: <mn83fd$rkm$1@ger.gmane.org>
References: <mn83fd$rkm$1@ger.gmane.org>
Message-ID: <CAP7+vJL_x--J9Ti_Dq1zecJL_TZZT0Hx-qKrhjKA+ZAGViUiZw@mail.gmail.com>

I think this may be more of a Windows issue than an asyncio issue. I agree
that ideally ^C should take effect immediately (as it does on UNIX).

On Sat, Jul 4, 2015 at 9:54 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> Should the loop.run... methods of asyncio respect KeyboardInterrupt (^C)?
>
> Developer and user convenience and this paragraph in PEP
>
> "However, exceptions deriving only from BaseException are typically not
> caught, and will usually cause the program to terminate with a traceback.
> In some cases they are caught and re-raised. (Examples of this category
> include KeyboardInterrupt and SystemExit ; it is usually unwise to treat
> these the same as most other exceptions.) "
>
> and this examples in the doc (two places)
>
> TCP echo server
>     # Serve requests until CTRL+c is pressed
>     print('Serving on {}'.format(server.sockets[0].getsockname()))
>     try:
>         loop.run_forever()
>     except KeyboardInterrupt:
>         pass
>
> suggest yes.  On the other hand, the section on
> "Set signal handlers for SIGINT and SIGTERM"
> suggests not, unless an explicit handler is registered and then only on
> Unix.
>
> In any case, Adam Bartos, python-list, "An asyncio example", today asks.
> '''
> This is a minimal example:
>
> import asyncio
>
> async def wait():
>     await asyncio.sleep(5)
>
> loop = asyncio.get_event_loop()
> loop.run_until_complete(wait())
>
> Ctrl-C doesn't interrupt the waiting, instead KeyboardInterrupt occurs
> after those five seconds. It's 3.5.0b2 on Windows. Is it a bug?
> '''
>
> Using run_forever instead, I found no way to stop other than killing the
> process (Idle or Command Prompt).
>
> --
> Terry Jan Reedy
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150704/1dc06fb7/attachment.html>

From rdmurray at bitdance.com  Sat Jul  4 19:49:42 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 04 Jul 2015 13:49:42 -0400
Subject: [Python-Dev] Should asyncio ignore KeyboardInterrupt?
In-Reply-To: <CAP7+vJL_x--J9Ti_Dq1zecJL_TZZT0Hx-qKrhjKA+ZAGViUiZw@mail.gmail.com>
References: <mn83fd$rkm$1@ger.gmane.org>
 <CAP7+vJL_x--J9Ti_Dq1zecJL_TZZT0Hx-qKrhjKA+ZAGViUiZw@mail.gmail.com>
Message-ID: <20150704174942.E9DE4250EA5@webabinitio.net>

Once long ago in Internet time (issue 581232) time.sleep on windows was
not interruptible and this was fixed.  Is it possible the work on EINTR
has broken that fix?

(I don't currently have 3.5 installed on windows to test that theory...)

On Sat, 04 Jul 2015 17:46:34 +0200, Guido van Rossum <guido at python.org> wrote:
> I think this may be more of a Windows issue than an asyncio issue. I agree
> that ideally ^C should take effect immediately (as it does on UNIX).
> 
> On Sat, Jul 4, 2015 at 9:54 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> > Should the loop.run... methods of asyncio respect KeyboardInterrupt (^C)?
> >
> > Developer and user convenience and this paragraph in PEP
> >
> > "However, exceptions deriving only from BaseException are typically not
> > caught, and will usually cause the program to terminate with a traceback.
> > In some cases they are caught and re-raised. (Examples of this category
> > include KeyboardInterrupt and SystemExit ; it is usually unwise to treat
> > these the same as most other exceptions.) "
> >
> > and this examples in the doc (two places)
> >
> > TCP echo server
> >     # Serve requests until CTRL+c is pressed
> >     print('Serving on {}'.format(server.sockets[0].getsockname()))
> >     try:
> >         loop.run_forever()
> >     except KeyboardInterrupt:
> >         pass
> >
> > suggest yes.  On the other hand, the section on
> > "Set signal handlers for SIGINT and SIGTERM"
> > suggests not, unless an explicit handler is registered and then only on
> > Unix.
> >
> > In any case, Adam Bartos, python-list, "An asyncio example", today asks.
> > '''
> > This is a minimal example:
> >
> > import asyncio
> >
> > async def wait():
> >     await asyncio.sleep(5)
> >
> > loop = asyncio.get_event_loop()
> > loop.run_until_complete(wait())
> >
> > Ctrl-C doesn't interrupt the waiting, instead KeyboardInterrupt occurs
> > after those five seconds. It's 3.5.0b2 on Windows. Is it a bug?
> > '''
> >
> > Using run_forever instead, I found no way to stop other than killing the
> > process (Idle or Command Prompt).
> >
> > --
> > Terry Jan Reedy
> >
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > 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
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com

From guido at python.org  Sat Jul  4 21:58:43 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 4 Jul 2015 21:58:43 +0200
Subject: [Python-Dev] Should asyncio ignore KeyboardInterrupt?
In-Reply-To: <20150704174942.E9DE4250EA5@webabinitio.net>
References: <mn83fd$rkm$1@ger.gmane.org>
 <CAP7+vJL_x--J9Ti_Dq1zecJL_TZZT0Hx-qKrhjKA+ZAGViUiZw@mail.gmail.com>
 <20150704174942.E9DE4250EA5@webabinitio.net>
Message-ID: <CAP7+vJK91GaaGRcLfmBOH5UGmax1V0dSDOQLUeidrL054NmhMw@mail.gmail.com>

It's possible, but AFAIK asyncio.sleep() has nothing in common with
time.sleep() -- it's implemented as a timeout on select() or on the IOCP
loop. (I also have no access to Windows ATM.)

On Sat, Jul 4, 2015 at 7:49 PM, R. David Murray <rdmurray at bitdance.com>
wrote:

> Once long ago in Internet time (issue 581232) time.sleep on windows was
> not interruptible and this was fixed.  Is it possible the work on EINTR
> has broken that fix?
>
> (I don't currently have 3.5 installed on windows to test that theory...)
>
> On Sat, 04 Jul 2015 17:46:34 +0200, Guido van Rossum <guido at python.org>
> wrote:
> > I think this may be more of a Windows issue than an asyncio issue. I
> agree
> > that ideally ^C should take effect immediately (as it does on UNIX).
> >
> > On Sat, Jul 4, 2015 at 9:54 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> >
> > > Should the loop.run... methods of asyncio respect KeyboardInterrupt
> (^C)?
> > >
> > > Developer and user convenience and this paragraph in PEP
> > >
> > > "However, exceptions deriving only from BaseException are typically not
> > > caught, and will usually cause the program to terminate with a
> traceback.
> > > In some cases they are caught and re-raised. (Examples of this category
> > > include KeyboardInterrupt and SystemExit ; it is usually unwise to
> treat
> > > these the same as most other exceptions.) "
> > >
> > > and this examples in the doc (two places)
> > >
> > > TCP echo server
> > >     # Serve requests until CTRL+c is pressed
> > >     print('Serving on {}'.format(server.sockets[0].getsockname()))
> > >     try:
> > >         loop.run_forever()
> > >     except KeyboardInterrupt:
> > >         pass
> > >
> > > suggest yes.  On the other hand, the section on
> > > "Set signal handlers for SIGINT and SIGTERM"
> > > suggests not, unless an explicit handler is registered and then only on
> > > Unix.
> > >
> > > In any case, Adam Bartos, python-list, "An asyncio example", today
> asks.
> > > '''
> > > This is a minimal example:
> > >
> > > import asyncio
> > >
> > > async def wait():
> > >     await asyncio.sleep(5)
> > >
> > > loop = asyncio.get_event_loop()
> > > loop.run_until_complete(wait())
> > >
> > > Ctrl-C doesn't interrupt the waiting, instead KeyboardInterrupt occurs
> > > after those five seconds. It's 3.5.0b2 on Windows. Is it a bug?
> > > '''
> > >
> > > Using run_forever instead, I found no way to stop other than killing
> the
> > > process (Idle or Command Prompt).
> > >
> > > --
> > > Terry Jan Reedy
> > >
> > > _______________________________________________
> > > Python-Dev mailing list
> > > Python-Dev at python.org
> > > 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
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150704/956c5891/attachment.html>

From andrew.svetlov at gmail.com  Sat Jul  4 22:06:14 2015
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Sat, 4 Jul 2015 23:06:14 +0300
Subject: [Python-Dev] Should asyncio ignore KeyboardInterrupt?
In-Reply-To: <CAP7+vJK91GaaGRcLfmBOH5UGmax1V0dSDOQLUeidrL054NmhMw@mail.gmail.com>
References: <mn83fd$rkm$1@ger.gmane.org>
 <CAP7+vJL_x--J9Ti_Dq1zecJL_TZZT0Hx-qKrhjKA+ZAGViUiZw@mail.gmail.com>
 <20150704174942.E9DE4250EA5@webabinitio.net>
 <CAP7+vJK91GaaGRcLfmBOH5UGmax1V0dSDOQLUeidrL054NmhMw@mail.gmail.com>
Message-ID: <CAL3CFcXY3w=UFx7Tzc1VTBJgYwcWaa6jUavhz6ebCokP8TLv_Q@mail.gmail.com>

I believe it's a bug #23057 http://bugs.python.org/issue23057

On Sat, Jul 4, 2015 at 10:58 PM, Guido van Rossum <guido at python.org> wrote:
> It's possible, but AFAIK asyncio.sleep() has nothing in common with
> time.sleep() -- it's implemented as a timeout on select() or on the IOCP
> loop. (I also have no access to Windows ATM.)
>
> On Sat, Jul 4, 2015 at 7:49 PM, R. David Murray <rdmurray at bitdance.com>
> wrote:
>>
>> Once long ago in Internet time (issue 581232) time.sleep on windows was
>> not interruptible and this was fixed.  Is it possible the work on EINTR
>> has broken that fix?
>>
>> (I don't currently have 3.5 installed on windows to test that theory...)
>>
>> On Sat, 04 Jul 2015 17:46:34 +0200, Guido van Rossum <guido at python.org>
>> wrote:
>> > I think this may be more of a Windows issue than an asyncio issue. I
>> > agree
>> > that ideally ^C should take effect immediately (as it does on UNIX).
>> >
>> > On Sat, Jul 4, 2015 at 9:54 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>> >
>> > > Should the loop.run... methods of asyncio respect KeyboardInterrupt
>> > > (^C)?
>> > >
>> > > Developer and user convenience and this paragraph in PEP
>> > >
>> > > "However, exceptions deriving only from BaseException are typically
>> > > not
>> > > caught, and will usually cause the program to terminate with a
>> > > traceback.
>> > > In some cases they are caught and re-raised. (Examples of this
>> > > category
>> > > include KeyboardInterrupt and SystemExit ; it is usually unwise to
>> > > treat
>> > > these the same as most other exceptions.) "
>> > >
>> > > and this examples in the doc (two places)
>> > >
>> > > TCP echo server
>> > >     # Serve requests until CTRL+c is pressed
>> > >     print('Serving on {}'.format(server.sockets[0].getsockname()))
>> > >     try:
>> > >         loop.run_forever()
>> > >     except KeyboardInterrupt:
>> > >         pass
>> > >
>> > > suggest yes.  On the other hand, the section on
>> > > "Set signal handlers for SIGINT and SIGTERM"
>> > > suggests not, unless an explicit handler is registered and then only
>> > > on
>> > > Unix.
>> > >
>> > > In any case, Adam Bartos, python-list, "An asyncio example", today
>> > > asks.
>> > > '''
>> > > This is a minimal example:
>> > >
>> > > import asyncio
>> > >
>> > > async def wait():
>> > >     await asyncio.sleep(5)
>> > >
>> > > loop = asyncio.get_event_loop()
>> > > loop.run_until_complete(wait())
>> > >
>> > > Ctrl-C doesn't interrupt the waiting, instead KeyboardInterrupt occurs
>> > > after those five seconds. It's 3.5.0b2 on Windows. Is it a bug?
>> > > '''
>> > >
>> > > Using run_forever instead, I found no way to stop other than killing
>> > > the
>> > > process (Idle or Command Prompt).
>> > >
>> > > --
>> > > Terry Jan Reedy
>> > >
>> > > _______________________________________________
>> > > Python-Dev mailing list
>> > > Python-Dev at python.org
>> > > 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
>> > Python-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/python-dev
>> > Unsubscribe:
>> > https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> 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
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com
>



-- 
Thanks,
Andrew Svetlov

From tjreedy at udel.edu  Sat Jul  4 22:23:38 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 4 Jul 2015 16:23:38 -0400
Subject: [Python-Dev] Should asyncio ignore KeyboardInterrupt?
In-Reply-To: <CAL3CFcXY3w=UFx7Tzc1VTBJgYwcWaa6jUavhz6ebCokP8TLv_Q@mail.gmail.com>
References: <mn83fd$rkm$1@ger.gmane.org>
 <CAP7+vJL_x--J9Ti_Dq1zecJL_TZZT0Hx-qKrhjKA+ZAGViUiZw@mail.gmail.com>
 <20150704174942.E9DE4250EA5@webabinitio.net>
 <CAP7+vJK91GaaGRcLfmBOH5UGmax1V0dSDOQLUeidrL054NmhMw@mail.gmail.com>
 <CAL3CFcXY3w=UFx7Tzc1VTBJgYwcWaa6jUavhz6ebCokP8TLv_Q@mail.gmail.com>
Message-ID: <mn9fcc$b6h$2@ger.gmane.org>

On 7/4/2015 4:06 PM, Andrew Svetlov wrote:
> I believe it's a bug #23057 http://bugs.python.org/issue23057
>
> On Sat, Jul 4, 2015 at 10:58 PM, Guido van Rossum <guido at python.org> wrote:
>> It's possible, but AFAIK asyncio.sleep() has nothing in common with
>> time.sleep() -- it's implemented as a timeout on select() or on the IOCP
>> loop. (I also have no access to Windows ATM.)

Thanks all.  I replied back to OP on python-list.

-- 
Terry Jan Reedy


From victor.stinner at gmail.com  Sun Jul  5 00:14:17 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sun, 5 Jul 2015 00:14:17 +0200
Subject: [Python-Dev] Should asyncio ignore KeyboardInterrupt?
In-Reply-To: <mn83fd$rkm$1@ger.gmane.org>
References: <mn83fd$rkm$1@ger.gmane.org>
Message-ID: <CAMpsgwb_nhjrN+TpOPNS-NyFGCFgVT5rhP7NUR7d2ZBRxukYVA@mail.gmail.com>

Signal handling is not implemented in asyncio on Windows. I have  working
patch for that somewhere, it's not merged yet.

UDP and SSL are also missing on Windows. Good news: SSL support comes with
Python 3.5!

Victor
Le 4 juil. 2015 09:55, "Terry Reedy" <tjreedy at udel.edu> a ?crit :

> Should the loop.run... methods of asyncio respect KeyboardInterrupt (^C)?
>
> Developer and user convenience and this paragraph in PEP
>
> "However, exceptions deriving only from BaseException are typically not
> caught, and will usually cause the program to terminate with a traceback.
> In some cases they are caught and re-raised. (Examples of this category
> include KeyboardInterrupt and SystemExit ; it is usually unwise to treat
> these the same as most other exceptions.) "
>
> and this examples in the doc (two places)
>
> TCP echo server
>     # Serve requests until CTRL+c is pressed
>     print('Serving on {}'.format(server.sockets[0].getsockname()))
>     try:
>         loop.run_forever()
>     except KeyboardInterrupt:
>         pass
>
> suggest yes.  On the other hand, the section on
> "Set signal handlers for SIGINT and SIGTERM"
> suggests not, unless an explicit handler is registered and then only on
> Unix.
>
> In any case, Adam Bartos, python-list, "An asyncio example", today asks.
> '''
> This is a minimal example:
>
> import asyncio
>
> async def wait():
>     await asyncio.sleep(5)
>
> loop = asyncio.get_event_loop()
> loop.run_until_complete(wait())
>
> Ctrl-C doesn't interrupt the waiting, instead KeyboardInterrupt occurs
> after those five seconds. It's 3.5.0b2 on Windows. Is it a bug?
> '''
>
> Using run_forever instead, I found no way to stop other than killing the
> process (Idle or Command Prompt).
>
> --
> Terry Jan Reedy
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150705/e80e05ef/attachment.html>

From drekin at gmail.com  Sun Jul  5 12:49:21 2015
From: drekin at gmail.com (drekin at gmail.com)
Date: Sun, 05 Jul 2015 03:49:21 -0700 (PDT)
Subject: [Python-Dev]  Should asyncio ignore KeyboardInterrupt?
In-Reply-To: <20150704174942.E9DE4250EA5@webabinitio.net>
Message-ID: <55990bb1.c709c20a.3a0ed.3614@mx.google.com>

> Once long ago in Internet time (issue 581232) time.sleep on windows was
> not interruptible and this was fixed.  Is it possible the work on EINTR
> has broken that fix?
> 
> (I don't currently have 3.5 installed on windows to test that theory...)

It is no problem to interrupt time.sleep() with Ctrl-C for me (Python 3.5.0b2, Windows Vista x64).

Regards, Adam Barto??

From larry at hastings.org  Sun Jul  5 19:20:07 2015
From: larry at hastings.org (Larry Hastings)
Date: Sun, 05 Jul 2015 10:20:07 -0700
Subject: [Python-Dev] [RELEASED] Python 3.5.0b3 is now available
Message-ID: <55996747.2030203@hastings.org>



On behalf of the Python development community and the Python 3.5 release 
team, I'm relieved to announce the availability of Python 3.5.0b3.

Python 3.5 has now entered "feature freeze".  By default new features 
may no longer be added to Python 3.5.

This is a preview release, and its use is not recommended for production 
settings.

An important reminder for Windows users about Python 3.5.0b3: if 
installing Python 3.5.0b2 as a non-privileged user, you may need to 
escalate to administrator privileges to install an update to your C 
runtime libraries.


You can find Python 3.5.0b2 here:

    https://www.python.org/downloads/release/python-350b3/

Happy hacking,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150705/1a61b21a/attachment.html>

From rdmurray at bitdance.com  Sun Jul  5 19:52:55 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 05 Jul 2015 13:52:55 -0400
Subject: [Python-Dev] What's New editing
Message-ID: <20150705175255.99CB6250EB5@webabinitio.net>

Just so people aren't caught unawares, it is very unlikely that I will have
time to be the final editor on "What's New for 3.5" they way I was for 3.3 and
3.4.  I've tried to encourage people to keep What's New up to date, but
*someone* should make a final editing pass.  Ideally they'd do at least the
research Serhiy did last year on checking that there's a mention for all of the
versionadded and versionchanged 3.5's in the docs.  Even better would be to
review the NEWS and/or commit history...but *that* is a really big job these
days....

--David

From srkunze at mail.de  Sun Jul  5 23:50:00 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Sun, 05 Jul 2015 23:50:00 +0200
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>
References: <558AF376.30607@mail.de>	<558B1034.6080504@gmail.com>	<558B1F72.9000409@mail.de>	<20150625021659.GS20701@ando.pearwood.info>	<558C2489.2080305@mail.de>	<CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>	<558D5834.2030909@mail.de>	<BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>	<558D8E95.6020404@stoneleaf.us>	<558D9A41.3050309@gmail.com>	<5592F074.7010904@mail.de>	<5594638C.1060401@canterbury.ac.nz>	<5595A52D.9040909@mail.de>
 <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>
Message-ID: <5599A688.8050900@mail.de>

Thanks, Nick, for you reasoned response.

On 03.07.2015 11:40, Nick Coghlan wrote:
> On 3 July 2015 at 06:55, Sven R. Kunze <srkunze at mail.de> wrote:
>> My understanding of coloring is "needs special treatment".
>>
>> Being special or not (containing an 'await' or not), as long as I don't need
>> to care, I can call them either way (with 'await' or not) and each case
>> works sensibly that's fine with me.
> I'm afraid you're going to be disappointed in that regard, as wishing
> that event driven programs behaved more like synchronous programs is
> like wishing that complex numbers behaved like real numbers.
Seems like we stick to this example once again. So, let me get this 
straight:

1) I can add, subtract, multiply and divide real numbers.
2) I can add, subtract, multiply and divide complex numbers.
3) I can even add, subtract, multiply and divide complex numbers AND 
real numbers altogether in a single expression.
4) Granted, complex numbers can do more but that basically follows from 
their definition and does not jeopardize ease of usage.

A) I can call a function and might get a return value.
B) I can await an awaitable and might get a return value.
C) I cannot use them interchangeably. Why? Because people think we 
cannot have the best things of both worlds.
D) Granted, awaitables can do more but that basically follows from their 
definition and does not need to jeopardize ease of usage.

> There's
> an extra level of complexity that is being deliberately introduced in
> order to improve Python's ability to express certain kinds of
> algorithms, and it isn't effective to just try to wish that complexity
> away.
>
> The payoff is that code that otherwise needs to be written as a long
> series of disconnected callback chains (as has long been possible with
> Twisted) can instead be written to look more like comparable
> synchronous code

That is great. So, let's do the next step.

> (and this approach should bring with it much improved
> introspection support, at least in 3.5+ now that gi_yieldfrom and
> cr_await are being exposed at the Python level).
>
>> Sensible would be something similar to:
>> await function: suspension point and runs the function until completion
>> call awaitable: runs the awaitable until completion
> These both fail, and deliberately so: we don't know what they're
> supposed to mean, and we refuse the temptation to guess.

Where do we guess here? It is a definition.

> They're also
> quite likely to indicate a bug (e.g. forgetting to call a native
> coroutine function to get the coroutine out of it, forgetting to wait
> for an awaitable) rather than something folks have done deliberately.
>
> It's possible shorthand adapters may emerge over time, like:
>
>      # Call awaitable from synchronous code
>      def wait_for_result(awaitable):
>          """Usage: result = asyncio.wait_for_result(awaitable)"""
>         return asyncio.get_event_loop().run_until_complete(awaitable.__await__())
>
>      # Call blocking operation from asynchronous code
>     def blocking_call(f, *args, **kwds):
>          """Usage: result = await asyncio.blocking_call(f, *args, **kwds))"""
>          cb = functools.partial(f, *args, **kwds)
>          return asyncio.get_event_loop().run_in_executor(cb)
>
> However, those can be written already as utility functions, so we can
> wait and see how strong the demand is for them as adapters. (They may
> also be potentially useful to have as recipes in the documentation)
Sure, that would be reasonable. You have the first guy asking explicitly 
for these types of adapters provided by the current syntax and removal 
of 'async'.

Until a solution, we return to watching and have one reason less to 
switch to Python 3. :-/

From rosuav at gmail.com  Mon Jul  6 02:27:37 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 6 Jul 2015 10:27:37 +1000
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <5599A688.8050900@mail.de>
References: <558AF376.30607@mail.de> <558B1034.6080504@gmail.com>
 <558B1F72.9000409@mail.de>
 <20150625021659.GS20701@ando.pearwood.info>
 <558C2489.2080305@mail.de>
 <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de> <5594638C.1060401@canterbury.ac.nz>
 <5595A52D.9040909@mail.de>
 <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>
 <5599A688.8050900@mail.de>
Message-ID: <CAPTjJmoOcdm6kEN0j68p_FquRePbfV_9ViQW82y_bOM0vXSmPA@mail.gmail.com>

On Mon, Jul 6, 2015 at 7:50 AM, Sven R. Kunze <srkunze at mail.de> wrote:
> Seems like we stick to this example once again. So, let me get this
> straight:
>
> 1) I can add, subtract, multiply and divide real numbers.
> 2) I can add, subtract, multiply and divide complex numbers.
> 3) I can even add, subtract, multiply and divide complex numbers AND real
> numbers altogether in a single expression.
> 4) Granted, complex numbers can do more but that basically follows from
> their definition and does not jeopardize ease of usage.

Until you run into a TypeError: unorderable types: complex() >
complex(), at which point you realize that they aren't a simple
superset of reals with all the same operations supported.

ChrisA

From ncoghlan at gmail.com  Mon Jul  6 03:06:41 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 6 Jul 2015 11:06:41 +1000
Subject: [Python-Dev] What's New editing
In-Reply-To: <20150705175255.99CB6250EB5@webabinitio.net>
References: <20150705175255.99CB6250EB5@webabinitio.net>
Message-ID: <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>

On 6 July 2015 at 03:52, R. David Murray <rdmurray at bitdance.com> wrote:
> Just so people aren't caught unawares, it is very unlikely that I will have
> time to be the final editor on "What's New for 3.5" they way I was for 3.3 and
> 3.4.

And thank you again for your work on those!

> I've tried to encourage people to keep What's New up to date, but
> *someone* should make a final editing pass.  Ideally they'd do at least the
> research Serhiy did last year on checking that there's a mention for all of the
> versionadded and versionchanged 3.5's in the docs.  Even better would be to
> review the NEWS and/or commit history...but *that* is a really big job these
> days....

What would your rough estimate of the scope of work be? As you note,
the amount of effort involved in doing a thorough job of that has
expanded beyond what can reasonably be expected of volunteer
contributors, so I'm wondering if it might make sense for the PSF to
start offering a contract technical writing gig to finalise the What's
New documentation for each new release.

After all, the What's New doc is an essential component of
communicating changes in recommended development practices to Python
educators, so ensuring we do a good job with that can have a big
multiplier effect on all the other work that goes into creating each
new release.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From steve at pearwood.info  Mon Jul  6 02:49:36 2015
From: steve at pearwood.info (Steven D'Aprano)
Date: Mon, 6 Jul 2015 10:49:36 +1000
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <5599A688.8050900@mail.de>
References: <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de> <5594638C.1060401@canterbury.ac.nz>
 <5595A52D.9040909@mail.de>
 <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>
 <5599A688.8050900@mail.de>
Message-ID: <20150706004935.GX10773@ando.pearwood.info>

On Sun, Jul 05, 2015 at 11:50:00PM +0200, Sven R. Kunze wrote:

> Seems like we stick to this example once again. So, let me get this 
> straight:
> 
> 1) I can add, subtract, multiply and divide real numbers.
> 2) I can add, subtract, multiply and divide complex numbers.

I don't think that this is a complelling analogy for calling regular 
functions and awaitable functions. Doing arithmetic is a bit more 
complicated than just the four elementary operators you mention. 
Contrast:

    10 < 20

    10+20j < 20+10j

It is not just that complex numbers can do more than real numbers. They 
can also do *less*.

But aside from that, your analogy looks to me like this:

(1) I can do arithmetic on reals; 
(2) I can do arithmetic on complex numbers;
(3) and I can do arithmetic on mixed real + complex expressions;

(A) I can travel in a car to the shops down the road;
(B) I can travel in a space ship to the moon;

(C) so why can't I travel in a car to the moon? Or use a space ship to 
    fly to the shops down the road? Because people think we cannot have 
    the best things of both worlds!

It seems to me that if "people think we cannot have the best things of 
both worlds" (your words), it is because there are solid reasons for 
that belief.

Could somebody build a car that can fly to the moon? Probably, but it 
would cost *more* than the combination of separate space ship plus car, 
it would require as much maintenance and support as a space ship, and 
the fuel economy when driving to work would be terrible. Not to mention 
all the complaints about the noise and the pollution.

I think that the distinction between regular and concurrent routines is 
practical and necessary, *not* just because of people's closed minds, 
but because of decades of collective experience with them.

To convince me differently, you will need more than some rather dubious 
analogies or arguments from theoretical purity that sequential 
syncronous code is just a special case of concurrent asyncronous code. 
An actual working implementation speaks most loudly of all, but at the 
very least you will need to stick to concrete arguments, not analogies.

Are you aware of any other languages which have eliminated the 
distinction between regular and concurrent functions? If it has already 
been done, that would make a good argument in favour of your idea.


-- 
Steven

From ncoghlan at gmail.com  Mon Jul  6 03:41:45 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 6 Jul 2015 11:41:45 +1000
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <CAPTjJmoOcdm6kEN0j68p_FquRePbfV_9ViQW82y_bOM0vXSmPA@mail.gmail.com>
References: <558AF376.30607@mail.de> <558B1034.6080504@gmail.com>
 <558B1F72.9000409@mail.de>
 <20150625021659.GS20701@ando.pearwood.info>
 <558C2489.2080305@mail.de>
 <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de> <5594638C.1060401@canterbury.ac.nz>
 <5595A52D.9040909@mail.de>
 <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>
 <5599A688.8050900@mail.de>
 <CAPTjJmoOcdm6kEN0j68p_FquRePbfV_9ViQW82y_bOM0vXSmPA@mail.gmail.com>
Message-ID: <CADiSq7fN1et3yae=CwrWoL7DNeF3jwzdRFkhM8EQ7FkQC3etaw@mail.gmail.com>

On 6 July 2015 at 10:27, Chris Angelico <rosuav at gmail.com> wrote:
> On Mon, Jul 6, 2015 at 7:50 AM, Sven R. Kunze <srkunze at mail.de> wrote:
>> Seems like we stick to this example once again. So, let me get this
>> straight:
>>
>> 1) I can add, subtract, multiply and divide real numbers.
>> 2) I can add, subtract, multiply and divide complex numbers.
>> 3) I can even add, subtract, multiply and divide complex numbers AND real
>> numbers altogether in a single expression.
>> 4) Granted, complex numbers can do more but that basically follows from
>> their definition and does not jeopardize ease of usage.
>
> Until you run into a TypeError: unorderable types: complex() >
> complex(), at which point you realize that they aren't a simple
> superset of reals with all the same operations supported.

Exactly. While complex numbers are a superset of the real numbers from
a value perspective, from a behavioural perspective, there are things
you can do when working only with real numbers that you can't do when
you have to account for the fact that here might be complex numbers
are in the mix. In a Python context, the essential operations specific
to real numbers are listed at
https://docs.python.org/3/library/numbers.html#numbers.Real

There's also a difference between the scope of the math and cmath modules:

    >>> import math, cmath
    >>> set(dir(math)) - set(dir(cmath))
    {'floor', 'pow', 'erf', 'trunc', 'copysign', 'expm1', 'ldexp',
'fsum', 'erfc', 'lgamma', 'frexp', 'gamma', 'factorial', 'log2',
'fabs', 'log1p', 'atan2', 'hypot', 'modf', 'radians', 'degrees',
'fmod', 'ceil'}

It's a general principle of design that expanding the kinds of values
you accept (e.g. from real numbers to complex numbers) means you
reduce the kinds of operations you can assume will work (e.g. to the
behaviours of 2D complex numbers, rather than the 1D real number
line). Similarly, as you step further down the numeric tower from real
numbers to rationals and integers, you reduce the set of supported
values, but you also increase the number of defined behaviours.

When it comes to coroutines and subroutines, coroutines are the
superset - a subroutine is just a coroutine that never suspends before
producing a result. You can thus make certain simplifying assumptions
when executing subroutines that you can't make when executing a
coroutine.

It also turns out that "never suspends" is actually problematic, which
is why nominally subroutine based code these days tends to instead
have *implicit* suspension points based on either operating system
level pre-emptive multithreading where suspension may occur at any
point or greenlet style state switching where suspension may occur as
part of any function call (whether an explicit call or as part of a
syntactic protocol). These approaches provide parallel execution at
the expense of the ability to reason locally about code correctness,
which then causes all sorts of *other* problems.

That said, I think there's definitely value in providing a very simple
answer to the "how do I make a blocking call from a coroutine?"
question, so I filed an RFE to add asyncio.blocking_call:
http://bugs.python.org/issue24571

I'm less convinced of the value of "asyncio.wait_for_result()", so I
haven't filed an RFE for that one.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From rdmurray at bitdance.com  Mon Jul  6 03:54:34 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 05 Jul 2015 21:54:34 -0400
Subject: [Python-Dev] What's New editing
In-Reply-To: <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
Message-ID: <20150706015435.C4552250EAD@webabinitio.net>

On Mon, 06 Jul 2015 11:06:41 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 6 July 2015 at 03:52, R. David Murray <rdmurray at bitdance.com> wrote:
> > Just so people aren't caught unawares, it is very unlikely that I will have
> > time to be the final editor on "What's New for 3.5" they way I was for 3.3 and
> > 3.4.
> 
> And thank you again for your work on those!
> 
> > I've tried to encourage people to keep What's New up to date, but
> > *someone* should make a final editing pass.  Ideally they'd do at least the
> > research Serhiy did last year on checking that there's a mention for all of the
> > versionadded and versionchanged 3.5's in the docs.  Even better would be to
> > review the NEWS and/or commit history...but *that* is a really big job these
> > days....
> 
> What would your rough estimate of the scope of work be? As you note,
> the amount of effort involved in doing a thorough job of that has
> expanded beyond what can reasonably be expected of volunteer
> contributors, so I'm wondering if it might make sense for the PSF to
> start offering a contract technical writing gig to finalise the What's
> New documentation for each new release.
> 
> After all, the What's New doc is an essential component of
> communicating changes in recommended development practices to Python
> educators, so ensuring we do a good job with that can have a big
> multiplier effect on all the other work that goes into creating each
> new release.

I can tell you that 3.4 took me approximately 67 hours according to my
time log.  That was going through the list prepared by Serhiy, and going
through pretty much all of the NEWS entries but not the commit log.  I'm
a precisionist, so I suspect someone less...ocd...about the details
could do it a bit faster, perhaps at the cost of some small amount of
accuracy :)

On the other hand, my knowledge of the code base and the development
that had been going on probably sped up my analysis and writeup of
the missing entries (and revision of existing entries, in many cases).

On gripping hand, I also did some small amount of documentation
rewriting and clarification along the way.

--David

From Steve.Dower at microsoft.com  Mon Jul  6 04:03:01 2015
From: Steve.Dower at microsoft.com (Steve Dower)
Date: Mon, 6 Jul 2015 02:03:01 +0000
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <5599A688.8050900@mail.de>
References: <558AF376.30607@mail.de>	<558B1034.6080504@gmail.com>
 <558B1F72.9000409@mail.de>	<20150625021659.GS20701@ando.pearwood.info>
 <558C2489.2080305@mail.de>
 <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us>	<558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de>	<5594638C.1060401@canterbury.ac.nz>
 <5595A52D.9040909@mail.de>
 <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>,
 <5599A688.8050900@mail.de>
Message-ID: <BY2PR0301MB16531464C137A9B482EE982EF5930@BY2PR0301MB1653.namprd03.prod.outlook.com>

"A) I can call a function and might get a return value.
B) I can await an awaitable and might get a return value.
C) I cannot use them interchangeably. Why?"

Function != awaitable - the answer is right there in the terminology. Different names, different things.

Given A, B and the fact that an awaitable is just an object, here's another important point:

* I can call a function and might get an awaitable.

If the function was decorated with async, the "might" becomes "will", but it's still just a function returning a value.

Because an awaitable is indistinguishable from any other value, the compiler doesn't know whether to await or not, so it has to be specified by the developer. If the language specifies it, then it's impossible to handle awaitable objects (for example, to put them in a list and await them later).

C# is another language that implemented this exact model a few years ago and it works well.

Cheers,
Steve

Top-posted from my Windows Phone
________________________________
From: Sven R. Kunze<mailto:srkunze at mail.de>
Sent: ?7/?5/?2015 14:50
To: python-dev at python.org<mailto:python-dev at python.org>
Subject: Re: [Python-Dev] Importance of "async" keyword

Thanks, Nick, for you reasoned response.

On 03.07.2015 11:40, Nick Coghlan wrote:
> On 3 July 2015 at 06:55, Sven R. Kunze <srkunze at mail.de> wrote:
>> My understanding of coloring is "needs special treatment".
>>
>> Being special or not (containing an 'await' or not), as long as I don't need
>> to care, I can call them either way (with 'await' or not) and each case
>> works sensibly that's fine with me.
> I'm afraid you're going to be disappointed in that regard, as wishing
> that event driven programs behaved more like synchronous programs is
> like wishing that complex numbers behaved like real numbers.
Seems like we stick to this example once again. So, let me get this
straight:

1) I can add, subtract, multiply and divide real numbers.
2) I can add, subtract, multiply and divide complex numbers.
3) I can even add, subtract, multiply and divide complex numbers AND
real numbers altogether in a single expression.
4) Granted, complex numbers can do more but that basically follows from
their definition and does not jeopardize ease of usage.

A) I can call a function and might get a return value.
B) I can await an awaitable and might get a return value.
C) I cannot use them interchangeably. Why? Because people think we
cannot have the best things of both worlds.
D) Granted, awaitables can do more but that basically follows from their
definition and does not need to jeopardize ease of usage.

> There's
> an extra level of complexity that is being deliberately introduced in
> order to improve Python's ability to express certain kinds of
> algorithms, and it isn't effective to just try to wish that complexity
> away.
>
> The payoff is that code that otherwise needs to be written as a long
> series of disconnected callback chains (as has long been possible with
> Twisted) can instead be written to look more like comparable
> synchronous code

That is great. So, let's do the next step.

> (and this approach should bring with it much improved
> introspection support, at least in 3.5+ now that gi_yieldfrom and
> cr_await are being exposed at the Python level).
>
>> Sensible would be something similar to:
>> await function: suspension point and runs the function until completion
>> call awaitable: runs the awaitable until completion
> These both fail, and deliberately so: we don't know what they're
> supposed to mean, and we refuse the temptation to guess.

Where do we guess here? It is a definition.

> They're also
> quite likely to indicate a bug (e.g. forgetting to call a native
> coroutine function to get the coroutine out of it, forgetting to wait
> for an awaitable) rather than something folks have done deliberately.
>
> It's possible shorthand adapters may emerge over time, like:
>
>      # Call awaitable from synchronous code
>      def wait_for_result(awaitable):
>          """Usage: result = asyncio.wait_for_result(awaitable)"""
>         return asyncio.get_event_loop().run_until_complete(awaitable.__await__())
>
>      # Call blocking operation from asynchronous code
>     def blocking_call(f, *args, **kwds):
>          """Usage: result = await asyncio.blocking_call(f, *args, **kwds))"""
>          cb = functools.partial(f, *args, **kwds)
>          return asyncio.get_event_loop().run_in_executor(cb)
>
> However, those can be written already as utility functions, so we can
> wait and see how strong the demand is for them as adapters. (They may
> also be potentially useful to have as recipes in the documentation)
Sure, that would be reasonable. You have the first guy asking explicitly
for these types of adapters provided by the current syntax and removal
of 'async'.

Until a solution, we return to watching and have one reason less to
switch to Python 3. :-/
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150706/de6b64a6/attachment-0001.html>

From ncoghlan at gmail.com  Mon Jul  6 04:05:28 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 6 Jul 2015 12:05:28 +1000
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <20150706004935.GX10773@ando.pearwood.info>
References: <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de> <5594638C.1060401@canterbury.ac.nz>
 <5595A52D.9040909@mail.de>
 <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>
 <5599A688.8050900@mail.de>
 <20150706004935.GX10773@ando.pearwood.info>
Message-ID: <CADiSq7eOUo0hR9OvAA1pC75hk+257VgoYhkWA-qejmNutm-X9w@mail.gmail.com>

On 6 July 2015 at 10:49, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sun, Jul 05, 2015 at 11:50:00PM +0200, Sven R. Kunze wrote:
>
>> Seems like we stick to this example once again. So, let me get this
>> straight:
>>
>> 1) I can add, subtract, multiply and divide real numbers.
>> 2) I can add, subtract, multiply and divide complex numbers.
>
> I don't think that this is a complelling analogy for calling regular
> functions and awaitable functions.

I actually really like the analogy, as the "Why can't complex numbers
be just like real numbers?" reaction is pretty common when folks are
first learning to use them for things like signal analysis. I know it
didn't really sink in for me at university - it was only a couple of
years into doing digital signal processing full time that the concepts
involved in switching back and forth between linear real number based
time domain analysis and cyclical complex number based frequency
domain analysis really started to make sense to me.

There's a wonderful page at
http://betterexplained.com/articles/a-visual-intuitive-guide-to-imaginary-numbers/
which not only does a great job of providing a relatively intuitive
explanation of the behaviour of complex numbers as an answer to the
question "What is the square root of negative 1?", it also compares
them to the original reactions to the "absurd" notion of negative
numbers as an answer to the question "What is the result of
subtracting a larger number from a smaller one?".

"Why can't coroutines be just like subroutines?" strikes me as being a
similar case where the answer is "because not everything can be
appropriately modelled as a subroutine", but that answer isn't going
to make intuitive sense if you've never personally encountered the
limits of subroutine based algorithm design.

I also think the analogy helps provide good design guidance, as folks
are already familiar with the notion of "use real numbers if you can,
complex numbers if you need to", and extending that to an attitude of
"use subroutines if you can, coroutines if you need to" would be a
*very* good thing in terms of encouraging maintainable designs.

"Are complex numbers better than real numbers?" is hopefully a
self-evidently nonsensical question - some things are better modelled
as complex numbers, others as real numbers, so the only reasonable
answer is to ask "What are you trying to model?". "Are coroutines
better than subroutines?" is the same kind of question, just applied
to algorithm design rather than numeric modelling.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From mertz at gnosis.cx  Mon Jul  6 04:42:10 2015
From: mertz at gnosis.cx (David Mertz)
Date: Sun, 5 Jul 2015 19:42:10 -0700
Subject: [Python-Dev] What's New editing
In-Reply-To: <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
Message-ID: <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>

On Sun, Jul 5, 2015 at 6:06 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 July 2015 at 03:52, R. David Murray <rdmurray at bitdance.com> wrote:
> > Just so people aren't caught unawares, it is very unlikely that I will
> have
> > time to be the final editor on "What's New for 3.5" they way I was for
> 3.3 and
> > 3.4.
>
> And thank you again for your work on those!
>
> > I've tried to encourage people to keep What's New up to date, but
> > *someone* should make a final editing pass.  Ideally they'd do at least
> the
> > research Serhiy did last year on checking that there's a mention for all
> of the
> > versionadded and versionchanged 3.5's in the docs.  Even better would be
> to
> > review the NEWS and/or commit history...but *that* is a really big job
> these
> > days....
>
> What would your rough estimate of the scope of work be? As you note,
> the amount of effort involved in doing a thorough job of that has
> expanded beyond what can reasonably be expected of volunteer
> contributors, so I'm wondering if it might make sense for the PSF to
> start offering a contract technical writing gig to finalise the What's
> New documentation for each new release.
>

I think I might be able to "volunteer" for the task of writing/editing the
"What's New in 3.5" docs.  I saw David's comment on it today, so obviously
haven't yet had a chance to run it by my employer (Continuum Analytics),
but I have a hunch they would allow me to do it at least in large part as
paid time.  I am experienced as a technical writer, follow python-dev,
write about new features, but am *not*, however, my self an existing core
developer.

If there is interest in this, or at least it seems plausible, I can run it
by my employer tomorrow to see about getting enough time allocated (using
David Murray's past experience as a guideline for what's likely to be
needed).

Yours, David...

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150705/aa62e84e/attachment.html>

From ncoghlan at gmail.com  Mon Jul  6 05:51:45 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 6 Jul 2015 13:51:45 +1000
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
Message-ID: <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>

On 6 July 2015 at 12:42, David Mertz <mertz at gnosis.cx> wrote:
> I think I might be able to "volunteer" for the task of writing/editing the
> "What's New in 3.5" docs.  I saw David's comment on it today, so obviously
> haven't yet had a chance to run it by my employer (Continuum Analytics), but
> I have a hunch they would allow me to do it at least in large part as paid
> time.  I am experienced as a technical writer, follow python-dev, write
> about new features, but am *not*, however, my self an existing core
> developer.

I think the last point may be a positive rather than a negative when
it comes to effectively describing new features :)

> If there is interest in this, or at least it seems plausible, I can run it
> by my employer tomorrow to see about getting enough time allocated (using
> David Murray's past experience as a guideline for what's likely to be
> needed).

That would be very helpful! I'd definitely be able to find the time to
review and merge updates, it's the research-and-writing side that
poses a problem for me (appreciating a task is worth doing isn't the
same thing as wanting to do it myself!).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Mon Jul  6 06:22:46 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 6 Jul 2015 14:22:46 +1000
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7 HTTPS
Message-ID: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>

Hi folks,

As previously discussed on python-ideas, Red Hat has been looking at
ways to provide a smoother migration path for system administrators to
get to a point where system Python installations are verifying HTTPS
by default.

While we're not proposing that these changes be implemented upstream
(given that the change in default behaviour was already implemented
for 2.7.9), we *would* like to pursue an explicit upstream
recommendation regarding how deviations from the upstream behaviour
should be handled. Otherwise we run the risk of different
redistributors pursuing mutually incompatible approaches to the
migration, which would be a rather unfortunate outcome.

The proposal in PEP 493 offers two recommendations:

* one option that leaves the default behaviour alone, but provides an
easy environment variable based way to revert to the legacy behaviour
on a per-application basis (based on a design suggested by MAL)
* a second option designed for backporting the changes to versions
that advertise themselves as older than 2.7.9 that permits opting in
to the new behaviour on a system wide basis (based on a design
suggested by Robert Kuska)

The main change from the last version discussed on python-ideas is
that in both cases there's now a required attribute that
redistributors are expected to add to the SSL module to signal the
presence of the feature (and to provide some useful information about
its implementation).

I think this is mature enough now for me to request pronouncement (if
Guido's interested in doing that himself), or volunteers to be
BDFL-Delegate (if Guido's would prefer someone else handle it).

Regards,
Nick.

======================
PEP: 493
Title: HTTPS verification recommendations for Python 2.7 redistributors
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan <ncoghlan at gmail.com>,
        Robert Kuska <rkuska at redhat.com>,
        Marc-Andr? Lemburg <mal at lemburg.com>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 10-May-2015
Post-History: 06-Jul-2015


Abstract
========

PEP 476 updated Python's default handling of HTTPS certificates to be
appropriate for communication over the public internet. The Python 2.7 long
term maintenance series was judged to be in scope for this change, with the
new behaviour introduced in the Python 2.7.9 maintenance release.

This PEP provides recommendations to downstream redistributors wishing to
provide a smoother migration experience when helping their users to manage
this change in Python's default behaviour.

*Note that this PEP is not currently accepted, so it is a *proposed*
recommendation, rather than an active one.*


Rationale
=========

PEP 476 changed Python's default behaviour to better match the needs and
expectations of developers operating over the public internet, a category
which appears to include most new Python developers. It is the position of
the authors of this PEP that this was a correct decision.

However, it is also the case that this change *does* cause problems for
infrastructure administrators operating private intranets that rely on
self-signed certificates, or otherwise encounter problems with the new default
certificate verification settings.

The long term answer for such environments is to update their internal
certificate management to at least match the standards set by the public
internet, but in the meantime, it is desirable to offer these administrators
a way to continue receiving maintenance updates to the Python 2.7 series,
without having to gate that on upgrades to their certificate management
infrastructure.

PEP 476 did attempt to address this question, by covering how to revert the
new settings process wide by monkeypatching the ``ssl`` module to restore the
old behaviour. Unfortunately, the ``sitecustomize.py`` based technique proposed
to allow system administrators to disable the feature by default in their
Standard Operating Environment definition has been determined to be
insufficient in at least some cases. The specific case of interest to the
authors of this PEP is the one where a Linux distributor aims to provide
their users with a
`smoother migration path
<https://bugzilla.redhat.com/show_bug.cgi?id=1173041>`__
than the standard one provided by consuming upstream CPython 2.7 releases
directly, but other potential challenges have also been pointed out with
updating embedded Python runtimes and other user level installations of Python.

Rather than allowing a plethora of mutually incompatibile migration techniques
to bloom, this PEP proposes two alternative approaches that redistributors
may take when addressing these problems. Redistributors may choose to implement
one, both, or neither of these approaches based on their assessment of the
needs of their particular userbase.

These designs are being proposed as a recommendation for redistributors, rather
than as new upstream features, as they are needed purely to support legacy
environments migrating from older versions of Python 2.7. Neither approach
is being proposed as an upstream Python 2.7 feature, nor as a feature in any
version of Python 3 (whether published directly by the Python Software
Foundation or by a redistributor).


Requirements for capability detection
=====================================

As these recommendations are intended to cover backports to earlier Python
versions, the Python version number cannot be used as a reliable means for
detecting them. Instead, the recommendations are defined to allow the presence
or absence of the feature to be determined using the following technique::

    python -c "import ssl; ssl._relevant_attribute"

This will fail with `AttributeError` (and hence a non-zero return code) if the
relevant capability is not available.

The marker attributes are prefixed with an underscore to indicate the
implementation dependent nature of these capabilities - not all Python
distributions will offer them, only those that are providing a multi-stage
migration process from the legacy HTTPS handling to the new default behaviour.


Recommendation for an environment variable based security downgrade
===================================================================

Some redistributors may wish to provide a per-application option to disable
certificate verification in selected applications that run on or embed CPython
without needing to modify the application itself.

In these cases, a configuration mechanism is needed that provides:

* an opt-out model that allows certificate verification to be selectively
  turned off for particular applications after upgrading to a version of
  Python that verifies certificates by default
* the ability for all users to configure this setting on a per-application
  basis, rather than on a per-system, or per-Python-installation basis

This approach may be used for any redistributor provided version of Python 2.7,
including those that advertise themselves as providing Python 2.7.9 or later.


Required marker attribute
-------------------------

The required marker attribute on the ``ssl`` module when implementing this
recommendation is::

    _https_verify_envvar = 'PYTHONHTTPSVERIFY'

This not only makes it straightforward to detect the presence (or absence) of
the capability, it also makes it possible to programmatically determine the
relevant environment variable name.


Recommended modifications to the Python standard library
--------------------------------------------------------

The recommended approach to providing a per-application configuration setting
for HTTPS certificate verification that doesn't require modifications to the
application itself is to:

* modify the ``ssl`` module to read the ``PYTHONHTTPSVERIFY`` environment
  variable when the module is first imported into a Python process
* set the ``ssl._create_default_https_context`` function to be an alias for
  ``ssl._create_unverified_context`` if this environment variable is present
  and set to ``'0'``
* otherwise, set the ``ssl._create_default_https_context`` function to be an
  alias for ``ssl.create_default_context`` as usual


Example implementation
----------------------

::

    _https_verify_envvar = 'PYTHONHTTPSVERIFY'

    def _get_https_context_factory():
        config_setting = os.environ.get(_https_verify_envvar)
        if config_setting == '0':
            return _create_unverified_context
        return create_default_context

    _create_default_https_context = _get_https_context_factory()


Security Considerations
-----------------------

Relative to an unmodified version of CPython 2.7.9 or later, this approach
does introduce a new downgrade attack against the default security settings
that potentially allows a sufficiently determined attacker to revert Python
to the vulnerable configuration used in CPython 2.7.8 and earlier releases.
However, such an attack requires the ability to modify the execution
environment of a Python process prior to the import of the ``ssl`` module,
and any attacker with such access would already be able to modify the
behaviour of the underlying OpenSSL implementation.


Recommendation for backporting to earlier Python versions
=========================================================

Some redistributors, most notably Linux distributions, may choose to backport
the PEP 476 HTTPS verification changes to modified Python versions based on
earlier Python 2 maintenance releases. In these cases, a configuration
mechanism is needed that provides:

* an opt-in model that allows the decision to enable HTTPS certificate
  verification to be made independently of the decision to upgrade to the
  Python version where the feature was first backported
* the ability for system administrators to set the default behaviour of Python
  applications and scripts run directly in the system Python installation
* the ability for the redistributor to consider changing the default behaviour
  of *new* installations at some point in the future without impacting existing
  installations that have been explicitly configured to skip verifying HTTPS
  certificates by default

This approach should not be used for any Python installation that advertises
itself as providing Python 2.7.9 or later, as most Python users will have the
reasonable expectation that all such environments will validate HTTPS
certificates by default.


Required marker attribute
-------------------------

The required marker attribute on the ``ssl`` module when implementing this
recommendation is::

    _cert_verification_config = '<path to configuration file>'

This not only makes it straightforward to detect the presence (or absence) of
the capability, it also makes it possible to programmatically determine the
relevant configuration file name.


Recommended modifications to the Python standard library
--------------------------------------------------------

The recommended approach to backporting the PEP 476 modifications to an earlier
point release is to implement the following changes relative to the default
PEP 476 behaviour implemented in Python 2.7.9+:

* modify the ``ssl`` module to read a system wide configuration file when the
  module is first imported into a Python process
* define a platform default behaviour (either verifying or not verifying HTTPS
  certificates) to be used if this configuration file is not present
* support selection between the following three modes of operation:

  * ensure HTTPS certificate verification is enabled
  * ensure HTTPS certificate verification is disabled
  * delegate the decision to the redistributor providing this Python version

* set the ``ssl._create_default_https_context`` function to be an alias for
  either ``ssl.create_default_context`` or ``ssl._create_unverified_context``
  based on the given configuration setting.


Recommended file location
-------------------------

This approach is currently only defined for \*nix system Python installations.

The recommended configuration file name is
``/etc/python/cert-verification.cfg``.

The ``.cfg`` filename extension is recommended for consistency with the
``pyvenv.cfg`` used by the ``venv`` module in Python 3's standard library.


Recommended file format
-----------------------

The configuration file should use a ConfigParser ini-style format with a
single section named ``[https]`` containing one required setting ``verify``.

Permitted values for ``verify`` are:

* ``enable``: ensure HTTPS certificate verification is enabled by default
* ``disable``: ensure HTTPS certificate verification is disabled by default
* ``platform_default``: delegate the decision to the redistributor providing
  this particular Python version

If the ``[https]`` section or the ``verify`` setting are missing, or if the
``verify`` setting is set to an unknown value, it should be treated as if the
configuration file is not present.


Example implementation
----------------------

::

    _cert_verification_config = '/etc/python/cert-verification.cfg'

    def _get_https_context_factory():
        # Check for a system-wide override of the default behaviour
        context_factories = {
            'enable': create_default_context,
            'disable': _create_unverified_context,
            'platform_default': _create_unverified_context, # For now :)
        }
        import ConfigParser
        config = ConfigParser.RawConfigParser()
        config.read(_cert_verification_config)
        try:
            verify_mode = config.get('https', 'verify')
        except (ConfigParser.NoSectionError, ConfigParser.NoOptionError):
            verify_mode = 'platform_default'
        default_factory = context_factories.get('platform_default')
        return context_factories.get(verify_mode, default_factory)

    _create_default_https_context = _get_https_context_factory()


Security Considerations
-----------------------

The specific recommendations for the backporting case are designed to work for
privileged, security sensitive processes, even those being run in the following
locked down configuration:

* run from a locked down administrator controlled directory rather than a normal
  user directory (preventing ``sys.path[0]`` based privilege escalation attacks)
* run using the ``-E`` switch (preventing ``PYTHON*`` environment variable based
  privilege escalation attacks)
* run using the ``-s`` switch (preventing user site directory based privilege
  escalation attacks)
* run using the ``-S`` switch (preventing ``sitecustomize`` based privilege
  escalation attacks)

The intent is that the *only* reason HTTPS verification should be getting
turned off system wide when using this approach is because:

* an end user is running a redistributor provided version of CPython rather
  than running upstream CPython directly
* that redistributor has decided to provide a smoother migration path to
  verifying HTTPS certificates by default than that being provided by the
  upstream project
* either the redistributor or the local infrastructure administrator has
  determined that it is appropriate to override the default upstream behaviour
  (at least for the time being)

Using an administrator controlled configuration file rather than an environment
variable has the essential feature of providing a smoother migration path, even
for applications being run with the ``-E`` switch.


Combining the recommendations
=============================

If a redistributor chooses to implement both recommendations, then the
environment variable should take precedence over the system-wide configuration
setting. This allows the setting to be changed for a given user, virtual
environment or application, regardless of the system-wide default behaviour.

In this case, if the ``PYTHONHTTPSVERIFY`` environment variable is defined, and
set to anything *other* than ``'0'``, then HTTPS certificate verification
should be enabled.

Example implementation
----------------------

::

    _https_verify_envvar = 'PYTHONHTTPSVERIFY'
    _cert_verification_config = '/etc/python/cert-verification.cfg'

    def _get_https_context_factory():
        # Check for am environmental override of the default behaviour
        config_setting = os.environ.get(_https_verify_envvar)
        if config_setting is not None:
            if config_setting == '0':
                return _create_unverified_context
            return create_default_context

        # Check for a system-wide override of the default behaviour
        context_factories = {
            'enable': create_default_context,
            'disable': _create_unverified_context,
            'platform_default': _create_unverified_context, # For now :)
        }
        import ConfigParser
        config = ConfigParser.RawConfigParser()
        config.read(_cert_verification_config)
        try:
            verify_mode = config.get('https', 'verify')
        except (ConfigParser.NoSectionError, ConfigParser.NoOptionError):
            verify_mode = 'platform_default'
        default_factory = context_factories.get('platform_default')
        return context_factories.get(verify_mode, default_factory)

    _create_default_https_context = _get_https_context_factory()


Copyright
=========

This document has been placed into the public domain.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From solipsis at pitrou.net  Mon Jul  6 12:21:23 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 6 Jul 2015 12:21:23 +0200
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
Message-ID: <20150706122123.195c4c57@fsol>

On Mon, 6 Jul 2015 14:22:46 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> The main change from the last version discussed on python-ideas

Was it discussed there? That list has become totally useless, I've
stopped following it.

> * modify the ``ssl`` module to read the ``PYTHONHTTPSVERIFY`` environment
>   variable when the module is first imported into a Python process

Have you passed that by RedHat's security experts?

Regards

Antoine.



From benhoyt at gmail.com  Mon Jul  6 15:08:08 2015
From: benhoyt at gmail.com (Ben Hoyt)
Date: Mon, 6 Jul 2015 09:08:08 -0400
Subject: [Python-Dev] [RELEASED] Python 3.5.0b3 is now available
In-Reply-To: <55996747.2030203@hastings.org>
References: <55996747.2030203@hastings.org>
Message-ID: <CAL9jXCE2ZxsdQOjY1LTsG+pVTZA0yQ0vxDHy5pcpZbF5+zADmw@mail.gmail.com>

Thanks! Looking forward to trying this.

I'm not sure where these descriptions come from, or whether they're carried
over from b2 to b3 etc, but one small note on this bullet point:

* PEP 471, os.scandir(), a faster alternative to os.walk()

This isn't quite correct. os.scandir() is actually an alternative to
os.listdir(), which is also used to speed up os.walk().

-Ben


On Sun, Jul 5, 2015 at 1:20 PM, Larry Hastings <larry at hastings.org> wrote:

>
>
> On behalf of the Python development community and the Python 3.5 release
> team, I'm relieved to announce the availability of Python 3.5.0b3.
>
> Python 3.5 has now entered "feature freeze".  By default new features may
> no longer be added to Python 3.5.
>
> This is a preview release, and its use is not recommended for production
> settings.
>
> An important reminder for Windows users about Python 3.5.0b3: if
> installing Python 3.5.0b2 as a non-privileged user, you may need to
> escalate to administrator privileges to install an update to your C runtime
> libraries.
>
>
> You can find Python 3.5.0b2 here:
>
> https://www.python.org/downloads/release/python-350b3/
>
> Happy hacking,
>
>
> */arry*
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/benhoyt%40gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150706/6549b49f/attachment.html>

From ncoghlan at gmail.com  Mon Jul  6 15:22:09 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 6 Jul 2015 23:22:09 +1000
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <20150706122123.195c4c57@fsol>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
Message-ID: <CADiSq7eB9Rr-UzEq5GKcEHSi_CBPnLnpQt_pp_nk_FiF53WJmQ@mail.gmail.com>

On 6 Jul 2015 20:23, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
>
> On Mon, 6 Jul 2015 14:22:46 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> >
> > The main change from the last version discussed on python-ideas
>
> Was it discussed there? That list has become totally useless, I've
> stopped following it.
>
> > * modify the ``ssl`` module to read the ``PYTHONHTTPSVERIFY``
environment
> >   variable when the module is first imported into a Python process
>
> Have you passed that by RedHat's security experts?

Yeah, they were the ones that finally persuaded me that this design was
reasonable. If I understood their explanation correctly, the gist is that
if you're running with elevated permissions while allowing arbitrary
processes to set environment variables, you've already opened up so many
attack vectors that the only reasonable defence is "don't do that", and
hence higher level design decisions like sudo running in root's
environment, not the individual user's. Since having the selective
downgrade option available makes it easier to justify the default security
*up*grade, it works out as a net win.

However, I did just realise there's a bug in the current definition of that
feature - it should respect the "ignore environment" flag, but it's
currently specified as being unconditional.

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150706/b4164bab/attachment.html>

From solipsis at pitrou.net  Mon Jul  6 15:28:42 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 6 Jul 2015 15:28:42 +0200
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <CADiSq7eB9Rr-UzEq5GKcEHSi_CBPnLnpQt_pp_nk_FiF53WJmQ@mail.gmail.com>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CADiSq7eB9Rr-UzEq5GKcEHSi_CBPnLnpQt_pp_nk_FiF53WJmQ@mail.gmail.com>
Message-ID: <20150706152842.13bb0ff6@fsol>

On Mon, 6 Jul 2015 23:22:09 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 Jul 2015 20:23, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
> >
> > On Mon, 6 Jul 2015 14:22:46 +1000
> > Nick Coghlan <ncoghlan at gmail.com> wrote:
> > >
> > > The main change from the last version discussed on python-ideas
> >
> > Was it discussed there? That list has become totally useless, I've
> > stopped following it.
> >
> > > * modify the ``ssl`` module to read the ``PYTHONHTTPSVERIFY``
> environment
> > >   variable when the module is first imported into a Python process
> >
> > Have you passed that by RedHat's security experts?
> 
> Yeah, they were the ones that finally persuaded me that this design was
> reasonable. If I understood their explanation correctly, the gist is that
> if you're running with elevated permissions while allowing arbitrary
> processes to set environment variables, you've already opened up so many
> attack vectors that the only reasonable defence is "don't do that", and
> hence higher level design decisions like sudo running in root's
> environment, not the individual user's. Since having the selective
> downgrade option available makes it easier to justify the default security
> *up*grade, it works out as a net win.

Thank you. Then I'm ok with the PEP.

Regards

Antoine.

From mertz at gnosis.cx  Mon Jul  6 17:38:23 2015
From: mertz at gnosis.cx (David Mertz)
Date: Mon, 6 Jul 2015 08:38:23 -0700
Subject: [Python-Dev] What's New editing
In-Reply-To: <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
Message-ID: <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>

Hi Folks,

I hereby volunteer to write "What's New for Python 3.5?" if folks on
python-dev are fine with me taking the job (i.e. I ran it by Travis, my
boss at Continuum, and he's happy to allow me to do that work within my
salaried hours... so having time isn't a problem).

If this is OK with the powers-that-be, I'll coordinate with David Murray on
how best to take over this task from him.

Thanks, David...

On Sun, Jul 5, 2015 at 8:51 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 July 2015 at 12:42, David Mertz <mertz at gnosis.cx> wrote:
> > I think I might be able to "volunteer" for the task of writing/editing
> the
> > "What's New in 3.5" docs.  I saw David's comment on it today, so
> obviously
> > haven't yet had a chance to run it by my employer (Continuum Analytics),
> but
> > I have a hunch they would allow me to do it at least in large part as
> paid
> > time.  I am experienced as a technical writer, follow python-dev, write
> > about new features, but am *not*, however, my self an existing core
> > developer.
>
> I think the last point may be a positive rather than a negative when
> it comes to effectively describing new features :)
>
> > If there is interest in this, or at least it seems plausible, I can run
> it
> > by my employer tomorrow to see about getting enough time allocated (using
> > David Murray's past experience as a guideline for what's likely to be
> > needed).
>
> That would be very helpful! I'd definitely be able to find the time to
> review and merge updates, it's the research-and-writing side that
> poses a problem for me (appreciating a task is worth doing isn't the
> same thing as wanting to do it myself!).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150706/c74c7bf8/attachment.html>

From erik.m.bray at gmail.com  Mon Jul  6 18:07:30 2015
From: erik.m.bray at gmail.com (Erik Bray)
Date: Mon, 6 Jul 2015 12:07:30 -0400
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <20150706122123.195c4c57@fsol>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
Message-ID: <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>

On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 6 Jul 2015 14:22:46 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> The main change from the last version discussed on python-ideas
>
> Was it discussed there? That list has become totally useless, I've
> stopped following it.

Considering that a useful discussion of a useful PEP occurred there
(not to mention other occasionally useful discussions) I'd say that
such a value judgment is not only unnecessary but also inaccurate.
That's fine if it's uninteresting to you and you don't want to follow
it, but let's please avoid judgments on entire mailing lists and, by
extension, the people holding conversations there.

Thanks,
Erik

From storchaka at gmail.com  Mon Jul  6 20:45:01 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 06 Jul 2015 21:45:01 +0300
Subject: [Python-Dev] What's New editing
In-Reply-To: <20150705175255.99CB6250EB5@webabinitio.net>
References: <20150705175255.99CB6250EB5@webabinitio.net>
Message-ID: <mneibd$g0o$1@ger.gmane.org>

On 05.07.15 20:52, R. David Murray wrote:
> Just so people aren't caught unawares, it is very unlikely that I will have
> time to be the final editor on "What's New for 3.5" they way I was for 3.3 and
> 3.4.  I've tried to encourage people to keep What's New up to date, but
> *someone* should make a final editing pass.  Ideally they'd do at least the
> research Serhiy did last year on checking that there's a mention for all of the
> versionadded and versionchanged 3.5's in the docs.  Even better would be to
> review the NEWS and/or commit history...but *that* is a really big job these
> days....

Many thanks you David for your invaluable work.

Here is 3.5 NEWS file cleaned from duplicates in 3.4 NEWS file (i.e. 
from entries about merged bug fixes). It is much less than unfiltered 
NEWS file. Hope this will help volunteers.
-------------- next part --------------
+++++++++++
Python News
+++++++++++

What's New in Python 3.6.0 alpha 1?
===================================

Release date: XXXX-XX-XX

Core and Builtins
-----------------

Library
-------

- Issue #24426: Fast searching optimization in regular expressions now works
  for patterns that starts with capturing groups.  Fast searching optimization
  now can't be disabled at compile time.


What's New in Python 3.5.0 beta 4?
==================================

Release date: 2015-07-26

Core and Builtins
-----------------

- Issue #24569: Make PEP 448 dictionary evaluation more consistent.

Library
-------


What's New in Python 3.5.0 beta 3?
==================================

Release date: 2015-07-05

Core and Builtins
-----------------

- Upgrade to Unicode 8.0.0.

- Issue #24345: Add Py_tp_finalize slot for the stable ABI.

- Issue #24400: Introduce a distinct type for PEP 492 coroutines; add
  types.CoroutineType, inspect.getcoroutinestate, inspect.getcoroutinelocals;
  coroutines no longer use CO_GENERATOR flag; sys.set_coroutine_wrapper
  works only for 'async def' coroutines; inspect.iscoroutine no longer
  uses collections.abc.Coroutine, it's intended to test for pure 'async def'
  coroutines only; add new opcode: GET_YIELD_FROM_ITER; fix generators wrapper
  used in types.coroutine to be instance of collections.abc.Generator;
  collections.abc.Awaitable and collections.abc.Coroutine can no longer
  be used to detect generator-based coroutines--use inspect.isawaitable
  instead.

- Issue #24450: Add gi_yieldfrom to generators and cr_await to coroutines.
  Contributed by Benno Leslie and Yury Selivanov.

- Issue #19235: Add new RecursionError exception. Patch by Georg Brandl.

Library
-------

- Issue #24522: Fix possible integer overflow in json accelerator module.

- Issue #24408: Fixed AttributeError in measure() and metrics() methods of
  tkinter.Font.

- Issue #14373: C implementation of functools.lru_cache() now can be used with
  methods.

- Issue #8232: webbrowser support incomplete on Windows. Patch by Brandon
  Milam

- Issue #24347: Set KeyError if PyDict_GetItemWithError returns NULL.

- Issue #24348: Drop superfluous incref/decref.

- Issue #24359: Check for changed OrderedDict size during iteration.

- Issue #24368: Support keyword arguments in OrderedDict methods.

- Issue #24362: Simplify the C OrderedDict fast nodes resize logic.

- Issue #24377: Fix a ref leak in OrderedDict.__repr__.

- Issue #24369: Defend against key-changes during iteration.

Tests
-----

- Issue #24373: _testmultiphase and xxlimited now use tp_traverse and
  tp_finalize to avoid reference leaks encountered when combining tp_dealloc
  with PyType_FromSpec (see issue #16690 for details)

Documentation
-------------

- Issue #24458: Update documentation to cover multi-phase initialization for
  extension modules (PEP 489). Patch by Petr Viktorin.

Build
-----


What's New in Python 3.5.0 beta 2?
==================================

Release date: 2015-05-31

Core and Builtins
-----------------

- Issue #24284: The startswith and endswith methods of the str class no longer
  return True when finding the empty string and the indexes are completely out
  of range.

- Issue #24328: Fix importing one character extension modules.

- Issue #11205: In dictionary displays, evaluate the key before the value.

- Issue #24285: Fixed regression that prevented importing extension modules
  from inside packages. Patch by Petr Viktorin.

Library
-------

- Issue #24270: Add math.isclose() and cmath.isclose() functions as per PEP 485.
  Contributed by Chris Barker and Tal Einat.

- Issue #16991: Add a C implementation of OrderedDict.

- Issue #23934: Fix inspect.signature to fail correctly for builtin types
  lacking signature information.  Initial patch by James Powell.


What's New in Python 3.5.0 beta 1?
==================================

Release date: 2015-05-24

Core and Builtins
-----------------

- Issue #24276: Fixed optimization of property descriptor getter.

- Issue #24268: PEP 489: Multi-phase extension module initialization.
  Patch by Petr Viktorin.

- Issue #23359: Optimize set object internals by specializing the
  hash table search into a lookup function and an insert function.

- Issue #23955: Add pyvenv.cfg option to suppress registry/environment
  lookup for generating sys.path on Windows.

- Issue #15027: The UTF-32 encoder is now 3x to 7x faster.

- Issue #23290:  Optimize set_merge() for cases where the target is empty.
  (Contributed by Serhiy Storchaka.)

- Issue #2292: PEP 448: Additional Unpacking Generalizations.

- Issue #23910: Optimize property() getter calls.  Patch by Joe Jevnik.

- Issue #23911: Move path-based importlib bootstrap code to a separate
  frozen module.

- Issue #24192: Fix namespace package imports.

- Issue #9951: Added a hex() method to bytes, bytearray, and memoryview.

- Issue #22906: PEP 479: Change StopIteration handling inside generators.

- Issue #24017: PEP 492: Coroutines with async and await syntax.

Library
-------

- Issue #14373: Added C implementation of functools.lru_cache().  Based on
  patches by Matt Joiner and Alexey Kachayev.

- Issue 24230: The tempfile module now accepts bytes for prefix, suffix and dir
  parameters and returns bytes in such situations (matching the os module APIs).

- Issue #22189: collections.UserString now supports __getnewargs__(),
  __rmod__(), casefold(), format_map(), isprintable(), and maketrans().
  Patch by Joe Jevnik.

- Issue 24244: Prevents termination when an invalid format string is
  encountered on Windows in strftime.

- Issue #23973: PEP 484: Add the typing module.

- Issue #23086: The collections.abc.Sequence() abstract base class added
  *start* and *stop* parameters to the index() mixin.
  Patch by Devin Jeanpierre.

- Issue #20035: Replaced the ``tkinter._fix`` module used for setting up the
  Tcl/Tk environment on Windows with a private function in the ``_tkinter``
  module that makes no permanent changes to the environment.

- Issue #15836: assertRaises(), assertRaisesRegex(), assertWarns() and
  assertWarnsRegex() assertments now check the type of the first argument
  to prevent possible user error.  Based on patch by Daniel Wagner-Hall.

- Issue #9858: Add missing method stubs to _io.RawIOBase.  Patch by Laura
  Rupprecht.

- Issue #22955: attrgetter, itemgetter and methodcaller objects in the operator
  module now support pickling.  Added readable and evaluable repr for these
  objects.  Based on patch by Josh Rosenberg.

- Issue #23780: Improved error message in os.path.join() with single argument.

- Issue #13866: *quote_via* argument added to urllib.parse.urlencode.

- Issue #20098: New mangle_from policy option for email, default True
  for compat32, but False for all other policies.

- Issue #24211: The email library now supports RFC 6532: it can generate
  headers using utf-8 instead of encoded words.

- Issue #16314: Added support for the LZMA compression in distutils.

- Issue #21804: poplib now supports RFC 6856 (UTF8).

- Issue #18682: Optimized pprint functions for builtin scalar types.

- Issue #22027: smtplib now supports RFC 6531 (SMTPUTF8).

- Issue #23488: Random generator objects now consume 2x less memory on 64-bit.

- Issue #1322: platform.dist() and platform.linux_distribution() functions are
  now deprecated.  Initial patch by Vajrasky Kok.

- Issue #22486: Added the math.gcd() function.  The fractions.gcd() function now is
  deprecated.  Based on patch by Mark Dickinson.

- Issue #24064: Property() docstrings are now writeable.
  (Patch by Berker Peksag.)

- Issue #22681: Added support for the koi8_t encoding.

- Issue #22682: Added support for the kz1048 encoding.

- Issue #21795: smtpd now supports the 8BITMIME extension whenever
  the new *decode_data* constructor argument is set to False.

- Issue #24155: optimize heapq.heapify() for better cache performance
  when heapifying large lists.

- Issue #21800: imaplib now supports RFC 5161 (enable), RFC 6855
  (utf8/internationalized email) and automatically encodes non-ASCII
  usernames and passwords to UTF8.

- Issue #20274: When calling a _sqlite.Connection, it now complains if passed
  any keyword arguments.  Previously it silently ignored them.

- Issue #24134: assertRaises(), assertRaisesRegex(), assertWarns() and
  assertWarnsRegex() checks now emits a deprecation warning when callable is
  None or keyword arguments except msg is passed in the context manager mode.

- Issue #24018: Add a collections.abc.Generator abstract base class.
  Contributed by Stefan Behnel.

- Issue #23880: Tkinter's getint() and getdouble() now support Tcl_Obj.
  Tkinter's getdouble() now supports any numbers (in particular int).

- Issue #22619: Added negative limit support in the traceback module.
  Based on patch by Dmitry Kazakov.

- Issue #17445: add difflib.diff_bytes() to support comparison of
  byte strings (fixes a regression from Python 2).

- Issue #23917: Fall back to sequential compilation when ProcessPoolExecutor
  doesn't exist.  Patch by Claudiu Popa.

- Fix asyncio issue 235: LifoQueue and PriorityQueue's put didn't
  increment unfinished tasks (this bug was introduced when
  JoinableQueue was merged with Queue).

- Issue #23887: urllib.error.HTTPError now has a proper repr() representation.
  Patch by Berker Peksag.

- Issue 24178: asyncio.Lock, Condition, Semaphore, and BoundedSemaphore
  support new 'async with' syntax.  Contributed by Yury Selivanov.

- Issue 24179: Support 'async for' for asyncio.StreamReader.
  Contributed by Yury Selivanov.

- Issue 24184: Add AsyncIterator and AsyncIterable ABCs to
  collections.abc.  Contributed by Yury Selivanov.

- Issue 22547: Implement informative __repr__ for inspect.BoundArguments.
  Contributed by Yury Selivanov.

- Issue 24190: Implement inspect.BoundArgument.apply_defaults() method.
  Contributed by Yury Selivanov.

- Issue 20691: Add 'follow_wrapped' argument to
  inspect.Signature.from_callable() and inspect.signature().
  Contributed by Yury Selivanov.

- Issue 24248: Deprecate inspect.Signature.from_function() and
  inspect.Signature.from_builtin().

IDLE
----

Tests
-----

- Issue #9517: Move script_helper into the support package.
  Patch by Christie Wilson.

Documentation
-------------

- Issue #24077: Fix typo in man page for -I command option: -s, not -S

Tools/Demos
-----------

- Issue #24000: Improved Argument Clinic's mapping of converters to legacy
  "format units".  Updated the documentation to match.

- Issue #24001: Argument Clinic converters now use accept={type}
  instead of types={'type'} to specify the types the converter accepts.


What's New in Python 3.5.0 alpha 4?
===================================

Release date: 2015-04-19

Core and Builtins
-----------------

- Issue #22980: Under Linux, GNU/KFreeBSD and the Hurd, C extensions now include
  the architecture triplet in the extension name, to make it easy to test builds
  for different ABIs in the same working tree.  Under OS X, the extension name
  now includes PEP 3149-style information.

- Issue #22631: Added Linux-specific socket constant CAN_RAW_FD_FRAMES.
  Patch courtesy of Joe Jevnik.

- Issue #23731: Implement PEP 488: removal of .pyo files.

- Issue #23726: Don't enable GC for user subclasses of non-GC types that
  don't add any new fields.  Patch by Eugene Toder.

- Issue #23466: %c, %o, %x, and %X in bytes formatting now raise TypeError on
  non-integer input.

Library
-------

- Issue #16914: new debuglevel 2 in smtplib adds timestamps to debug output.

- Issue #7159: urllib.request now supports sending auth credentials
  automatically after the first 401.  This enhancement is a superset of the
  enhancement from issue #19494 and supersedes that change.

- Issue #23703: Fix a regression in urljoin() introduced in 901e4e52b20a.
  Patch by Demian Brecht.

- Issue #4254: Adds _curses.update_lines_cols() Patch by Arnon Yaari

- Issue 19933: Provide default argument for ndigits in round. Patch by
  Vajrasky Kok.

- Issue #23193: Add a numeric_owner parameter to
  tarfile.TarFile.extract and tarfile.TarFile.extractall. Patch by
  Michael Vogt and Eric Smith.

- Issue #23342: Add a subprocess.run() function than returns a CalledProcess
  instance for a more consistent API than the existing call* functions.

- Issue #21217: inspect.getsourcelines() now tries to compute the start and end
  lines from the code object, fixing an issue when a lambda function is used as
  decorator argument. Patch by Thomas Ballinger and Allison Kaptur.

- Issue #21116: Avoid blowing memory when allocating a multiprocessing shared
  array that's larger than 50% of the available RAM.  Patch by M?d?ric Boquien.

- Issue #23464: Removed deprecated asyncio JoinableQueue.

- Issue #23529: Limit the size of decompressed data when reading from
  GzipFile, BZ2File or LZMAFile.  This defeats denial of service attacks
  using compressed bombs (i.e. compressed payloads which decompress to a huge
  size).  Patch by Martin Panter and Nikolaus Rath.

- Issue #21859: Added Python implementation of io.FileIO.

- Issue #10838: The subprocess now module includes SubprocessError and
  TimeoutError in its list of exported names for the users wild enough
  to use ``from subprocess import *``.

- Issue #23411: Added DefragResult, ParseResult, SplitResult, DefragResultBytes,
  ParseResultBytes, and SplitResultBytes to urllib.parse.__all__.
  Patch by Martin Panter.

- Issue #23853: :meth:`socket.socket.sendall` does no more reset the socket
  timeout each time data is sent successfuly. The socket timeout is now the
  maximum total duration to send all data.

- Issue #22721: An order of multiline pprint output of set or dict containing
  orderable and non-orderable elements no longer depends on iteration order of
  set or dict.

- Issue #10590: xml.sax.parseString() now supports string argument.

- Issue #15582: inspect.getdoc() now follows inheritance chains.

- Issue #2175: SAX parsers now support a character stream of InputSource object.

- Issue #23618: :meth:`socket.socket.connect` now waits until the connection
  completes instead of raising :exc:`InterruptedError` if the connection is
  interrupted by signals, signal handlers don't raise an exception and the
  socket is blocking or has a timeout. :meth:`socket.socket.connect` still
  raise :exc:`InterruptedError` for non-blocking sockets.

- Issue #23836: Fix the faulthandler module to handle reentrant calls to
  its signal handlers.

- Issue #10395: Added os.path.commonpath(). Implemented in posixpath and ntpath.
  Based on patch by Rafik Draoui.

- Issue #23611: Serializing more "lookupable" objects (such as unbound methods
  or nested classes) now are supported with pickle protocols < 4.

- Issue #13583: sqlite3.Row now supports slice indexing.

- Issue #23485: select.select() is now retried automatically with the
  recomputed timeout when interrupted by a signal, except if the signal handler
  raises an exception. This change is part of the PEP 475.

- Issue #23752: When built from an existing file descriptor, io.FileIO() now
  only calls fstat() once. Before fstat() was called twice, which was not
  necessary.

- Issue #23704: collections.deque() objects now support __add__, __mul__, and
  __imul__().

- Issue #23171: csv.Writer.writerow() now supports arbitrary iterables.

- Issue #22117: Fix os.utime(), it now rounds the timestamp towards minus
  infinity (-inf) instead of rounding towards zero.


Build
-----

- Issue #23817: FreeBSD now uses "1.0" the the SOVERSION as other operating
  systems, instead of just "1".

- Issue #23501: Argument Clinic now generates code into separate files by default.

Tests
-----

Tools/Demos
-----------

- Issue #18128: pygettext now uses standard +NNNN format in the
  POT-Creation-Date header.

- Issue #23935: Argument Clinic's understanding of format units
  accepting bytes, bytearrays, and buffers is now consistent with
  both the documentation and the implementation.

- Issue #23944: Argument Clinic now wraps long impl prototypes at column 78.

- Issue #20586: Argument Clinic now ensures that functions without docstrings
  have signatures.

- Issue #23492: Argument Clinic now generates argument parsing code with
  PyArg_Parse instead of PyArg_ParseTuple if possible.

- Issue #23500: Argument Clinic is now smarter about generating the "#ifndef"
  (empty) definition of the methoddef macro: it's only generated once, even
  if Argument Clinic processes the same symbol multiple times, and it's emitted
  at the end of all processing rather than immediately after the first use.

C API
-----


What's New in Python 3.5.0 alpha 3?
===================================

Release date: 2015-03-28

Core and Builtins
-----------------

- Issue #23573: Increased performance of string search operations (str.find,
  str.index, str.count, the in operator, str.split, str.partition) with
  arguments of different kinds (UCS1, UCS2, UCS4).

- Issue #23753: Python doesn't support anymore platforms without stat() or
  fstat(), these functions are always required.

- Issue #23681: The -b option now affects comparisons of bytes with int.

- Issue #23632: Memoryviews now allow tuple indexing (including for
  multi-dimensional memoryviews).

Library
-------

- Issue #14260: The groupindex attribute of regular expression pattern object
  now is non-modifiable mapping.

- Issue #23775: pprint() of OrderedDict now outputs the same representation
  as repr().

- Issue #23765: Removed IsBadStringPtr calls in ctypes

- Issue #22364: Improved some re error messages using regex for hints.

- Issue #21717: The zipfile.ZipFile.open function now supports 'x' (exclusive
  creation) mode.

- Issue #23622: Unknown escapes in regular expressions that consist of ``'\'``
  and ASCII letter now raise a deprecation warning and will be forbidden in
  Python 3.6.

- Issue #23502: The pprint module now supports mapping proxies.

- Issue #17530: pprint now wraps long bytes objects and bytearrays.

- Issue #22687: Fixed some corner cases in breaking words in tetxtwrap.
  Got rid of quadratic complexity in breaking long words.

- Issue #4727: The copy module now uses pickle protocol 4 (PEP 3154) and
  supports copying of instances of classes whose __new__ method takes
  keyword-only arguments.

- Issue #23491: Added a zipapp module to support creating executable zip
  file archives of Python code. Registered ".pyz" and ".pyzw" extensions
  on Windows for these archives (PEP 441).

- Issue #23657: Avoid explicit checks for str in zipapp, adding support
  for pathlib.Path objects as arguments.

- Issue #23688: Added support of arbitrary bytes-like objects and avoided
  unnecessary copying of memoryview in gzip.GzipFile.write().
  Original patch by Wolfgang Maier.

- Issue #23252:  Added support for writing ZIP files to unseekable streams.

- Issue #23704: collections.deque() objects now support methods for index(),
  insert(), and copy().  This allows deques to be registered as a
  MutableSequence and it improves their substitutablity for lists.

- Issue #23715: :func:`signal.sigwaitinfo` and :func:`signal.sigtimedwait` are
  now retried when interrupted by a signal not in the *sigset* parameter, if
  the signal handler does not raise an exception. signal.sigtimedwait()
  recomputes the timeout with a monotonic clock when it is retried.

- Issue #23001: Few functions in modules mmap, ossaudiodev, socket, ssl, and
  codecs, that accepted only read-only bytes-like object now accept writable
  bytes-like object too.

- Issue #23646: If time.sleep() is interrupted by a signal, the sleep is now
  retried with the recomputed delay, except if the signal handler raises an
  exception (PEP 475).

- Issue #22181: On Linux, os.urandom() now uses the new getrandom() syscall if
  available, syscall introduced in the Linux kernel 3.17. It is more reliable
  and more secure, because it avoids the need of a file descriptor and waits
  until the kernel has enough entropy.

- Issue #2211: Updated the implementation of the http.cookies.Morsel class.
  Setting attributes key, value and coded_value directly now is deprecated.
  update() and setdefault() now transform and check keys.  Comparing for
  equality now takes into account attributes key, value and coded_value.
  copy() now returns a Morsel, not a dict.  repr() now contains all attributes.
  Optimized checking keys and quoting values.  Added new tests.
  Original patch by Demian Brecht.

- Issue #18983: Allow selection of output units in timeit.
  Patch by Julian Gindi.

- Issue #23631: Fix traceback.format_list when a traceback has been mutated.

- Issue #2052: Add charset parameter to HtmlDiff.make_file().

- Issue #23668: Support os.truncate and os.ftruncate on Windows.

- Issue #23581: Add matmul support to MagicMock. Patch by H?kan L?vdahl.

- Issue #23566: enable(), register(), dump_traceback() and
  dump_traceback_later() functions of faulthandler now accept file
  descriptors. Patch by Wei Wu.

- Issue #23605: os.walk() now calls os.scandir() instead of os.listdir().
  The usage of os.scandir() reduces the number of calls to os.stat().
  Initial patch written by Ben Hoyt.

Build
-----

- Issue #23585: make patchcheck will ensure the interpreter is built.

Tests
-----

Tools/Demos
-----------

- Issue #22826: The result of open() in Tools/freeze/bkfile.py is now better
  compatible with regular files (in particular it now supports the context
  management protocol).


What's New in Python 3.5 alpha 2?
=================================

Release date: 2015-03-09

Core and Builtins
-----------------

- Issue #23571: PyObject_Call() and PyCFunction_Call() now raise a SystemError
  if a function returns a result and raises an exception. The SystemError is
  chained to the previous exception.

Library
-------

- Issue #22524: New os.scandir() function, part of the PEP 471: "os.scandir()
  function -- a better and faster directory iterator". Patch written by Ben
  Hoyt.

- Issue #23103: Reduced the memory consumption of IPv4Address and IPv6Address.

- Issue #21793: BaseHTTPRequestHandler again logs response code as numeric,
  not as stringified enum.  Patch by Demian Brecht.

- Issue #23563: Optimized utility functions in urllib.parse.

- Issue #7830: Flatten nested functools.partial.

- Issue #19980: Improved help() for non-recognized strings.  help('') now
  shows the help on str.  help('help') now shows the help on help().
  Original patch by Mark Lawrence.

 * Eliminated OverflowError from timedelta * float for some floats;
 * Corrected rounding in timedlta true division.

- Issue #22936: Make it possible to show local variables in tracebacks for
  both the traceback module and unittest.

- Issue #15955: Add an option to limit the output size in bz2.decompress().
  Patch by Nikolaus Rath.

- Issues #814253, #9179: Group references and conditional group references now
  work in lookbehind assertions in regular expressions.

- Issue #23239: ssl.match_hostname() now supports matching of IP addresses.

- Issue #23096: Pickle representation of floats with protocol 0 now is the same
  for both Python and C implementations.

- Issue #19105: pprint now more efficiently uses free space at the right.

- Issue #14910: Add allow_abbrev parameter to argparse.ArgumentParser. Patch by
  Jonathan Paugh, Steven Bethard, paul j3 and Daniel Eriksson.

- Issue #21717: tarfile.open() now supports 'x' (exclusive creation) mode.

- Issue #23344: marshal.dumps() is now 20-25% faster on average.

- Issue #20416: marshal.dumps() with protocols 3 and 4 is now 40-50% faster on
  average.

- logging.handlers.QueueListener now takes a respect_handler_level keyword
  argument which, if set to True, will pass messages to handlers taking handler
  levels into account.

- Issue #19705: turtledemo now has a visual sorting algorithm demo.  Original
  patch from Jason Yeo.

Build
-----

- Issue #23686: Update OS X 10.5 installer build to use OpenSSL 1.0.2a.

C API
-----

- Issue #20204: Deprecation warning is now raised for builtin type without the
  __module__ attribute.

Windows
-------

- Issue #23465: Implement PEP 486 - Make the Python Launcher aware of virtual
  environments. Patch by Paul Moore.

- Issue #23437: Make user scripts directory versioned on Windows. Patch by Paul
  Moore.


What's New in Python 3.5 alpha 1?
=================================

Release date: 2015-02-08

Core and Builtins
-----------------

- Issue #23285: PEP 475 - EINTR handling.

- Issue #22986: Allow changing an object's __class__ between a dynamic type and
  static type in some cases.

- Issue #15859: PyUnicode_EncodeFSDefault(), PyUnicode_EncodeMBCS() and
  PyUnicode_EncodeCodePage() now raise an exception if the object is not an
  Unicode object. For PyUnicode_EncodeFSDefault(), it was already the case on
  platforms other than Windows. Patch written by Campbell Barton.

- Issue #22286: The "backslashreplace" error handlers now works with
  decoding and translating.

- Issue #23253: Delay-load ShellExecute[AW] in os.startfile for reduced
  startup overhead on Windows.

- Issue #22038: pyatomic.h now uses stdatomic.h or GCC built-in functions for
  atomic memory access if available. Patch written by Vitor de Lima and Gustavo
  Temple.

- Issue #20284: %-interpolation (aka printf) formatting added for bytes and
  bytearray.

- Issue #22834: If the current working directory ends up being set to a
  non-existent directory then import will no longer raise FileNotFoundError.

- Issue #22869: Move the interpreter startup & shutdown code to a new
  dedicated pylifecycle.c module

- Issue #22847: Improve method cache efficiency.

- Issue #17636: Circular imports involving relative imports are now
  supported.

- Issue #21052: Do not raise ImportWarning when sys.path_hooks or sys.meta_path
  are set to None.

- Issue #16518: Use 'bytes-like object required' in error messages that
  previously used the far more cryptic "'x' does not support the buffer
  protocol.

- Issue #22540: speed up `PyObject_IsInstance` and `PyObject_IsSubclass` in the
  common case that the second argument has metaclass `type`.

- Issue #18711: Add a new `PyErr_FormatV` function, similar to `PyErr_Format`
  but accepting a `va_list` argument.

- Issue #16324: _charset parameter of MIMEText now also accepts
  email.charset.Charset instances. Initial patch by Claude Paroz.

- Issue #1764286: Fix inspect.getsource() to support decorated functions.
  Patch by Claudiu Popa.

- Issue #18554: os.__all__ includes posix functions.

- Issue #21391: Use os.path.abspath in the shutil module.

- Issue #11471: avoid generating a JUMP_FORWARD instruction at the end of
  an if-block if there is no else-clause.  Original patch by Eugene Toder.

- Issue #22215: Now ValueError is raised instead of TypeError when str or bytes
  argument contains not permitted null character or byte.

- Issue #22258: Fix the internal function set_inheritable() on Illumos.
  This platform exposes the function ``ioctl(FIOCLEX)``, but calling it fails
  with errno is ENOTTY: "Inappropriate ioctl for device". set_inheritable()
  now falls back to the slower ``fcntl()`` (``F_GETFD`` and then ``F_SETFD``).

- Issue #21389: Displaying the __qualname__ of the underlying function in the
  repr of a bound method.

- Issue #22206: Using pthread, PyThread_create_key() now sets errno to ENOMEM
  and returns -1 (error) on integer overflow.

- Issue #20184: Argument Clinic based signature introspection added for
  30 of the builtin functions.

- Issue #22116: C functions and methods (of the 'builtin_function_or_method'
  type) can now be weakref'ed.  Patch by Wei Wu.

- Issue #22077: Improve index error messages for bytearrays, bytes, lists,
  and tuples by adding 'or slices'. Added ', not <typename' for bytearrays.
  Original patch by Claudiu Popa.

- Issue #20179: Apply Argument Clinic to bytes and bytearray.
  Patch by Tal Einat.

- Issue #22082: Clear interned strings in slotdefs.

- Upgrade Unicode database to Unicode 7.0.0.

- Issue #21205: Add a new ``__qualname__`` attribute to generator, the
  qualified name, and use it in the representation of a generator
  (``repr(gen)``). The default name of the generator (``__name__`` attribute)
  is now get from the function instead of the code. Use ``gen.gi_code.co_name``
  to get the name of the code.

- Issue #21377: PyBytes_Concat() now tries to concatenate in-place when the
  first argument has a reference count of 1.  Patch by Nikolaus Rath.

- Issue #20355: -W command line options now have higher priority than the
  PYTHONWARNINGS environment variable.  Patch by Arfrever.

- Issue #20904: Support setting FPU precision on m68k.

- Issue #21193: pow(a, b, c) now raises ValueError rather than TypeError when b
  is negative.  Patch by Josh Rosenberg.

- PEP 465 and Issue #21176: Add the '@' operator for matrix multiplication.

- Issue #8297: Attributes missing from modules now include the module name
  in the error text.  Original patch by ysj.ray.

- Issue #19995: %c, %o, %x, and %X now raise TypeError on non-integer input.

- Issue #19655: The ASDL parser - used by the build process to generate code for
  managing the Python AST in C - was rewritten. The new parser is self contained
  and does not require to carry long the spark.py parser-generator library;
  spark.py was removed from the source base.

- Issue #20480: Add ipaddress.reverse_pointer. Patch by Leon Weber.

- Issue #8931: Make alternate formatting ('#') for type 'c' raise an
  exception. In versions prior to 3.5, '#' with 'c' had no effect. Now
  specifying it is an error.  Patch by Torsten Landschoff.

Library
-------

- Issue #20289: cgi.FieldStorage() now supports the context management
  protocol.

- Issue #13128: Print response headers for CONNECT requests when debuglevel
  > 0. Patch by Demian Brecht.

- Issue #15381: Optimized io.BytesIO to make less allocations and copyings.

- Issue #22818: Splitting on a pattern that could match an empty string now
  raises a warning.  Patterns that can only match empty strings are now
  rejected.

- Issue #23326: Removed __ne__ implementations.  Since fixing default __ne__
  implementation in issue #21408 they are redundant.

- Issue #14099: Restored support of writing ZIP files to tellable but
  non-seekable streams.

- Issue #14099: Writing to ZipFile and reading multiple ZipExtFiles is
  threadsafe now.

- Issue #19361: JSON decoder now raises JSONDecodeError instead of ValueError.

- Issue #20188: Support Application-Layer Protocol Negotiation (ALPN) in the ssl
  module.

- Issue #23133: Pickling of ipaddress objects now produces more compact and
  portable representation.

- Issue #23266: Much faster implementation of ipaddress.collapse_addresses()
  when there are many non-consecutive addresses.

- Issue #21817: When an exception is raised in a task submitted to a
  ProcessPoolExecutor, the remote traceback is now displayed in the
  parent process.  Patch by Claudiu Popa.

- Issue #15955: Add an option to limit output size when decompressing LZMA
  data.  Patch by Nikolaus Rath and Martin Panter.

- Issue #23209, #23225: selectors.BaseSelector.get_key() now raises a
  RuntimeError if the selector is closed. And selectors.BaseSelector.close()
  now clears its internal reference to the selector mapping to break a
  reference cycle. Initial patch written by Martin Richard.

- Issue #17911: Provide a way to seed the linecache for a PEP-302 module
  without actually loading the code.

- Issue #17911: Provide a new object API for traceback, including the ability
  to not lookup lines at all until the traceback is actually rendered, without
  any trace of the original objects being kept alive.

- Issue #19777: Provide a home() classmethod on Path objects.  Contributed
  by Victor Salgado and Mayank Tripathi.

- Issue #23206: Make ``json.dumps(..., ensure_ascii=False)`` as fast as the
  default case of ``ensure_ascii=True``.  Patch by Naoki Inada.

- Issue #23185: Add math.inf and math.nan constants.

- Issue #23186: Add ssl.SSLObject.shared_ciphers() and
  ssl.SSLSocket.shared_ciphers() to fetch the client's list ciphers sent at
  handshake.

- Issue #23143: Remove compatibility with OpenSSLs older than 0.9.8.

- Issue #23132: Improve performance and introspection support of comparison
  methods created by functool.total_ordering.

- Issue #19776: Add a expanduser() method on Path objects.

- Issue #21793: Added http.HTTPStatus enums (i.e. HTTPStatus.OK,
  HTTPStatus.NOT_FOUND).  Patch by Demian Brecht.

- Issue #22783: Pickling now uses the NEWOBJ opcode instead of the NEWOBJ_EX
  opcode if possible.

- Issue #21740: Support wrapped callables in doctest. Patch by Claudiu Popa.

- Issue #22696: Add function :func:`sys.is_finalizing` to know about
  interpreter shutdown.

- Issue #14099: ZipFile.open() no longer reopen the underlying file.  Objects
  returned by ZipFile.open() can now operate independently of the ZipFile even
  if the ZipFile was created by passing in a file-like object as the first
  argument to the constructor.

- Issue #22407: Deprecated the use of re.LOCALE flag with str patterns or
  re.ASCII. It was newer worked.

- Issue #22902: The "ip" command is now used on Linux to determine MAC address
  in uuid.getnode().  Pach by Bruno Cauet.

- Issue #22389: Add contextlib.redirect_stderr().

- Issue #22940: Add readline.append_history_file.

- Issue #19676: Added the "namereplace" error handler.

- Issue #22796: HTTP cookie parsing is now stricter, in order to protect
  against potential injection attacks.

- Issue #19494: Added urllib.request.HTTPBasicPriorAuthHandler. Patch by
  Matej Cepl.

- Issue #22578: Added attributes to the re.error class.

- Issue #21650: Add an `--sort-keys` option to json.tool CLI.

- Issue #22824:  Updated reprlib output format for sets to use set literals.
  Patch contributed by Berker Peksag.

- Issue #22824:  Updated reprlib output format for arrays to display empty
  arrays without an unnecessary empty list.  Suggested by Serhiy Storchaka.

- Issue #6623: Remove deprecated Netrc class in the ftplib module. Patch by
  Matt Chaput.

- Issue #22217: Implemented reprs of classes in the zipfile module.

- Issue #22457: Honour load_tests in the start_dir of discovery.

- Issue #18216: gettext now raises an error when a .mo file has an
  unsupported major version number.  Patch by Aaron Hill.

- Issue #13918: Provide a locale.delocalize() function which can remove
  locale-specific number formatting from a string representing a number,
  without then converting it to a specific type.  Patch by C?dric Krier.

- Issue #22676: Make the pickling of global objects which don't have a
  __module__ attribute less slow.

- Issue #7559: unittest test loading ImportErrors are reported as import errors
  with their import exception rather than as attribute errors after the import
  has already failed.

- Issue #19746: Make it possible to examine the errors from unittest
  discovery without executing the test suite. The new `errors` attribute
  on TestLoader exposes these non-fatal errors encountered during discovery.

- Issue #17401: Include closefd in io.FileIO repr.

- Issue #21338: Add silent mode for compileall. quiet parameters of
  compile_{dir, file, path} functions now have a multilevel value. Also,
  -q option of the CLI now have a multilevel value. Patch by Thomas Kluyver.

- Issue #20152: Convert the array and cmath modules to Argument Clinic.

- Issue #18643: Add socket.socketpair() on Windows.

- Issue #19380: Optimized parsing of regular expressions.

- Issue #1519638: Now unmatched groups are replaced with empty strings in re.sub()
  and re.subn().

- Issue #18615: sndhdr.what/whathdr now return a namedtuple.

- Issue #21965: Add support for in-memory SSL to the ssl module.  Patch
  by Geert Jansen.

- Issue #11271: concurrent.futures.Executor.map() now takes a *chunksize*
  argument to allow batching of tasks in child processes and improve
  performance of ProcessPoolExecutor.  Patch by Dan O'Reilly.

- Issue #21883: os.path.join() and os.path.relpath() now raise a TypeError with
  more helpful error message for unsupported or mismatched types of arguments.

- Issue #22508: The email.__version__ variable has been removed; the email
  code is no longer shipped separately from the stdlib, and __version__
  hasn't been updated in several releases.

- Issue #20218: Added convenience methods read_text/write_text and read_bytes/
  write_bytes to pathlib.Path objects.

- Issue #22437: Number of capturing groups in regular expression is no longer
  limited by 100.

- Issue #17442: InteractiveInterpreter now displays the full chained traceback
  in its showtraceback method, to match the built in interactive interpreter.

- Issue #5309: distutils' build and build_ext commands now accept a ``-j``
  option to enable parallel building of extension modules.

- Issue #22362: Forbidden ambiguous octal escapes out of range 0-0o377 in
  regular expressions.

- Issue #22278: Fix urljoin problem with relative urls, a regression observed
  after changes to issue22118 were submitted.

- Issue #21091: Fix API bug: email.message.EmailMessage.is_attachment is now
  a method.

- Issue #20537: logging methods now accept an exception instance as well as a
  Boolean value or exception tuple. Thanks to Yury Selivanov for the patch.

- Issue #13968: The glob module now supports recursive search in
  subdirectories using the "**" pattern.

- Issue #12410: imaplib.IMAP4 now supports the context management protocol.
  Original patch by Tarek Ziad?.

- Issue #21270: We now override tuple methods in mock.call objects so that
  they can be used as normal call attributes.

- Issue #16662: load_tests() is now unconditionally run when it is present in
  a package's __init__.py.  TestLoader.loadTestsFromModule() still accepts
  use_load_tests, but it is deprecated and ignored.  A new keyword-only
  attribute `pattern` is added and documented.  Patch given by Robert Collins,
  tweaked by Barry Warsaw.

- Issue #20421: Add a .version() method to SSL sockets exposing the actual
  protocol version in use.

- Issue #19546: configparser exceptions no longer expose implementation details.
  Chained KeyErrors are removed, which leads to cleaner tracebacks.  Patch by
  Claudiu Popa.

- Issue #22043: time.monotonic() is now always available.
  ``threading.Lock.acquire()``, ``threading.RLock.acquire()`` and socket
  operations now use a monotonic clock, instead of the system clock, when a
  timeout is used.

- Issue #21527: Add a default number of workers to ThreadPoolExecutor equal
  to 5 times the number of CPUs.  Patch by Claudiu Popa.

- Issue #22098: ctypes' BigEndianStructure and LittleEndianStructure now
  define an empty __slots__ so that subclasses don't always get an instance
  dict.  Patch by Claudiu Popa.

- Issue #22287: On UNIX, _PyTime_gettimeofday() now uses
  clock_gettime(CLOCK_REALTIME) if available. As a side effect, Python now
  depends on the librt library on Solaris and on Linux (only with glibc older
  than 2.17).

- Issue #22042: signal.set_wakeup_fd(fd) now raises an exception if the file
  descriptor is in blocking mode.

- Issue #16808: inspect.stack() now returns a named tuple instead of a tuple.
  Patch by Daniel Shahaf.

- Issue #2527: Add a *globals* argument to timeit functions, in order to
  override the globals namespace in which the timed code is executed.
  Patch by Ben Roberts.

- Issue #22118: Switch urllib.parse to use RFC 3986 semantics for the
  resolution of relative URLs, rather than RFCs 1808 and 2396.
  Patch by Demian Brecht.

- Issue #21549: Added the "members" parameter to TarFile.list().

- Issue #19628: Allow compileall recursion depth to be specified with a -r
  option.

- Issue #15381: Optimized line reading in io.BytesIO.

- Issue #21725: Added support for RFC 6531 (SMTPUTF8) in smtpd.

- Issue #5411: Added support for the "xztar" format in the shutil module.

- Issue #20170: Convert posixmodule to use Argument Clinic.

- Issue #21539: Add a *exists_ok* argument to `Pathlib.mkdir()` to mimic
  `mkdir -p` and `os.makedirs()` functionality.  When true, ignore
  FileExistsErrors.  Patch by Berker Peksag.

- Issue #22127: Bypass IDNA for pure-ASCII host names in the socket module
  (in particular for numeric IPs).

- Issue #21047: set the default value for the *convert_charrefs* argument
  of HTMLParser to True.  Patch by Berker Peksag.

- Add an __all__ to html.entities.

- Issue #15114: the strict mode and argument of HTMLParser, HTMLParser.error,
  and the HTMLParserError exception have been removed.

- Issue #22085: Dropped support of Tk 8.3 in Tkinter.

- Issue #22003: When initialized from a bytes object, io.BytesIO() now
  defers making a copy until it is mutated, improving performance and
  memory use on some use cases.  Patch by David Wilson.

- Issue #22018: On Windows, signal.set_wakeup_fd() now also supports sockets.
  A side effect is that Python depends to the WinSock library.

- Issue #22054: Add os.get_blocking() and os.set_blocking() functions to get
  and set the blocking mode of a file descriptor (False if the O_NONBLOCK flag
  is set, True otherwise). These functions are not available on Windows.

- Issue #20173: Convert sha1, sha256, sha512 and md5 to ArgumentClinic.
  Patch by Vajrasky Kok.

- Issue #22033: Reprs of most Python implemened classes now contain actual
  class name instead of hardcoded one.

- Issue #21947: The dis module can now disassemble generator-iterator
  objects based on their gi_code attribute. Patch by Clement Rouault.

- Issue #4350: Removed a number of out-of-dated and non-working for a long time
  Tkinter methods.

- Issue #6167: Scrollbar.activate() now returns the name of active element if
  the argument is not specified.  Scrollbar.set() now always accepts only 2
  arguments.

- Issue #15275: Clean up and speed up the ntpath module.

- Issue #22032: __qualname__ instead of __name__ is now always used to format
  fully qualified class names of Python implemented classes.

- Issue #22031: Reprs now always use hexadecimal format with the "0x" prefix
  when contain an id in form " at 0x...".

- Issue #22018: signal.set_wakeup_fd() now raises an OSError instead of a
  ValueError on ``fstat()`` failure.

- Issue #21966: Respect -q command-line option when code module is ran.

- Issue #16382: Improve exception message of warnings.warn() for bad
  category. Initial patch by Phil Elson.

- Issue #21932: os.read() now uses a :c:func:`Py_ssize_t` type instead of
  :c:type:`int` for the size to support reading more than 2 GB at once. On
  Windows, the size is truncted to INT_MAX. As any call to os.read(), the OS
  may read less bytes than the number of requested bytes.

- Issue #15014: Added 'auth' method to smtplib to make implementing auth
  mechanisms simpler, and used it internally in the login method.

- Issue #5800: headers parameter of wsgiref.headers.Headers is now optional.
  Initial patch by Pablo Torres Navarrete and SilentGhost.

- Issue #21679: Prevent extraneous fstat() calls during open().  Patch by
  Bohuslav Kabrda.

- Issue #21863: cProfile now displays the module name of C extension functions,
  in addition to their own name.

- Issue #20295: imghdr now recognizes OpenEXR format images.

- Issue #21719: Added the ``st_file_attributes`` field to os.stat_result on
  Windows.

- Issue #21711: support for "site-python" directories has now been removed
  from the site module (it was deprecated in 3.4).

- Issue #17552: new socket.sendfile() method allowing to send a file over a
  socket by using high-performance os.sendfile() on UNIX.
  Patch by Giampaolo Rodola'.

- Issue #18039: dbm.dump.open() now always creates a new database when the
  flag has the value 'n'.  Patch by Claudiu Popa.

- Issue #21256: Printout of keyword args should be in deterministic order in
  a mock function call. This will help to write better doctests.

- Issue #21515: tempfile.TemporaryFile now uses os.O_TMPFILE flag is available.

- Issue #20383: Introduce importlib.util.module_from_spec() as the preferred way
  to create a new module.

- Issue #13742:  Added "key" and "reverse" parameters to heapq.merge().
  (First draft of patch contributed by Simon Sapin.)

- Issue #3015: _tkinter.create() now creates tkapp object with wantobject=1 by
  default.

- Issue #20197: Added support for the WebP image type in the imghdr module.
  Patch by Fabrice Aneche and Claudiu Popa.

- Issue #21513: Speedup some properties of IP addresses (IPv4Address,
  IPv6Address) such as .is_private or .is_multicast.

- Issue #21137: Improve the repr for threading.Lock() and its variants
  by showing the "locked" or "unlocked" status.  Patch by Berker Peksag.

- Issue #21455: Add a default backlog to socket.listen().

- Issue #21525: Most Tkinter methods which accepted tuples now accept lists too.

- Issue #20826: Optimize ipaddress.collapse_addresses().

- Issue #21487: Optimize ipaddress.summarize_address_range() and
  ipaddress.{IPv4Network,IPv6Network}.subnets().

- Issue #21486: Optimize parsing of netmasks in ipaddress.IPv4Network and
  ipaddress.IPv6Network.

- Issue #13916: Disallowed the surrogatepass error handler for non UTF-*
  encodings.

- Issue #19775: Add a samefile() method to pathlib Path objects.  Initial
  patch by Vajrasky Kok.

- Issue #21226: Set up modules properly in PyImport_ExecCodeModuleObject
  (and friends).

- Issue #16531: ipaddress.IPv4Network and ipaddress.IPv6Network now accept
  an (address, netmask) tuple argument, so as to easily construct network
  objects from existing addresses.

- Issue #21156: importlib.abc.InspectLoader.source_to_code() is now a
  staticmethod.

- Issue #21424: Simplified and optimized heaqp.nlargest() and nmsmallest()
  to make fewer tuple comparisons.

- Issue #18314: Unlink now removes junctions on Windows. Patch by Kim Gr?sman

- Issue #21407: _decimal: The module now supports function signatures.

- Issue #10650: Remove the non-standard 'watchexp' parameter from the
  Decimal.quantize() method in the Python version.  It had never been
  present in the C version.

- Issue #19414: Have the OrderedDict mark deleted links as unusable.
  This gives an early failure if the link is deleted during iteration.

- Issue #21421: Add __slots__ to the MappingViews ABC.
  Patch by Josh Rosenberg.

- Issue #21101: Eliminate double hashing in the C speed-up code for
  collections.Counter().

- Issue #21057: TextIOWrapper now allows the underlying binary stream's
  read() or read1() method to return an arbitrary bytes-like object
  (such as a memoryview).  Patch by Nikolaus Rath.

- Issue #20951: SSLSocket.send() now raises either SSLWantReadError or
  SSLWantWriteError on a non-blocking socket if the operation would block.
  Previously, it would return 0.  Patch by Nikolaus Rath.

- Issue #13248: removed previously deprecated asyncore.dispatcher __getattr__
  cheap inheritance hack.

- Issue #19940: ssl.cert_time_to_seconds() now interprets the given time
  string in the UTC timezone (as specified in RFC 5280), not the local
  timezone.

- Issue #21068: The ssl.PROTOCOL* constants are now enum members.

- Issue #21262: New method assert_not_called for Mock.
  It raises AssertionError if the mock has been called.

- Issue #21238: New keyword argument `unsafe` to Mock. It raises
  `AttributeError` incase of an attribute startswith assert or assret.

- Issue #20896: ssl.get_server_certificate() now uses PROTOCOL_SSLv23, not
  PROTOCOL_SSLv3, for maximum compatibility.

- Issue #21203: Updated fileConfig and dictConfig to remove inconsistencies.
  Thanks to Jure Koren for the patch.

- Issue #20539: Improved math.factorial error message for large positive inputs
  and changed exception type (OverflowError -> ValueError) for large negative
  inputs.

- Issue #21136: Avoid unnecessary normalization of Fractions resulting from
  power and other operations.  Patch by Raymond Hettinger.

- Issue #17621: Introduce importlib.util.LazyLoader.

- Issue #21076: signal module constants were turned into enums.
  Patch by Giampaolo Rodola'.

- Issue #20636: Improved the repr of Tkinter widgets.

- Issue #19505: The items, keys, and values views of OrderedDict now support
  reverse iteration using reversed().

- Issue #21000: Improve the command-line interface of json.tool.

- Issue #20627: xmlrpc.client.ServerProxy is now a context manager.

- Issue #19165: The formatter module now raises DeprecationWarning instead of
  PendingDeprecationWarning.

- Issue #13936: Remove the ability of datetime.time instances to be considered
  false in boolean contexts.

- Issue 18931: selectors module now supports /dev/poll on Solaris.
  Patch by Giampaolo Rodola'.

- Issue #19977: When the ``LC_TYPE`` locale is the POSIX locale (``C`` locale),
  :py:data:`sys.stdin` and :py:data:`sys.stdout` are now using the
  ``surrogateescape`` error handler, instead of the ``strict`` error handler.

- Issue #20574: Implement incremental decoder for cp65001 code (Windows code
  page 65001, Microsoft UTF-8).

- Issue #19573: inspect.signature: Use enum for parameter kind constants.

- Issue #20726: inspect.signature: Make Signature and Parameter picklable.

- Issue #17373: Add inspect.Signature.from_callable method.

- Issue #20378: Improve repr of inspect.Signature and inspect.Parameter.

- Issue #20334: inspect.Signature and inspect.Parameter are now hashable.
  Thanks to Antony Lee for bug reports and suggestions.

- Issue #15916: doctest.DocTestSuite returns an empty unittest.TestSuite instead
  of raising ValueError if it finds no tests

- Issue #22733: Fix ffi_prep_args not zero-extending argument values correctly
  on 64-bit Windows.

- Issue #23302: Default to TCP_NODELAY=1 upon establishing an HTTPConnection.
  Removed use of hard-coded MSS as it's an optimization that's no longer needed
  with Nagle disabled.

IDLE
----

- Issue #21477: htest.py - Improve framework, complete set of tests.
  Patches by Saimadhav Heblikar

Build
-----

- Issue #22592: Drop support of the Borland C compiler to build Python. The
  distutils module still supports it to build extensions.

- Issue #22591: Drop support of MS-DOS, especially of the DJGPP compiler
  (MS-DOS port of GCC).

- Issue #22359: Remove incorrect uses of recursive make.  Patch by Jonas
  Wagner.

- Issue #18093: the programs that embed the CPython runtime are now in a
  separate "Programs" directory, rather than being kept in the Modules
  directory.

- Issue #21141: The Windows build process no longer attempts to find Perl,
  instead relying on OpenSSL source being configured and ready to build.  The
  ``PCbuild\build_ssl.py`` script has been re-written and re-named to
  ``PCbuild\prepare_ssl.py``, and takes care of configuring OpenSSL source
  for both 32 and 64 bit platforms.  OpenSSL sources obtained from
  svn.python.org will always be pre-configured and ready to build.

- Issue #21037: Add a build option to enable AddressSanitizer support.

- Issue #19962: The Windows build process now creates "python.bat" in the
  root of the source tree, which passes all arguments through to the most
  recently built interpreter.

- Issue #17861: Tools/scripts/generate_opcode_h.py automatically regenerates
  Include/opcode.h from Lib/opcode.py if the later gets any change.

- Issue #20022: Eliminate use of deprecated bundlebuilder in OS X builds.

- Issue #15968: Incorporated Tcl, Tk, and Tix builds into the Windows build
  solution.

- Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015),
  which will be used for the official release.

- Issue #21236: Build _msi.pyd with cabinet.lib instead of fci.lib

- Issue #17128: Use private version of OpenSSL for OS X 10.5+ installer.

C API
-----

- Issue #14203: Remove obsolete support for view==NULL in PyBuffer_FillInfo(),
  bytearray_getbuffer(), bytesiobuf_getbuffer() and array_buffer_getbuf().
  All functions now raise BufferError in that case.

- Issue #22445: PyBuffer_IsContiguous() now implements precise contiguity
  tests, compatible with NumPy's NPY_RELAXED_STRIDES_CHECKING compilation
  flag.  Previously the function reported false negatives for corner cases.

- Issue #22453: Removed non-documented macro PyObject_REPR().

- Issue #18395: Rename ``_Py_char2wchar()`` to :c:func:`Py_DecodeLocale`,
  rename ``_Py_wchar2char()`` to :c:func:`Py_EncodeLocale`, and document
  these functions.

- Issue #21233: Add new C functions: PyMem_RawCalloc(), PyMem_Calloc(),
  PyObject_Calloc(), _PyObject_GC_Calloc(). bytes(int) is now using
  ``calloc()`` instead of ``malloc()`` for large objects which is faster and
  use less memory.

Documentation
-------------

- Issue #22394: Doc/Makefile now supports ``make venv PYTHON=../python`` to
  create a venv for generating the documentation, e.g.,
  ``make html PYTHON=venv/bin/python3``.

- Issue #6916: undocument deprecated asynchat.fifo class.

- Issue #21312: Update the thread_foobar.h template file to include newer
  threading APIs.  Patch by Jack McCracken.

Tests
-----

- Issue #22111: Assorted cleanups in test_imaplib.  Patch by Milan Oberkirch.

- Issue #9554: Use modern unittest features in test_argparse. Initial patch by
  Denver Coneybeare and Radu Voicilas.

- Issue #21503: Use test_both() consistently in test_importlib.

Tools/Demos
-----------

- Issue #22615: Argument Clinic now supports the "type" argument for the
  int converter.  This permits using the int converter with enums and
  typedefs.

- Issue #20076: The makelocalealias.py script no longer ignores UTF-8 mapping.

- Issue #20079: The makelocalealias.py script now can parse the SUPPORTED file
  from glibc sources and supports command line options for source paths.

- Issue #22120: For functions using an unsigned integer return converter,
  Argument Clinic now generates a cast to that type for the comparison
  to -1 in the generated code.  (This supresses a compilation warning.)

- Issue #18974: Tools/scripts/diff.py now uses argparse instead of optparse.

Windows
-------

- Issue #23260: Update Windows installer

- The bundled version of Tcl/Tk has been updated to 8.6.3.  The most visible
  result of this change is the addition of new native file dialogs when
  running on Windows Vista or newer.  See Tcl/Tk's TIP 432 for more
  information.  Also, this version of Tcl/Tk includes support for Windows 10.

- Issue #21907: Improved the batch scripts provided for building Python.

- Issue #22980: .pyd files with a version and platform tag (for example,
  ".cp35-win32.pyd") will now be loaded in preference to those without tags.

What's New in Python 3.4.0?
===========================

Release date: 2014-03-16

Library
-------

Documentation
-------------


What's New in Python 3.4.0 release candidate 3?
===============================================

Release date: 2014-03-09

Core and Builtins
-----------------

Library
-------

Build
-----


What's New in Python 3.4.0 release candidate 2?
===============================================

Release date: 2014-02-23

Core and Builtins
-----------------

Library
-------

Build
-----


What's New in Python 3.4.0 release candidate 1?
===============================================

Release date: 2014-02-10

Core and Builtins
-----------------

Library
-------

IDLE
----

Tests
-----

Tools/Demos
-----------

Build
-----

C-API
-----

Documentation
-------------


What's New in Python 3.4.0 Beta 3?
==================================

Release date: 2014-01-26

Core and Builtins
-----------------

Library
-------

IDLE
----

Tests
-----

Tools/Demos
-----------

Build
-----

What's New in Python 3.4.0 Beta 2?
==================================

Release date: 2014-01-05

Core and Builtins
-----------------

Library
-------

IDLE
----

Tests
-----

Build
-----

Documentation
-------------

Tools/Demos
-----------

What's New in Python 3.4.0 Beta 1?
==================================

Release date: 2013-11-24

Core and Builtins
-----------------

Library
-------

Tests
-----

Documentation
-------------

Build
-----

Tools/Demos
-----------

What's New in Python 3.4.0 Alpha 4?
===================================

Release date: 2013-10-20

Core and Builtins
-----------------

Library
-------

C API
-----

Tests
-----

Documentation
-------------

Build
-----

What's New in Python 3.4.0 Alpha 3?
===================================

Release date: 2013-09-29

Core and Builtins
-----------------

Library
-------

Tests
-----

IDLE
----

Documentation
-------------

Build
-----

Tools/Demos
-----------


What's New in Python 3.4.0 Alpha 2?
===================================

Release date: 2013-09-09

Core and Builtins
-----------------

Library
-------

Tests
-----

IDLE
----

Documentation
-------------

Build
-----

Tools/Demos
-----------

What's New in Python 3.4.0 Alpha 1?
===================================

Release date: 2013-08-03

Core and Builtins
-----------------

Library
-------

  Patch by Fraser Tweedale.

IDLE
----

Tests
-----

Build
-----

C-API
-----

Documentation
-------------

Tools/Demos
-----------

Windows
-------

**(For information about older versions, consult the HISTORY file.)**

From greg at krypto.org  Mon Jul  6 21:20:14 2015
From: greg at krypto.org (Gregory P. Smith)
Date: Mon, 06 Jul 2015 19:20:14 +0000
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
Message-ID: <CAGE7PN+Tc-MeHd4MiwFsCSwB8DDAVWQ0WTFrh+CnG839Um0LPA@mail.gmail.com>

On Mon, Jul 6, 2015 at 8:38 AM David Mertz <mertz at gnosis.cx> wrote:

> Hi Folks,
>
> I hereby volunteer to write "What's New for Python 3.5?" if folks on
> python-dev are fine with me taking the job (i.e. I ran it by Travis, my
> boss at Continuum, and he's happy to allow me to do that work within my
> salaried hours... so having time isn't a problem).
>
> If this is OK with the powers-that-be, I'll coordinate with David Murray
> on how best to take over this task from him.
>

+1


>
> Thanks, David...
>
> On Sun, Jul 5, 2015 at 8:51 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 6 July 2015 at 12:42, David Mertz <mertz at gnosis.cx> wrote:
>> > I think I might be able to "volunteer" for the task of writing/editing
>> the
>> > "What's New in 3.5" docs.  I saw David's comment on it today, so
>> obviously
>> > haven't yet had a chance to run it by my employer (Continuum
>> Analytics), but
>> > I have a hunch they would allow me to do it at least in large part as
>> paid
>> > time.  I am experienced as a technical writer, follow python-dev, write
>> > about new features, but am *not*, however, my self an existing core
>> > developer.
>>
>> I think the last point may be a positive rather than a negative when
>> it comes to effectively describing new features :)
>>
>> > If there is interest in this, or at least it seems plausible, I can run
>> it
>> > by my employer tomorrow to see about getting enough time allocated
>> (using
>> > David Murray's past experience as a guideline for what's likely to be
>> > needed).
>>
>> That would be very helpful! I'd definitely be able to find the time to
>> review and merge updates, it's the research-and-writing side that
>> poses a problem for me (appreciating a task is worth doing isn't the
>> same thing as wanting to do it myself!).
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>  _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150706/04249ee2/attachment.html>

From ethan at stoneleaf.us  Mon Jul  6 21:27:12 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 06 Jul 2015 12:27:12 -0700
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
Message-ID: <559AD690.1000802@stoneleaf.us>

On 07/06/2015 08:38 AM, David Mertz wrote:

> I hereby volunteer to write "What's New for Python 3.5?" if folks on python-dev are fine with me taking the job (i.e. I ran it by Travis, my boss at Continuum, and he's happy to allow me to do that
> work within my salaried hours... so having time isn't a problem).

Awesome, thank you to you and Continuum!

--
~Ethan~

From rdmurray at bitdance.com  Mon Jul  6 21:37:27 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 06 Jul 2015 15:37:27 -0400
Subject: [Python-Dev] What's New editing
In-Reply-To: <mneibd$g0o$1@ger.gmane.org>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <mneibd$g0o$1@ger.gmane.org>
Message-ID: <20150706193728.014FD250F9A@webabinitio.net>

On Mon, 06 Jul 2015 21:45:01 +0300, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 05.07.15 20:52, R. David Murray wrote:
> > Just so people aren't caught unawares, it is very unlikely that I will have
> > time to be the final editor on "What's New for 3.5" they way I was for 3.3 and
> > 3.4.  I've tried to encourage people to keep What's New up to date, but
> > *someone* should make a final editing pass.  Ideally they'd do at least the
> > research Serhiy did last year on checking that there's a mention for all of the
> > versionadded and versionchanged 3.5's in the docs.  Even better would be to
> > review the NEWS and/or commit history...but *that* is a really big job these
> > days....
> 
> Many thanks you David for your invaluable work.
> 
> Here is 3.5 NEWS file cleaned from duplicates in 3.4 NEWS file (i.e. 
> from entries about merged bug fixes). It is much less than unfiltered 
> NEWS file. Hope this will help volunteers.

That's great.  What I did was work from the html-rendered NEWS page, and
click through to the issue to figure out whether it was a bug fix or an
enhancement.  Not having to do that check should speed things up.  I
seem to recall I did find a couple of things that were screwed up and
still bore mentioning in whatsnew, but I doubt that is likely enough to
make enough difference to be worth it.  I also wound up fixing some
incorrect NEWS entries (wrong numbers, English, other errors), but that
is not central to the whatsnew project.  That activity was probably
included in the hours count, though.

For David (or whoever):  in addition to the obvious task of writing up
appropriate entries in What's New, part of what I did was to make sure
that all of the relevant documentation entries had the appropriate
versionchanged or versionadded tags, and that the new documentation made
sense.  As I recall, my working rhythm was to write the What's New entry
including links to the things that had changed, render the what's new
page to html, fix the links, then work through the links to make sure
the docs made sense and there were appropriate 'versionxxx' tags.  You,
of course, may find a different working style more beneficial :).

Oh, and work from newest change to oldest change.  I did it from oldest
to newest and only realized late in the game that was the wrong order,
because some changes got undone or modified by later changes :)

--David

From srkunze at mail.de  Mon Jul  6 22:08:44 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Mon, 06 Jul 2015 22:08:44 +0200
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <CADiSq7fN1et3yae=CwrWoL7DNeF3jwzdRFkhM8EQ7FkQC3etaw@mail.gmail.com>
References: <558AF376.30607@mail.de> <558B1034.6080504@gmail.com>
 <558B1F72.9000409@mail.de> <20150625021659.GS20701@ando.pearwood.info>
 <558C2489.2080305@mail.de>
 <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de> <5594638C.1060401@canterbury.ac.nz>
 <5595A52D.9040909@mail.de>
 <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>
 <5599A688.8050900@mail.de>
 <CAPTjJmoOcdm6kEN0j68p_FquRePbfV_9ViQW82y_bOM0vXSmPA@mail.gmail.com>
 <CADiSq7fN1et3yae=CwrWoL7DNeF3jwzdRFkhM8EQ7FkQC3etaw@mail.gmail.com>
Message-ID: <559AE04C.7050500@mail.de>

On 06.07.2015 03:41, Nick Coghlan wrote:
> That said, I think there's definitely value in providing a very simple
> answer to the "how do I make a blocking call from a coroutine?"
> question, so I filed an RFE to add asyncio.blocking_call:
> http://bugs.python.org/issue24571

Nice step forward, Nick. Thanks a lot.

> I'm less convinced of the value of "asyncio.wait_for_result()", so I
> haven't filed an RFE for that one.

I have done that for you, because I feel people need to have a 
convenient tool to **bridge both worlds** in either direction: 
http://bugs.python.org/issue24578


That is even another issue that came to my mind once in a while but I 
forgot to post it here:

How are mature projects are supposed to make the transition to asyncio 
when they see performance opportunities in using it?

We have several millions lines of code. I actually imagined we could 
simply drop an 'await' once in a while in order to gain from asyncio's 
power. As it seems, we need to inconveniently write all sort of wrappers 
(unnecessarily from my perspective) to retain existing functionality and 
leverage asyncio's strength at the same time in order not to break 
anything. That is, in fact, the main reason why I conduct this 
discussion. I feel this transition is mostly impossible, very costly or 
only possible for new code (where is remains to be seen whether it fits 
in the existing codebase).

I also feel I am missing something of the bigger picture and I am not 
sure if something like this is planned for the future. But from my 
perspective in order to leverage asyncio's power, you need at least two 
coroutines running at the same time, right? So, in order to get things 
running, I still need some sort of get_event_loop into which I can put 
my top-level coroutines.

Assume my venerable business functionality:

def business_old():
     content1 = open('big.file').read()   # blocks until finished
     content2 = open('huge.file').read()  # blocks until finished
     return content1 + content2

I would like to rewrite/amend it to work asynchronously with minimal 
effort such as:

def business_new():
     content1 = fork open('big.file').read()  # wraps up the calls into 
awaitables
     content2 = fork open('huge.file').read() # and put them into the 
event loop
     return content1 + content2               # variables are used => 
await evaluation

I might have missed something but I think you get my point.

Correct me if I am wrong, but inferring from the given example of PEP 
492, currently, we would need to do the following:

def business_new_2():
     content1 = open('big.file').read()  # get us two awaitables/futures
     content2 = open('huge.file').read() # ...

     # somehow the loop magic
loop = asyncio.get_event_loop()
loop.run_until_complete(content1)
loop.run_until_complete(content2)
try:
loop.run_forever() # might be something different
finally:
         loop.close()
     return content1.result() + content2.result()

I certainly do not want to put that into our codebase. Especially when 
this kind of code block could occur at any level many times in various 
functions.

Regards,
Sven


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150706/1e7987a7/attachment.html>

From clement.rouault at gmail.com  Mon Jul  6 22:45:59 2015
From: clement.rouault at gmail.com (Clement Rouault)
Date: Mon, 6 Jul 2015 22:45:59 +0200
Subject: [Python-Dev] raw_input prompt not printed on sys.stderr
Message-ID: <CAMxRgx_RyKmZPXAk1BUb8BZX0JuJv6rOa5hchJANkg5OntYWBg@mail.gmail.com>

Hi,

While playing with non-standard sys.stdout/stderr, I noticed that the
prompt of raw_input was printed on stderr (not sys.stderr) (see
Parser/myreadline.c:120).

I found an issue (http://bugs.python.org/issue1927) from 2008 talking
about changing stderr to stdout. But nobody in the thread seems
bothered by the use of stdout/err over the ones in the sys module.

So, is there any good reason I might not be aware of that justifies
the use of stderr over sys.stderr ?

-- 
Clement "Hakril" Rouault

From stephen at xemacs.org  Tue Jul  7 04:10:31 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 07 Jul 2015 11:10:31 +0900
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python
	2.7	HTTPS
In-Reply-To: <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
Message-ID: <87615wiup4.fsf@uwakimon.sk.tsukuba.ac.jp>

Cross-posted to redirect discussion.  Replies directed to Python-Ideas.

Erik Bray writes on Python-Dev:
 > On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
 > > On Mon, 6 Jul 2015 14:22:46 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
 > >>
 > >> The main change from the last version discussed on python-ideas
 > >
 > > Was it discussed there? That list has become totally useless, I've
 > > stopped following it.
 > 
 > Considering that a useful discussion of a useful PEP occurred there
 > (not to mention other occasionally useful discussions) I'd say that
 > such a value judgment is not only unnecessary but also inaccurate.

As you point out, the words "totally" and "useless" were unnecessary
and inaccurate respectively.

However, the gist of his post, that the S/N on Python-Ideas has become
substantially lower in the last few months, seems accurate to me.  At
least two recent threads could have been continued on Python-List,
where they would have benefited a lot more users, and they didn't seem
profitable on Python-Ideas since it was quite evident that Those Who
Know About Python were adamantly opposed to the idea as discussed in
the thread, while the proponent kept pushing on that brick wall rather
than seeking a way around it.

I myself continue to follow Python-Ideas, Nick and other committers
are posting here daily, and even Guido manages to pop up occasionally,
so that may be no problem (or even a good thing if it results in
educating and inviting new committers in the long run).  But I think
it's worth considering whether it we should cultivate a bit more
discipline here.

Again, discussion on Python-Ideas, please.



From raymond.hettinger at gmail.com  Tue Jul  7 06:32:44 2015
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 6 Jul 2015 21:32:44 -0700
Subject: [Python-Dev] What's New editing
In-Reply-To: <20150706015435.C4552250EAD@webabinitio.net>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <20150706015435.C4552250EAD@webabinitio.net>
Message-ID: <CABphzDni6xwbSKYEiKPu5PeOooHiKmNLVcHmvBfpYnSki_+60A@mail.gmail.com>

FWIW, it took me 100+ hours.   Doing this right is a non-trivial undertaking
(in modern times, there are an astonishing number of changes per release).
That said, it is rewarding work that makes a difference.


Raymond


[David Murray]
I can tell you that 3.4 took me approximately 67 hours according to my
time log.  That was going through the list prepared by Serhiy, and going
through pretty much all of the NEWS entries but not the commit log.  I'm
a precisionist, so I suspect someone less...ocd...about the details
could do it a bit faster, perhaps at the cost of some small amount of
accuracy :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150706/ecf2ceac/attachment.html>

From taleinat at gmail.com  Tue Jul  7 09:18:00 2015
From: taleinat at gmail.com (Tal Einat)
Date: Tue, 7 Jul 2015 10:18:00 +0300
Subject: [Python-Dev] raw_input prompt not printed on sys.stderr
In-Reply-To: <CAMxRgx_RyKmZPXAk1BUb8BZX0JuJv6rOa5hchJANkg5OntYWBg@mail.gmail.com>
References: <CAMxRgx_RyKmZPXAk1BUb8BZX0JuJv6rOa5hchJANkg5OntYWBg@mail.gmail.com>
Message-ID: <CALWZvp5P-X9JEGcZvFd+WmzzPjc1hf_hrirNQbAZ6bcrvKhyyg@mail.gmail.com>

On Mon, Jul 6, 2015 at 11:45 PM, Clement Rouault
<clement.rouault at gmail.com> wrote:
> Hi,
>
> While playing with non-standard sys.stdout/stderr, I noticed that the
> prompt of raw_input was printed on stderr (not sys.stderr) (see
> Parser/myreadline.c:120).
>
> I found an issue (http://bugs.python.org/issue1927) from 2008 talking
> about changing stderr to stdout. But nobody in the thread seems
> bothered by the use of stdout/err over the ones in the sys module.
>
> So, is there any good reason I might not be aware of that justifies
> the use of stderr over sys.stderr ?

See issue #24402: input() uses sys.__stdout__ instead of sys.stdout for prompt

That issue was deemed probably a bug, and includes a simple patch
which appears to fix the issue (without tests).

- Tal Einat

From storchaka at gmail.com  Tue Jul  7 09:19:37 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 07 Jul 2015 10:19:37 +0300
Subject: [Python-Dev] cpython: Minor bit of factoring-out common code.
In-Reply-To: <20150707020853.20885.2805@psf.io>
References: <20150707020853.20885.2805@psf.io>
Message-ID: <mnfui9$lon$1@ger.gmane.org>

On 07.07.15 05:08, raymond.hettinger wrote:
> https://hg.python.org/cpython/rev/5088f2cd6293
> changeset:   96866:5088f2cd6293
> user:        Raymond Hettinger <python at rcn.com>
> date:        Mon Jul 06 19:08:49 2015 -0700
> summary:
>    Minor bit of factoring-out common code.

> +        if (rv < 0)
> +            goto error;
>           if (rv) {
> -            if (set_add_entry(result, key, hash)) {
> -                Py_DECREF(it);
> -                Py_DECREF(result);
> -                Py_DECREF(key);
> -                return NULL;
> -            }
> +            if (set_add_entry(result, key, hash))
> +                goto error;
>           }
>           Py_DECREF(key);
>       }

In tight loop it may be worth to rewrite the code

     if (rv < 0)
         goto error;
     if (rv) {
         expensive_operation();
     }
     // if (rv == 0) do nothing

in the form:

     if (rv) {
         if (rv < 0)
             goto error;
         expensive_operation();
     }

This looks less clear, but needs only one test in the case of rv == 0.



From storchaka at gmail.com  Tue Jul  7 09:42:43 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 07 Jul 2015 10:42:43 +0300
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <20150707020307.11325.89553@psf.io>
References: <20150707020307.11325.89553@psf.io>
Message-ID: <mnfvtk$anv$1@ger.gmane.org>

On 07.07.15 05:03, raymond.hettinger wrote:
> https://hg.python.org/cpython/rev/c9782a9ac031
> changeset:   96865:c9782a9ac031
> user:        Raymond Hettinger <python at rcn.com>
> date:        Mon Jul 06 19:03:01 2015 -0700
> summary:
>    Tighten-up code in the set iterator to use an entry pointer rather than indexing.
>
> files:
>    Objects/setobject.c |  35 ++++++++++++--------------------
>    1 files changed, 13 insertions(+), 22 deletions(-)
>
>
> diff --git a/Objects/setobject.c b/Objects/setobject.c
> --- a/Objects/setobject.c
> +++ b/Objects/setobject.c
> @@ -766,8 +766,8 @@
>       PyObject_HEAD
>       PySetObject *si_set; /* Set to NULL when iterator is exhausted */
>       Py_ssize_t si_used;
> -    Py_ssize_t si_pos;
>       Py_ssize_t len;
> +    setentry *entry;
>   } setiterobject;
>
>   static void
> @@ -845,8 +845,6 @@
>
>   static PyObject *setiter_iternext(setiterobject *si)
>   {
> -    PyObject *key;
> -    Py_ssize_t i, mask;
>       setentry *entry;
>       PySetObject *so = si->si_set;
>
> @@ -860,25 +858,18 @@
>           si->si_used = -1; /* Make this state sticky */
>           return NULL;
>       }
> -
> -    i = si->si_pos;
> -    assert(i>=0);
> -    entry = so->table;
> -    mask = so->mask;
> -    while (i <= mask && (entry[i].key == NULL || entry[i].key == dummy))
> -        i++;
> -    si->si_pos = i+1;
> -    if (i > mask)
> -        goto fail;
> +    if (si->len <= 0) {
> +        Py_DECREF(so);
> +        si->si_set = NULL;
> +        return NULL;
> +    }
> +    entry = si->entry;
> +    while (entry->key == NULL || entry->key == dummy)
> +        entry++;
>       si->len--;
> -    key = entry[i].key;
> -    Py_INCREF(key);
> -    return key;
> -
> -fail:
> -    Py_DECREF(so);
> -    si->si_set = NULL;
> -    return NULL;
> +    si->entry = entry + 1;
> +    Py_INCREF(entry->key);
> +    return entry->key;
>   }
>
>   PyTypeObject PySetIter_Type = {
> @@ -923,8 +914,8 @@
>       Py_INCREF(so);
>       si->si_set = so;
>       si->si_used = so->used;
> -    si->si_pos = 0;
>       si->len = so->used;
> +    si->entry = so->table;
>       _PyObject_GC_TRACK(si);
>       return (PyObject *)si;
>   }

What if so->table was reallocated during the iteration, but so->used is 
left the same? This change looks unsafe to me.



From storchaka at gmail.com  Tue Jul  7 10:10:09 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 07 Jul 2015 11:10:09 +0300
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <mnfvtk$anv$1@ger.gmane.org>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
Message-ID: <mng1h1$3fq$1@ger.gmane.org>

On 07.07.15 10:42, Serhiy Storchaka wrote:
> On 07.07.15 05:03, raymond.hettinger wrote:
>> https://hg.python.org/cpython/rev/c9782a9ac031
>> changeset:   96865:c9782a9ac031
>> user:        Raymond Hettinger <python at rcn.com>
>> date:        Mon Jul 06 19:03:01 2015 -0700
>> summary:
>>    Tighten-up code in the set iterator to use an entry pointer rather
>> than indexing.

> What if so->table was reallocated during the iteration, but so->used is
> left the same? This change looks unsafe to me.

There is crash reproducer.

http://bugs.python.org/issue24581


From victor.stinner at gmail.com  Tue Jul  7 10:15:50 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 7 Jul 2015 10:15:50 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <mnfvtk$anv$1@ger.gmane.org>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
Message-ID: <CAMpsgwaXTzhiT4uDaYUZ45zmBqQgoB5fw=F4tHHVStfkdsJSZA@mail.gmail.com>

Maybe such issue can be detected if Raymond uses the bug tracker for
code review? I remember many cases where Serhiy and Raymond
collaborated successfully and wrote better code thanks to the code
review.

Victor

2015-07-07 9:42 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
> On 07.07.15 05:03, raymond.hettinger wrote:
>>
>> https://hg.python.org/cpython/rev/c9782a9ac031
>> changeset:   96865:c9782a9ac031
>> user:        Raymond Hettinger <python at rcn.com>
>> date:        Mon Jul 06 19:03:01 2015 -0700
>> summary:
>>    Tighten-up code in the set iterator to use an entry pointer rather than
>> indexing.
>>
>> files:
>>    Objects/setobject.c |  35 ++++++++++++--------------------
>>    1 files changed, 13 insertions(+), 22 deletions(-)
>>
>>
>> diff --git a/Objects/setobject.c b/Objects/setobject.c
>> --- a/Objects/setobject.c
>> +++ b/Objects/setobject.c
>> @@ -766,8 +766,8 @@
>>       PyObject_HEAD
>>       PySetObject *si_set; /* Set to NULL when iterator is exhausted */
>>       Py_ssize_t si_used;
>> -    Py_ssize_t si_pos;
>>       Py_ssize_t len;
>> +    setentry *entry;
>>   } setiterobject;
>>
>>   static void
>> @@ -845,8 +845,6 @@
>>
>>   static PyObject *setiter_iternext(setiterobject *si)
>>   {
>> -    PyObject *key;
>> -    Py_ssize_t i, mask;
>>       setentry *entry;
>>       PySetObject *so = si->si_set;
>>
>> @@ -860,25 +858,18 @@
>>           si->si_used = -1; /* Make this state sticky */
>>           return NULL;
>>       }
>> -
>> -    i = si->si_pos;
>> -    assert(i>=0);
>> -    entry = so->table;
>> -    mask = so->mask;
>> -    while (i <= mask && (entry[i].key == NULL || entry[i].key == dummy))
>> -        i++;
>> -    si->si_pos = i+1;
>> -    if (i > mask)
>> -        goto fail;
>> +    if (si->len <= 0) {
>> +        Py_DECREF(so);
>> +        si->si_set = NULL;
>> +        return NULL;
>> +    }
>> +    entry = si->entry;
>> +    while (entry->key == NULL || entry->key == dummy)
>> +        entry++;
>>       si->len--;
>> -    key = entry[i].key;
>> -    Py_INCREF(key);
>> -    return key;
>> -
>> -fail:
>> -    Py_DECREF(so);
>> -    si->si_set = NULL;
>> -    return NULL;
>> +    si->entry = entry + 1;
>> +    Py_INCREF(entry->key);
>> +    return entry->key;
>>   }
>>
>>   PyTypeObject PySetIter_Type = {
>> @@ -923,8 +914,8 @@
>>       Py_INCREF(so);
>>       si->si_set = so;
>>       si->si_used = so->used;
>> -    si->si_pos = 0;
>>       si->len = so->used;
>> +    si->entry = so->table;
>>       _PyObject_GC_TRACK(si);
>>       return (PyObject *)si;
>>   }
>
>
> What if so->table was reallocated during the iteration, but so->used is left
> the same? This change looks unsafe to me.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com

From breamoreboy at yahoo.co.uk  Tue Jul  7 11:24:46 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 07 Jul 2015 10:24:46 +0100
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <87615wiup4.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
 <87615wiup4.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <mng5t2$a87$1@ger.gmane.org>

On 07/07/2015 03:10, Stephen J. Turnbull wrote:
> Cross-posted to redirect discussion.  Replies directed to Python-Ideas.
>
> Erik Bray writes on Python-Dev:
>   > On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>   > > On Mon, 6 Jul 2015 14:22:46 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
>   > >>
>   > >> The main change from the last version discussed on python-ideas
>   > >
>   > > Was it discussed there? That list has become totally useless, I've
>   > > stopped following it.
>   >
>   > Considering that a useful discussion of a useful PEP occurred there
>   > (not to mention other occasionally useful discussions) I'd say that
>   > such a value judgment is not only unnecessary but also inaccurate.
>
> As you point out, the words "totally" and "useless" were unnecessary
> and inaccurate respectively.
>
> However, the gist of his post, that the S/N on Python-Ideas has become
> substantially lower in the last few months, seems accurate to me.  At
> least two recent threads could have been continued on Python-List,
> where they would have benefited a lot more users, and they didn't seem
> profitable on Python-Ideas since it was quite evident that Those Who
> Know About Python were adamantly opposed to the idea as discussed in
> the thread, while the proponent kept pushing on that brick wall rather
> than seeking a way around it.
>
> I myself continue to follow Python-Ideas, Nick and other committers
> are posting here daily, and even Guido manages to pop up occasionally,
> so that may be no problem (or even a good thing if it results in
> educating and inviting new committers in the long run).  But I think
> it's worth considering whether it we should cultivate a bit more
> discipline here.
>
> Again, discussion on Python-Ideas, please.
>

 From https://mail.python.org/mailman/listinfo/python-ideas

<quote>
This list is to contain discussion of speculative language ideas for 
Python for possible inclusion into the language. If an idea gains 
traction it can then be discussed and honed to the point of becoming a 
solid proposal to put to python-dev as appropriate.
</quote>

Relative to the above I believe that far too many proposals are for 
trivial ideas, mainly targetted at the stdlib, that would be better 
suited to the main python list.

As for gaining traction, it's often the complete opposite, flogging a 
dead horse is an understatement for some threads.  Gently putting the OP 
down with a firm but polite "it ain't gonna happen" would save a lot of 
time all around.

Just my ?0.02p worth.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From fijall at gmail.com  Tue Jul  7 12:04:34 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 7 Jul 2015 12:04:34 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <mng1h1$3fq$1@ger.gmane.org>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
Message-ID: <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>

I must say I completely fail to understand the procedures under which
python is developed. If the change (unreviewed, just randomly applied)
causes crashes, then surely it should be reverted first and continued
on bug tracker instead of lingering (and the complain sitting on bug
tracker)?

On Tue, Jul 7, 2015 at 10:10 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 07.07.15 10:42, Serhiy Storchaka wrote:
>>
>> On 07.07.15 05:03, raymond.hettinger wrote:
>>>
>>> https://hg.python.org/cpython/rev/c9782a9ac031
>>> changeset:   96865:c9782a9ac031
>>> user:        Raymond Hettinger <python at rcn.com>
>>> date:        Mon Jul 06 19:03:01 2015 -0700
>>> summary:
>>>    Tighten-up code in the set iterator to use an entry pointer rather
>>> than indexing.
>
>
>> What if so->table was reallocated during the iteration, but so->used is
>> left the same? This change looks unsafe to me.
>
>
> There is crash reproducer.
>
> http://bugs.python.org/issue24581
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com

From solipsis at pitrou.net  Tue Jul  7 13:24:12 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 7 Jul 2015 13:24:12 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
Message-ID: <20150707132412.3acadb42@fsol>

On Tue, 7 Jul 2015 12:04:34 +0200
Maciej Fijalkowski <fijall at gmail.com> wrote:
> I must say I completely fail to understand the procedures under which
> python is developed. If the change (unreviewed, just randomly applied)
> causes crashes, then surely it should be reverted first and continued
> on bug tracker instead of lingering (and the complain sitting on bug
> tracker)?

+1, especially as the commit doesn't seem to come with any concrete
explanation of what is being fixed or improved.

("tighten-up code" is really a platonic motivation... not necessarily
bad, but should be trumped such as operational concerns, e.g.
crashes :-))

Regards

Antoine.



From guido at python.org  Tue Jul  7 14:14:49 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 7 Jul 2015 14:14:49 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <20150707132412.3acadb42@fsol>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
Message-ID: <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>

FYI, do we have any indication that Raymond even read the comment? IIRC he
doesn't regularly read python-dev. I also don't think code review comments
ought to go to python-dev; the commiters list would seem more appropriate?
(Though it looks like python-checkins is configured to direct replies to
python-dev. Maybe we need to revisit that?)

On Tue, Jul 7, 2015 at 1:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Tue, 7 Jul 2015 12:04:34 +0200
> Maciej Fijalkowski <fijall at gmail.com> wrote:
> > I must say I completely fail to understand the procedures under which
> > python is developed. If the change (unreviewed, just randomly applied)
> > causes crashes, then surely it should be reverted first and continued
> > on bug tracker instead of lingering (and the complain sitting on bug
> > tracker)?
>
> +1, especially as the commit doesn't seem to come with any concrete
> explanation of what is being fixed or improved.
>
> ("tighten-up code" is really a platonic motivation... not necessarily
> bad, but should be trumped such as operational concerns, e.g.
> crashes :-))
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/6b784ac3/attachment.html>

From guido at python.org  Tue Jul  7 14:18:12 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 7 Jul 2015 14:18:12 +0200
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <mng5t2$a87$1@ger.gmane.org>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
 <87615wiup4.fsf@uwakimon.sk.tsukuba.ac.jp> <mng5t2$a87$1@ger.gmane.org>
Message-ID: <CAP7+vJLpfV002TeOCqp-qSh8dGFXGpQRdyaaHDwUYh8Bf6VyNg@mail.gmail.com>

On Tue, Jul 7, 2015 at 11:24 AM, Mark Lawrence <breamoreboy at yahoo.co.uk>
wrote:

> From https://mail.python.org/mailman/listinfo/python-ideas
>
> <quote>
> This list is to contain discussion of speculative language ideas for
> Python for possible inclusion into the language. If an idea gains traction
> it can then be discussed and honed to the point of becoming a solid
> proposal to put to python-dev as appropriate.
> </quote>
>
> Relative to the above I believe that far too many proposals are for
> trivial ideas, mainly targetted at the stdlib, that would be better suited
> to the main python list.
>
> As for gaining traction, it's often the complete opposite, flogging a dead
> horse is an understatement for some threads.  Gently putting the OP down
> with a firm but polite "it ain't gonna happen" would save a lot of time all
> around.
>
> Just my ?0.02p worth.
>

Agreed. It's also probably easier to just ignore an obviously bad or poorly
thought-out idea than to try to engage the OP in lengthy explanations of
why that is so. After all there's a huge amount of subjectivity -- we won't
change our minds, but it takes forever to explain to someone who's new to
Python core development.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/244bf83c/attachment.html>

From solipsis at pitrou.net  Tue Jul  7 14:25:24 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 7 Jul 2015 14:25:24 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
Message-ID: <20150707142524.7966c63d@fsol>

On Tue, 7 Jul 2015 14:14:49 +0200
Guido van Rossum <guido at python.org> wrote:
> FYI, do we have any indication that Raymond even read the comment? IIRC he
> doesn't regularly read python-dev. I also don't think code review comments
> ought to go to python-dev; the commiters list would seem more appropriate?

Well, do we have to keep a record of what ML each developer reads? Or
is post-commit review to be faced each times with dilemmas such as the
present: """does this core developer really read that mailing-list? should I
email him/her privately, or is that too intrusive? what about writing
to that other mailing-list? if they don't answer, did they at least see
the message amongst the other threads?"""

(this is a nice thing with pre-commit review: you can usually be sure
the developer will read your comments, unless there's something
seriously wrong with the setup)

> (Though it looks like python-checkins is configured to direct replies to
> python-dev. Maybe we need to revisit that?)

My own preference would be to keep it that way. If python-dev becomes
annoying to read, then probably python-checkins isn't very exciting
either ;-)
(just MHO, of course)

Regards

Antoine.

From guido at python.org  Tue Jul  7 14:31:26 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 7 Jul 2015 14:31:26 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <20150707142524.7966c63d@fsol>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <20150707142524.7966c63d@fsol>
Message-ID: <CAP7+vJ+g5O2dG7Gep1OFEYaqVw5UyFrjppXO+oLwcrVziRatfA@mail.gmail.com>

A simple way to address this would have been to CC Raymond on the issue.
But the reply-to header probably makes that hard. Agreed that post-commit
reviews don't really scale to our size. It's hard to teach old dogs new
tricks though. I now realize that my main point, however, was that Raymond
and Serhiy might have sorted this out offline already without either of
them bothering to CC python-dev on the fix, so perhaps the discussion about
our broken process might well have been premature. Certainly I don't think
automatically rolling back commits is something we should start to do
without a bigger overhaul of our process -- which takes time and may well
already be underway.

On Tue, Jul 7, 2015 at 2:25 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Tue, 7 Jul 2015 14:14:49 +0200
> Guido van Rossum <guido at python.org> wrote:
> > FYI, do we have any indication that Raymond even read the comment? IIRC
> he
> > doesn't regularly read python-dev. I also don't think code review
> comments
> > ought to go to python-dev; the commiters list would seem more
> appropriate?
>
> Well, do we have to keep a record of what ML each developer reads? Or
> is post-commit review to be faced each times with dilemmas such as the
> present: """does this core developer really read that mailing-list? should
> I
> email him/her privately, or is that too intrusive? what about writing
> to that other mailing-list? if they don't answer, did they at least see
> the message amongst the other threads?"""
>
> (this is a nice thing with pre-commit review: you can usually be sure
> the developer will read your comments, unless there's something
> seriously wrong with the setup)
>
> > (Though it looks like python-checkins is configured to direct replies to
> > python-dev. Maybe we need to revisit that?)
>
> My own preference would be to keep it that way. If python-dev becomes
> annoying to read, then probably python-checkins isn't very exciting
> either ;-)
> (just MHO, of course)
>
> Regards
>
> Antoine.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/a67a69f4/attachment.html>

From fijall at gmail.com  Tue Jul  7 14:32:06 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 7 Jul 2015 14:32:06 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
Message-ID: <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>

On Tue, Jul 7, 2015 at 2:14 PM, Guido van Rossum <guido at python.org> wrote:
> FYI, do we have any indication that Raymond even read the comment? IIRC he
> doesn't regularly read python-dev. I also don't think code review comments
> ought to go to python-dev; the commiters list would seem more appropriate?
> (Though it looks like python-checkins is configured to direct replies to
> python-dev. Maybe we need to revisit that?)

I kind of thought that python does pre-commit reviews (at least seems
to apply to most people), so in case someone is completely exempt from
that, maybe he should read python-dev or wherever the reply is set to?
That also does not explain why a crashing commit has not been
reverted.

From ncoghlan at gmail.com  Tue Jul  7 14:40:37 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 7 Jul 2015 22:40:37 +1000
Subject: [Python-Dev] Importance of "async" keyword
In-Reply-To: <559AE04C.7050500@mail.de>
References: <558AF376.30607@mail.de> <558B1034.6080504@gmail.com>
 <558B1F72.9000409@mail.de>
 <20150625021659.GS20701@ando.pearwood.info>
 <558C2489.2080305@mail.de>
 <CAL3CFcUywCtz04nkPamznR1vTeAHYiJFn4_j-9sFnAad6ZkBjg@mail.gmail.com>
 <558D5834.2030909@mail.de>
 <BLUPR0301MB1652BA6E0F63A32184C338B5F5AD0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <558D8E95.6020404@stoneleaf.us> <558D9A41.3050309@gmail.com>
 <5592F074.7010904@mail.de> <5594638C.1060401@canterbury.ac.nz>
 <5595A52D.9040909@mail.de>
 <CADiSq7eU_R4cHC8HHcRNt+Nvfbi_cTTHjS2fjrXUR3J4_TTz0g@mail.gmail.com>
 <5599A688.8050900@mail.de>
 <CAPTjJmoOcdm6kEN0j68p_FquRePbfV_9ViQW82y_bOM0vXSmPA@mail.gmail.com>
 <CADiSq7fN1et3yae=CwrWoL7DNeF3jwzdRFkhM8EQ7FkQC3etaw@mail.gmail.com>
 <559AE04C.7050500@mail.de>
Message-ID: <CADiSq7dhZ+QAUzgFFu+u-9sGFP+0Oz5XBPd14b_qPEUX2r8xFg@mail.gmail.com>

On 7 July 2015 at 06:08, Sven R. Kunze <srkunze at mail.de> wrote:
> I would like to rewrite/amend it to work asynchronously with minimal effort
> such as:
>
> def business_new():
>     content1 = fork open('big.file').read()  # wraps up the calls into
> awaitables
>     content2 = fork open('huge.file').read() # and put them into the event
> loop
>     return content1 + content2               # variables are used => await
> evaluation
>
> I might have missed something but I think you get my point.

No, you haven't missed anything, but I think the convenience APIs
we're discussing in this thread are what you need, rather than
async/await.

Specifically, your main application would remain synchronous, but the
event loop could be used to run selected operations in a background
thread:

    def business_new():
        future1 = asyncio.call_async(open('big.file').read)
        future2 = asyncio.call_async(open('huge.file').read)
        content1 = asyncio.wait_for_result(future1)
        content2 = asyncio.wait_for_result(future2)
        return content1 + content2

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From guido at python.org  Tue Jul  7 14:41:37 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 7 Jul 2015 14:41:37 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
Message-ID: <CAP7+vJLZtdn2RSK43EGUynsMh+2yKwBXZcn=V-hD0YctzqohBg@mail.gmail.com>

It's more complicated than that.

FWIW a crash reproducer doesn't mean it's a common or likely crash.
Apparently no unittests broke. Also, please give Raymond time to wake up
(I'm in Europe, but Raymond is probably recovering from a three-day weekend
in the US).

On Tue, Jul 7, 2015 at 2:32 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:

> On Tue, Jul 7, 2015 at 2:14 PM, Guido van Rossum <guido at python.org> wrote:
> > FYI, do we have any indication that Raymond even read the comment? IIRC
> he
> > doesn't regularly read python-dev. I also don't think code review
> comments
> > ought to go to python-dev; the commiters list would seem more
> appropriate?
> > (Though it looks like python-checkins is configured to direct replies to
> > python-dev. Maybe we need to revisit that?)
>
> I kind of thought that python does pre-commit reviews (at least seems
> to apply to most people), so in case someone is completely exempt from
> that, maybe he should read python-dev or wherever the reply is set to?
> That also does not explain why a crashing commit has not been
> reverted.
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/235f4344/attachment-0001.html>

From ncoghlan at gmail.com  Tue Jul  7 14:43:39 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 7 Jul 2015 22:43:39 +1000
Subject: [Python-Dev] What's New editing
In-Reply-To: <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <CAEbHw4YhQpnyOKnJ=T5ZMAsmG28oR+6upDqVHUqCPgKH=gvO0g@mail.gmail.com>
 <CADiSq7c0U8LZV1J7BYS6miD3SozCGBVL-9uP_G+SGRu1qimeMA@mail.gmail.com>
 <CAEbHw4ZKyYT8DJYz7hTBjuw_3ERPY0JefJJQPrgh6Jcsfm0Rhw@mail.gmail.com>
Message-ID: <CADiSq7ciXY00_tesP7+hfm0oTJ_9=hEsFbpFobueGdZp8hNwng@mail.gmail.com>

On 7 July 2015 at 01:38, David Mertz <mertz at gnosis.cx> wrote:
> Hi Folks,
>
> I hereby volunteer to write "What's New for Python 3.5?" if folks on
> python-dev are fine with me taking the job (i.e. I ran it by Travis, my boss
> at Continuum, and he's happy to allow me to do that work within my salaried
> hours... so having time isn't a problem).

Huzzah - thanks for offering, and thanks Travis/Continuum for granting
you the paid time :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Tue Jul  7 15:07:17 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 7 Jul 2015 23:07:17 +1000
Subject: [Python-Dev] Review/CI infrastructure status (was Re: cpython:
 Tighten-up code in the set iterator to use an entry pointer rather than)
Message-ID: <CADiSq7eXqSyQpwC8nau1fLggvYFCHW3UPYNG5gLd5RnH1avV1Q@mail.gmail.com>

On 7 July 2015 at 22:31, Guido van Rossum <guido at python.org> wrote:
> A simple way to address this would have been to CC Raymond on the issue. But
> the reply-to header probably makes that hard. Agreed that post-commit
> reviews don't really scale to our size. It's hard to teach old dogs new
> tricks though. I now realize that my main point, however, was that Raymond
> and Serhiy might have sorted this out offline already without either of them
> bothering to CC python-dev on the fix, so perhaps the discussion about our
> broken process might well have been premature. Certainly I don't think
> automatically rolling back commits is something we should start to do
> without a bigger overhaul of our process -- which takes time and may well
> already be underway.

Only sort of - the three principals (myself, Donald Stufft, Brett
Cannon) have all had quite a few other things on our plates in the
last few months, so the forge.python.org proposals haven't progressed
beyond where they were at the Language Summit in April :(

It did occur to me that we could potentially get the moral equivalent
of a "gated trunk" *without* disrupting current commit workflows by
introducing a separate "cpython-ci" repo that was only updated after
the BuildBots gave a commit a clean bill of health. That would also
provide a better basis for other folks to do CI against, since they'd
know the commit was at least passing our own test suite before they
tried it.

It would mean yet another piece of workflow infrastructure to set up
and maintain, though :(

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From storchaka at gmail.com  Tue Jul  7 15:08:29 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 07 Jul 2015 16:08:29 +0300
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
Message-ID: <mngj0d$u9p$1@ger.gmane.org>

On 07.07.15 15:32, Maciej Fijalkowski wrote:
> I kind of thought that python does pre-commit reviews (at least seems
> to apply to most people), so in case someone is completely exempt from
> that, maybe he should read python-dev or wherever the reply is set to?
> That also does not explain why a crashing commit has not been
> reverted.

There is no haste. Only developed branch is affected and we have enough 
time to fix it. No buildbots is broken. Just rolling back this changeset 
can be impossible because Raymond committed other changes after it. I'm 
not sure that this changeset is culprit, it can be previous one. Raymond 
is the most experienced person in this file, and writing good fix that 
conform to Raymond's view by other person can take more time than the 
time that is needed to Raymond to awake and read this topic.


From storchaka at gmail.com  Tue Jul  7 15:29:34 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 07 Jul 2015 16:29:34 +0300
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
Message-ID: <mngk8j$jnm$1@ger.gmane.org>

On 07.07.15 15:14, Guido van Rossum wrote:
> FYI, do we have any indication that Raymond even read the comment? IIRC
> he doesn't regularly read python-dev. I also don't think code review
> comments ought to go to python-dev; the commiters list would seem more
> appropriate? (Though it looks like python-checkins is configured to
> direct replies to python-dev. Maybe we need to revisit that?)

I would have commented on the tracker, if any issue number was 
corresponded to this commit. I was not sure there is real crash until 
trying to write a reproducer, the code just looked suspicious to me.

Another suspicious commit was changeset 637e197be547 [1]. Looks as 
Raymond missed my comment on Python-Dev [2]. I still have no reproducer 
for this particular possible crash, found example crashes also with 3.5 
[3], this can be a consequence of other change.

[1] https://hg.python.org/cpython/rev/637e197be547
[2] http://comments.gmane.org/gmane.comp.python.cvs/110808
[3] https://bugs.python.org/issue24583



From barry at python.org  Tue Jul  7 15:30:32 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 7 Jul 2015 09:30:32 -0400
Subject: [Python-Dev] What's New editing
In-Reply-To: <CABphzDni6xwbSKYEiKPu5PeOooHiKmNLVcHmvBfpYnSki_+60A@mail.gmail.com>
References: <20150705175255.99CB6250EB5@webabinitio.net>
 <CADiSq7cQyjcqoi+eVeJq-uqqU5=-uharLhwD_1zyd6N05HAJsA@mail.gmail.com>
 <20150706015435.C4552250EAD@webabinitio.net>
 <CABphzDni6xwbSKYEiKPu5PeOooHiKmNLVcHmvBfpYnSki_+60A@mail.gmail.com>
Message-ID: <20150707093032.75274cfb@limelight.wooz.org>

On Jul 06, 2015, at 09:32 PM, Raymond Hettinger wrote:

>FWIW, it took me 100+ hours.   Doing this right is a non-trivial undertaking
>(in modern times, there are an astonishing number of changes per release).
>That said, it is rewarding work that makes a difference.

Indeed.  During distro Python version transitions (including the 3.5 one I'm
currently working on), verifying intentional changes via NEWS entries has been
really critical.

I'll point again to https://wiki.python.org/moin/PortingToPy3k/34to35 which
I'm using to document the changes that I've seen break actual packages.

Thanks for volunteering to do this work David, and for doing it in the past
other-David!

Cheers,
-Barry

From stefan at bytereef.org  Tue Jul  7 13:49:14 2015
From: stefan at bytereef.org (s.krah)
Date: Tue, 07 Jul 2015 11:49:14 +0000
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python
	2.7	HTTPS
In-Reply-To: <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
Message-ID: <14e684e58e2.115ad9114246975.8855519462170688269@bytereef.org>



Erik Bray &lt;erik.m.bray at gmail.com&gt; wrote:

&gt; On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou &lt;solipsis at pitrou.net&gt; wrote: 
&gt;&gt; On Mon, 6 Jul 2015 14:22:46 +1000 
&gt;&gt; Nick Coghlan &lt;ncoghlan at gmail.com&gt; wrote: 
&gt;&gt;&gt; 
&gt;&gt;&gt; The main change from the last version discussed on python-ideas 
&gt;&gt; 
&gt;&gt; Was it discussed there? That list has become totally useless, I've 
&gt;&gt; stopped following it. 
 
&gt; Considering that a useful discussion of a useful PEP occurred there 
&gt; (not to mention other occasionally useful discussions) I'd say that 
&gt; such a value judgment is not only unnecessary but also inaccurate. 
&gt; That's fine if it's uninteresting to you and you don't want to follow 
&gt; it, but let's please avoid judgments on entire mailing lists and, by 
&gt; extension, the people holding conversations there. 

In an informal setting, exaggeration is used widely in continental Europe.
I found the remark funny and was glad to hear that I'm not the only one
who has problems with python-ideas.


Stefan Krah


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/67ef8b19/attachment.html>

From ncoghlan at gmail.com  Tue Jul  7 16:10:09 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 8 Jul 2015 00:10:09 +1000
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <14e684e58e2.115ad9114246975.8855519462170688269@bytereef.org>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
 <14e684e58e2.115ad9114246975.8855519462170688269@bytereef.org>
Message-ID: <CADiSq7cgAhSTQwWMX5f1cobr00x0pJJVA8omyaP6xX4KFqatMg@mail.gmail.com>

On 7 July 2015 at 21:49, s.krah <stefan at bytereef.org> wrote:
>
>
> Erik Bray <erik.m.bray at gmail.com> wrote:
>
>> On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou <solipsis at pitrou.net>
>> wrote:
>>> On Mon, 6 Jul 2015 14:22:46 +1000
>>> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>>
>>>> The main change from the last version discussed on python-ideas
>>>
>>> Was it discussed there? That list has become totally useless, I've
>>> stopped following it.
>
>> Considering that a useful discussion of a useful PEP occurred there
>> (not to mention other occasionally useful discussions) I'd say that
>> such a value judgment is not only unnecessary but also inaccurate.
>> That's fine if it's uninteresting to you and you don't want to follow
>> it, but let's please avoid judgments on entire mailing lists and, by
>> extension, the people holding conversations there.
>
> In an informal setting, exaggeration is used widely in continental Europe.
> I found the remark funny and was glad to hear that I'm not the only one
> who has problems with python-ideas.

Folks are free to make all the jokes they want about python-ideas over
drinks at a conference, or when bouncing their heads off their desks
at how far off the rails a particular thread has gone - we wouldn't be
human if we didn't need to vent our frustrations sometimes.

That doesn't make it OK to vent those frustrations *here*. Here,
python-ideas needs to be accepted as a useful component of the
development process - it's the location where more freewheeling "this
*might* be a good idea" design discussions can happen with input from
experienced core developers and other community members without
bothering the folks that aren't interested in those kinds of
conversations, before python-dev and the issue tracker come into play
to provide more ruthless weeding out of the bad ideas. An awful lot of
what we discuss on python-ideas will turn out to be a bad idea, just
be sheer weight of probability. However, even weeding out the bad
ideas is a useful exercise in refining our collective understanding of
what "good" looks like (I know I've learned a *lot* from the many
occasions where Guido or someone else has persuaded me that one of my
ideas wasn't as good as I originally thought it was).

It's OK if folks aren't interested in participating in the noisy early
stages of that process - that's why the activity was long since moved
out to a dedicated list. It's not OK to make the jump from "I don't
consider participating in that to be the best possible use of my own
time" to "it isn't worth doing".

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From fijall at gmail.com  Tue Jul  7 16:33:32 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 7 Jul 2015 16:33:32 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <mngj0d$u9p$1@ger.gmane.org>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
 <mngj0d$u9p$1@ger.gmane.org>
Message-ID: <CAK5idxSw6FgNGsVSGjMxQ1P4KMF77+VqM1xSCQWQK+R-NYj1TA@mail.gmail.com>

On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 07.07.15 15:32, Maciej Fijalkowski wrote:
>>
>> I kind of thought that python does pre-commit reviews (at least seems
>> to apply to most people), so in case someone is completely exempt from
>> that, maybe he should read python-dev or wherever the reply is set to?
>> That also does not explain why a crashing commit has not been
>> reverted.
>
>
> There is no haste. Only developed branch is affected and we have enough time
> to fix it. No buildbots is broken. Just rolling back this changeset can be
> impossible because Raymond committed other changes after it. I'm not sure
> that this changeset is culprit, it can be previous one. Raymond is the most
> experienced person in this file, and writing good fix that conform to
> Raymond's view by other person can take more time than the time that is
> needed to Raymond to awake and read this topic.

Then maybe a good option would be to add the crasher to the test
suite, so the buildbots *are* actually broken showing the problem
exists?

From solipsis at pitrou.net  Tue Jul  7 16:42:31 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 7 Jul 2015 16:42:31 +0200
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
 <14e684e58e2.115ad9114246975.8855519462170688269@bytereef.org>
 <CADiSq7cgAhSTQwWMX5f1cobr00x0pJJVA8omyaP6xX4KFqatMg@mail.gmail.com>
Message-ID: <20150707164231.2bfdb9f4@fsol>

On Wed, 8 Jul 2015 00:10:09 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> It's OK if folks aren't interested in participating in the noisy early
> stages of that process - that's why the activity was long since moved
> out to a dedicated list. It's not OK to make the jump from "I don't
> consider participating in that to be the best possible use of my own
> time" to "it isn't worth doing".

Ok. As Stefan points out, exageration is a common rhetoric device - for
the better or (mostly perhaps :-)) for the worse. Sorry if that
*actually* offended some people.

In this case, though, I was a bit miffed since I didn't notice that
PEP appearing on python-ideas (or perhaps I already forget discussing
it?), which made me frustrated that *perhaps* with less pointless
drifting I would have seen it. Being one of the principal maintainers
of the ssl module I was definitely interested on giving my opinion.

Whether the time required to properly follow python-ideas is a
productive involvement for the average core dev is another question.
The problem I see with python-ideas is that it may select on free time
more than on actual, concrete contribution...

(note that python-list has a similar problem with some of its old-timers
and regular ranters; the difference is that python-list has a ready
alternative in StackOverflow, with perhaps higher-quality answers...
it's less and less relevant in the grand scheme of things)

Regards

Antoine.



From storchaka at gmail.com  Tue Jul  7 17:15:42 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 07 Jul 2015 18:15:42 +0300
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAK5idxSw6FgNGsVSGjMxQ1P4KMF77+VqM1xSCQWQK+R-NYj1TA@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
 <mngj0d$u9p$1@ger.gmane.org>
 <CAK5idxSw6FgNGsVSGjMxQ1P4KMF77+VqM1xSCQWQK+R-NYj1TA@mail.gmail.com>
Message-ID: <mngqeu$v4j$1@ger.gmane.org>

On 07.07.15 17:33, Maciej Fijalkowski wrote:
> On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> There is no haste. Only developed branch is affected and we have enough time
>> to fix it. No buildbots is broken.
>
> Then maybe a good option would be to add the crasher to the test
> suite, so the buildbots *are* actually broken showing the problem
> exists?

This will make harder to notice (and fix!) other regressions.



From stefan at bytereef.org  Tue Jul  7 18:03:36 2015
From: stefan at bytereef.org (s.krah)
Date: Tue, 07 Jul 2015 16:03:36 +0000
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
 HTTPS
In-Reply-To: <CADiSq7cgAhSTQwWMX5f1cobr00x0pJJVA8omyaP6xX4KFqatMg@mail.gmail.com>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
 <14e684e58e2.115ad9114246975.8855519462170688269@bytereef.org>
 <CADiSq7cgAhSTQwWMX5f1cobr00x0pJJVA8omyaP6xX4KFqatMg@mail.gmail.com>
Message-ID: <14e69249ad4.10d849bc020874.104137784187227994@bytereef.org>



Nick Coghlan &lt;ncoghlan at gmail.com&gt; wrote:

&gt; It's OK if folks aren't interested in participating in the noisy early 
&gt; stages of that process - that's why the activity was long since moved 
&gt; out to a dedicated list. It's not OK to make the jump from "I don't 
&gt; consider participating in that to be the best possible use of my own 
&gt; time" to "it isn't worth doing".

Well yes, to me it was an exaggeration which a German or French person
would interpret as "not the best possible use of one's time". ;)


Leaving phrasing and timing aside (Antoine has already explained himself),
how are people who don't go to Pycons supposed to know the opinion of
other core-devs if no one ever voices a complaint on a mailing list?


Stefan Krah








 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/b45534a7/attachment.html>

From brett at python.org  Tue Jul  7 18:15:17 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 07 Jul 2015 16:15:17 +0000
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAP7+vJ+g5O2dG7Gep1OFEYaqVw5UyFrjppXO+oLwcrVziRatfA@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <20150707142524.7966c63d@fsol>
 <CAP7+vJ+g5O2dG7Gep1OFEYaqVw5UyFrjppXO+oLwcrVziRatfA@mail.gmail.com>
Message-ID: <CAP1=2W7m3KzVEXgJ9C8dm_29pExQoq+JyUDXRhgypBhL4ZT84g@mail.gmail.com>

The overhaul of the development process is still on hold while I deal with
trying to get settled in new city and starting a new job next week (writing
this on a tablet because I don't even have a computer ATM). My hope is
everything will settle down enough that I can pick up the work on trying to
update our development process starting in August.

On Tue, Jul 7, 2015, 05:32 Guido van Rossum <guido at python.org> wrote:

> A simple way to address this would have been to CC Raymond on the issue.
> But the reply-to header probably makes that hard. Agreed that post-commit
> reviews don't really scale to our size. It's hard to teach old dogs new
> tricks though. I now realize that my main point, however, was that Raymond
> and Serhiy might have sorted this out offline already without either of
> them bothering to CC python-dev on the fix, so perhaps the discussion about
> our broken process might well have been premature. Certainly I don't think
> automatically rolling back commits is something we should start to do
> without a bigger overhaul of our process -- which takes time and may well
> already be underway.
>
> On Tue, Jul 7, 2015 at 2:25 PM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
>
>> On Tue, 7 Jul 2015 14:14:49 +0200
>> Guido van Rossum <guido at python.org> wrote:
>> > FYI, do we have any indication that Raymond even read the comment? IIRC
>> he
>> > doesn't regularly read python-dev. I also don't think code review
>> comments
>> > ought to go to python-dev; the commiters list would seem more
>> appropriate?
>>
>> Well, do we have to keep a record of what ML each developer reads? Or
>> is post-commit review to be faced each times with dilemmas such as the
>> present: """does this core developer really read that mailing-list?
>> should I
>> email him/her privately, or is that too intrusive? what about writing
>> to that other mailing-list? if they don't answer, did they at least see
>> the message amongst the other threads?"""
>>
>> (this is a nice thing with pre-commit review: you can usually be sure
>> the developer will read your comments, unless there's something
>> seriously wrong with the setup)
>>
>> > (Though it looks like python-checkins is configured to direct replies to
>> > python-dev. Maybe we need to revisit that?)
>>
>> My own preference would be to keep it that way. If python-dev becomes
>> annoying to read, then probably python-checkins isn't very exciting
>> either ;-)
>> (just MHO, of course)
>>
>
>> Regards
>>
>> Antoine.
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> 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
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/305634c9/attachment-0001.html>

From barry at python.org  Tue Jul  7 19:52:50 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 7 Jul 2015 13:52:50 -0400
Subject: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta
 exception requested)
Message-ID: <20150707135250.795a9420@limelight.wooz.org>

Larry and others,

I'd like to bring your attention to issue #15014.  This issue added arbitrary
auth methods to smtplib, which is a good thing.  Implicitly though, a
regression was introduced w.r.t. RFC 4954's optional initial-response for the
AUTH command, for authentication methods that support it.

An example is AUTH PLAIN, which does not require a challenge.  It's possible
that SMTP servers are not prepared to handle challenge/responses for
authentication methods that support initial-response, and regressions have
been seen in the wild while testing against Python 3.5.  In Python 3.4, AUTH
PLAIN included an initial-response.

After discussion on the issue, RDM and I agreed on a refinement to the
authobject() protocol, such that they would be called first with
challenge=None.  If the auth method implemented by the authobject() supports
an initial response, it can return the bytes to be encoded and sent along with
AUTH <METHOD>.  If it returns None, then a challenge is required, and the
normal SMTP challenge/response can proceed.

A minor complication is that clients using smtplib might want to force
challenge/response instead of initial-response even for authentication methods
that support the latter.  There are various reasons for this, including test
suites (such as Python's own test_smtplib.py).

So I added an optional keyword argument called *initial_response_ok* to
SMTP.auth() and SMTP.login(), with a default value of True.  Thus for
authentication methods that support it, smtplib will by default send an
initial-response, but it can easily be overridden.  Defaulting to True
restores compatibility with Python 3.4.

Technically, this is a new feature even though it addresses a regression in
Python 3.5.  Assuming a positive response by RDM or anybody else who would
like to review the patch, I'd like to get a beta release exemption for the
change.

Patch on the issue includes implementation, test, and docs.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/2ed753db/attachment.sig>

From tjreedy at udel.edu  Tue Jul  7 20:53:08 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 7 Jul 2015 14:53:08 -0400
Subject: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta
 exception requested)
In-Reply-To: <20150707135250.795a9420@limelight.wooz.org>
References: <20150707135250.795a9420@limelight.wooz.org>
Message-ID: <mnh76q$qjk$1@ger.gmane.org>

On 7/7/2015 1:52 PM, Barry Warsaw wrote:
> Larry and others,
>
> I'd like to bring your attention to issue #15014.  This issue added arbitrary
> auth methods to smtplib, which is a good thing.  Implicitly though, a
> regression was introduced w.r.t. RFC 4954's optional initial-response for the
> AUTH command, for authentication methods that support it.
>
> An example is AUTH PLAIN, which does not require a challenge.  It's possible
> that SMTP servers are not prepared to handle challenge/responses for
> authentication methods that support initial-response, and regressions have
> been seen in the wild while testing against Python 3.5.  In Python 3.4, AUTH
> PLAIN included an initial-response.
>
> After discussion on the issue, RDM and I agreed on a refinement to the
> authobject() protocol, such that they would be called first with
> challenge=None.  If the auth method implemented by the authobject() supports
> an initial response, it can return the bytes to be encoded and sent along with
> AUTH <METHOD>.  If it returns None, then a challenge is required, and the
> normal SMTP challenge/response can proceed.
>
> A minor complication is that clients using smtplib might want to force
> challenge/response instead of initial-response even for authentication methods
> that support the latter.  There are various reasons for this, including test
> suites (such as Python's own test_smtplib.py).
>
> So I added an optional keyword argument called *initial_response_ok* to
> SMTP.auth() and SMTP.login(), with a default value of True.  Thus for
> authentication methods that support it, smtplib will by default send an
> initial-response, but it can easily be overridden.  Defaulting to True
> restores compatibility with Python 3.4.
>
> Technically, this is a new feature

 From what you said above, this is not an independent new feature, in 
that you would not have proposed it without the prior patch, but rather, 
in effect, an amendment to the original patch, to make the combined 
effect what the original patch should have been.

> even though it addresses a regression in Python 3.5.

The main purpose of releases after feature freeze is to text and fix 
bugs and regressions in added features. The alternative fix would be to 
revert enough of the additions to avoid the regression, and defer such 
to 3.6.

To me, the main question is whether you are sure that your proposal is 
the right fix, or whether you might reasonably do something different 
(with the new arguments) if changes were reverted for the present and 
you two took more time to think about the problem.  My impression is 
that the latter is unlikely because the problem is inherent in the new 
auth methods.

-- 
Terry Jan Reedy


From ethan at stoneleaf.us  Tue Jul  7 21:03:58 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 07 Jul 2015 12:03:58 -0700
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <mngqeu$v4j$1@ger.gmane.org>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
 <mngj0d$u9p$1@ger.gmane.org>
 <CAK5idxSw6FgNGsVSGjMxQ1P4KMF77+VqM1xSCQWQK+R-NYj1TA@mail.gmail.com>
 <mngqeu$v4j$1@ger.gmane.org>
Message-ID: <559C229E.5080100@stoneleaf.us>

On 07/07/2015 08:15 AM, Serhiy Storchaka wrote:
> On 07.07.15 17:33, Maciej Fijalkowski wrote:
>> On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka wrote:

>>> There is no haste. Only developed branch is affected and we have enough time
>>> to fix it. No buildbots is broken.
>>
>> Then maybe a good option would be to add the crasher to the test
>> suite, so the buildbots *are* actually broken showing the problem
>> exists?
>
> This will make harder to notice (and fix!) other regressions.

I don't understand what you are trying to say.  If a bug is worth fixing, it's worth having a test so we don't have to fix it again in the future.

--
~Ethan~

From barry at python.org  Tue Jul  7 21:12:46 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 7 Jul 2015 15:12:46 -0400
Subject: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta
 exception requested)
In-Reply-To: <mnh76q$qjk$1@ger.gmane.org>
References: <20150707135250.795a9420@limelight.wooz.org>
 <mnh76q$qjk$1@ger.gmane.org>
Message-ID: <20150707151246.2ff75ee0@anarchist.wooz.org>

On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote:

>To me, the main question is whether you are sure that your proposal is the
>right fix, or whether you might reasonably do something different (with the
>new arguments) if changes were reverted for the present and you two took more
>time to think about the problem.  My impression is that the latter is
>unlikely because the problem is inherent in the new auth methods.

I generally like the approach that initially added with issue #15014.  This is
a subtle corner of the RFC and an unexpected regression from Python 3.4.

Cheers,
-Barry

From zachary.ware+pydev at gmail.com  Tue Jul  7 21:17:03 2015
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Tue, 7 Jul 2015 14:17:03 -0500
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <559C229E.5080100@stoneleaf.us>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
 <mngj0d$u9p$1@ger.gmane.org>
 <CAK5idxSw6FgNGsVSGjMxQ1P4KMF77+VqM1xSCQWQK+R-NYj1TA@mail.gmail.com>
 <mngqeu$v4j$1@ger.gmane.org> <559C229E.5080100@stoneleaf.us>
Message-ID: <CAKJDb-NeM1_axRg9hahm3OC+SRvs-ny1N61qGTZL2gb6ZoOsfg@mail.gmail.com>

On Tue, Jul 7, 2015 at 2:03 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 07/07/2015 08:15 AM, Serhiy Storchaka wrote:
>> This will make harder to notice (and fix!) other regressions.
>
> I don't understand what you are trying to say.  If a bug is worth fixing,
> it's worth having a test so we don't have to fix it again in the future.

I believe Serhiy's point is that there's no need to commit the test
before the fix, so that the buildbots won't be unnecessarily red until
the fix is committed.  The fix should, of course, include a test.

-- 
Zach

From zachary.ware+pydev at gmail.com  Tue Jul  7 22:20:05 2015
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Tue, 7 Jul 2015 15:20:05 -0500
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAP1=2W4jHbZQxyCdLxYt1knbyLkXeM6ev9KmZwSU7pSYsjNhcQ@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
 <mngj0d$u9p$1@ger.gmane.org>
 <CAK5idxSw6FgNGsVSGjMxQ1P4KMF77+VqM1xSCQWQK+R-NYj1TA@mail.gmail.com>
 <mngqeu$v4j$1@ger.gmane.org> <559C229E.5080100@stoneleaf.us>
 <CAKJDb-NeM1_axRg9hahm3OC+SRvs-ny1N61qGTZL2gb6ZoOsfg@mail.gmail.com>
 <CAP1=2W4jHbZQxyCdLxYt1knbyLkXeM6ev9KmZwSU7pSYsjNhcQ@mail.gmail.com>
Message-ID: <CAKJDb-NJtqvrOPdCh2xLZo53WfpvGYzBbw9UoSmGMhs5-Z76bg@mail.gmail.com>

On Tue, Jul 7, 2015 at 3:16 PM, Brett Cannon <brett at python.org> wrote:
> The test could be marked as an expected failure in the interim somitnisnt
> forgotten.

True, but in this case things would be a bit more difficult since the
testcase segfaults rather than just throwing an exception.

-- 
Zach

From brett at python.org  Tue Jul  7 22:16:51 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 07 Jul 2015 20:16:51 +0000
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAKJDb-NeM1_axRg9hahm3OC+SRvs-ny1N61qGTZL2gb6ZoOsfg@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
 <mngj0d$u9p$1@ger.gmane.org>
 <CAK5idxSw6FgNGsVSGjMxQ1P4KMF77+VqM1xSCQWQK+R-NYj1TA@mail.gmail.com>
 <mngqeu$v4j$1@ger.gmane.org> <559C229E.5080100@stoneleaf.us>
 <CAKJDb-NeM1_axRg9hahm3OC+SRvs-ny1N61qGTZL2gb6ZoOsfg@mail.gmail.com>
Message-ID: <CAP1=2W4jHbZQxyCdLxYt1knbyLkXeM6ev9KmZwSU7pSYsjNhcQ@mail.gmail.com>

 On Tue, Jul 7, 2015, 12:17 Zachary Ware <zachary.ware+pydev at gmail.com>
wrote:

On Tue, Jul 7, 2015 at 2:03 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 07/07/2015 08:15 AM, Serhiy Storchaka wrote:
>> This will make harder to notice (and fix!) other regressions.
>
> I don't understand what you are trying to say.  If a bug is worth fixing,
> it's worth having a test so we don't have to fix it again in the future.

I believe Serhiy's point is that there's no need to commit the test
before the fix, so that the buildbots won't be unnecessarily red until
the fix is committed.  The fix should, of course, include a test.


The test could be marked as an expected failure in the interim somitnisnt
forgotten.

-Brett


--
Zach
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/brett%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/70870ff0/attachment.html>

From skip.montanaro at gmail.com  Tue Jul  7 23:16:44 2015
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Tue, 7 Jul 2015 16:16:44 -0500
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAKJDb-NJtqvrOPdCh2xLZo53WfpvGYzBbw9UoSmGMhs5-Z76bg@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <mng1h1$3fq$1@ger.gmane.org>
 <CAK5idxS989gnm3077AFgViyGBJ6ASZO9b-BMxaxVECd+qFFZnQ@mail.gmail.com>
 <20150707132412.3acadb42@fsol>
 <CAP7+vJKoZgxFRhZvYDZks6Xia4-8+Nb9w9HbaT16hKDZSiUZnw@mail.gmail.com>
 <CAK5idxS_NZ5FsS6tH=h1fQmkL3KreGbA6-tbzKXEGTdtUerO0g@mail.gmail.com>
 <mngj0d$u9p$1@ger.gmane.org>
 <CAK5idxSw6FgNGsVSGjMxQ1P4KMF77+VqM1xSCQWQK+R-NYj1TA@mail.gmail.com>
 <mngqeu$v4j$1@ger.gmane.org> <559C229E.5080100@stoneleaf.us>
 <CAKJDb-NeM1_axRg9hahm3OC+SRvs-ny1N61qGTZL2gb6ZoOsfg@mail.gmail.com>
 <CAP1=2W4jHbZQxyCdLxYt1knbyLkXeM6ev9KmZwSU7pSYsjNhcQ@mail.gmail.com>
 <CAKJDb-NJtqvrOPdCh2xLZo53WfpvGYzBbw9UoSmGMhs5-Z76bg@mail.gmail.com>
Message-ID: <CANc-5Uw5U-S3Fk6oXdjCqrX1tCoSaqtFGP2vobootumq8Pd6Ag@mail.gmail.com>

Just thinking out loud here, but could you devote a single buildbot to the
cause? It would only ever try to build from the "crasher" branch. When a
crash is discovered like this one, you can do whatever is necessary to
merge the code and a crasher test case to that branch. It would then turn
red. Might a segfault provide enough output to debug?

Skip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150707/38b660dc/attachment.html>

From raymond.hettinger at gmail.com  Wed Jul  8 00:45:12 2015
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Tue, 7 Jul 2015 15:45:12 -0700
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
	use an entry pointer rather than
In-Reply-To: <mnfvtk$anv$1@ger.gmane.org>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
Message-ID: <E833D117-AD92-4B12-9E5E-24D7BC378234@gmail.com>


> On Jul 7, 2015, at 12:42 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 
> What if so->table was reallocated during the iteration, but so->used is left the same? This change looks unsafe to me.


FWIW, the mutation detection code in the iterator logic has always been vulnerable to being fooled the way you describe. The difference this time is that it results in a crash rather than a wrong answer.  I've rolled back the commit so we are back to where we've always been.


Raymond


P.S.  I don't think python-dev post was necessary or helpful (and I still haven't had a chance to read the whole thread).  It would have been sufficient to assign the tracker entry back to me.

From breamoreboy at yahoo.co.uk  Wed Jul  8 17:36:59 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Wed, 08 Jul 2015 16:36:59 +0100
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <20150707164231.2bfdb9f4@fsol>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
 <14e684e58e2.115ad9114246975.8855519462170688269@bytereef.org>
 <CADiSq7cgAhSTQwWMX5f1cobr00x0pJJVA8omyaP6xX4KFqatMg@mail.gmail.com>
 <20150707164231.2bfdb9f4@fsol>
Message-ID: <mnjg30$inh$1@ger.gmane.org>

On 07/07/2015 15:42, Antoine Pitrou wrote:
>
> Whether the time required to properly follow python-ideas is a
> productive involvement for the average core dev is another question.
> The problem I see with python-ideas is that it may select on free time
> more than on actual, concrete contribution...
>
> (note that python-list has a similar problem with some of its old-timers
> and regular ranters; the difference is that python-list has a ready
> alternative in StackOverflow, with perhaps higher-quality answers...
> it's less and less relevant in the grand scheme of things)
>

I cannot see StackOverflow as a "ready alternative" to python-list as 
questions are strictly closed, nothing in the way of debate is allowed. 
  I'd love to explain to some people what I think of their "perhaps 
higher-quality answers" but I don't have enough "reputation".

Having said that I have to agree about python-list, there is very little 
of any substance on there nowadays.  Perhaps that's because people are 
reading any of the 387 Python lists on gmane that are dedicated to their 
specific area of interest?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From storchaka at gmail.com  Wed Jul  8 22:19:01 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 08 Jul 2015 23:19:01 +0300
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <E833D117-AD92-4B12-9E5E-24D7BC378234@gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <E833D117-AD92-4B12-9E5E-24D7BC378234@gmail.com>
Message-ID: <mnk0jm$cot$1@ger.gmane.org>

On 08.07.15 01:45, Raymond Hettinger wrote:
> P.S.  I don't think python-dev post was necessary or helpful (and I still haven't had a chance to read the whole thread).  It would have been sufficient to assign the tracker entry back to me.

Well, I'll open new issue and assign it to you for every your commit 
that looks questionable to me.



From ncoghlan at gmail.com  Thu Jul  9 12:47:11 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 9 Jul 2015 20:47:11 +1000
Subject: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta
 exception requested)
In-Reply-To: <20150707151246.2ff75ee0@anarchist.wooz.org>
References: <20150707135250.795a9420@limelight.wooz.org>
 <mnh76q$qjk$1@ger.gmane.org>
 <20150707151246.2ff75ee0@anarchist.wooz.org>
Message-ID: <CADiSq7eOh6VPRtuvvRgBP9zqEPvaAnwzb4mz8rXVYw=r3_CAYg@mail.gmail.com>

On 8 July 2015 at 05:12, Barry Warsaw <barry at python.org> wrote:
> On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote:
>
>>To me, the main question is whether you are sure that your proposal is the
>>right fix, or whether you might reasonably do something different (with the
>>new arguments) if changes were reverted for the present and you two took more
>>time to think about the problem.  My impression is that the latter is
>>unlikely because the problem is inherent in the new auth methods.
>
> I generally like the approach that initially added with issue #15014.  This is
> a subtle corner of the RFC and an unexpected regression from Python 3.4.

That strikes me as just the kind of
not-quite-as-finished-as-we-thought case that the beta cycle is
designed to flush out, so the minor further enhancement sounds like a
good idea to me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Thu Jul  9 12:57:33 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 9 Jul 2015 20:57:33 +1000
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <20150707164231.2bfdb9f4@fsol>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
 <14e684e58e2.115ad9114246975.8855519462170688269@bytereef.org>
 <CADiSq7cgAhSTQwWMX5f1cobr00x0pJJVA8omyaP6xX4KFqatMg@mail.gmail.com>
 <20150707164231.2bfdb9f4@fsol>
Message-ID: <CADiSq7fuBzsShuozT2WuGp1qY2L-UABUp_T2ORa2RV_M5z9Q6A@mail.gmail.com>

On 8 July 2015 at 00:42, Antoine Pitrou <solipsis at pitrou.net> wrote:
> In this case, though, I was a bit miffed since I didn't notice that
> PEP appearing on python-ideas (or perhaps I already forget discussing
> it?), which made me frustrated that *perhaps* with less pointless
> drifting I would have seen it. Being one of the principal maintainers
> of the ssl module I was definitely interested on giving my opinion.

And it turns out that omission is entirely my fault - I *thought* I'd
previously started a python-ideas thread, but instead we only filed a
tracker issue, and I *didn't* add everyone handling ssl module
maintenance to the nosy list for it. If I'd added a proper references
section to the PEP I would have noticed there *wasn't* a previous
thread on it and I was misremembering. My apologies for the confusion.

I'll add a proper references section to the PEP (which will also call
out the Red Hat CVE thread more clearly) in addition to fixing the
example code to respect the "ignore_environment" flag.

As Guido suggested, would you be willing to take on the BDFL-Delegate
task for this? It definitely seems appropriate given the errors and
omissions you've already found :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From guido at python.org  Thu Jul  9 14:41:11 2015
From: guido at python.org (Guido van Rossum)
Date: Thu, 9 Jul 2015 14:41:11 +0200
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <mnk0jm$cot$1@ger.gmane.org>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <E833D117-AD92-4B12-9E5E-24D7BC378234@gmail.com> <mnk0jm$cot$1@ger.gmane.org>
Message-ID: <CAP7+vJJn=n+WnGWCFXVtqDJgvmpkAXmPi4oKbkhigHnG-aXt_Q@mail.gmail.com>

On Wed, Jul 8, 2015 at 10:19 PM, Serhiy Storchaka <storchaka at gmail.com>
wrote:

> On 08.07.15 01:45, Raymond Hettinger wrote:
>
>> P.S.  I don't think python-dev post was necessary or helpful (and I still
>> haven't had a chance to read the whole thread).  It would have been
>> sufficient to assign the tracker entry back to me.
>>
>
> Well, I'll open new issue and assign it to you for every your commit that
> looks questionable to me.
>

That sounds like a fine solution, and a good conclusion of the thread.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150709/600c5d9e/attachment.html>

From solipsis at pitrou.net  Thu Jul  9 15:15:18 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 9 Jul 2015 15:15:18 +0200
Subject: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7
	HTTPS
In-Reply-To: <CADiSq7fuBzsShuozT2WuGp1qY2L-UABUp_T2ORa2RV_M5z9Q6A@mail.gmail.com>
References: <CADiSq7cW3-gSEZJ7O82-7Lxg0pGm0e1_iwx6G5+X66mf6TyRhg@mail.gmail.com>
 <20150706122123.195c4c57@fsol>
 <CAOTD34bM2Bq_7nxS=YUwFS=h6i2qGz_2SZHq6eTBq4Mci7c+CQ@mail.gmail.com>
 <14e684e58e2.115ad9114246975.8855519462170688269@bytereef.org>
 <CADiSq7cgAhSTQwWMX5f1cobr00x0pJJVA8omyaP6xX4KFqatMg@mail.gmail.com>
 <20150707164231.2bfdb9f4@fsol>
 <CADiSq7fuBzsShuozT2WuGp1qY2L-UABUp_T2ORa2RV_M5z9Q6A@mail.gmail.com>
Message-ID: <20150709151518.49d764db@fsol>

On Thu, 9 Jul 2015 20:57:33 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> As Guido suggested, would you be willing to take on the BDFL-Delegate
> task for this? It definitely seems appropriate given the errors and
> omissions you've already found :)

Fine.  I'll take a look again and come up with questions, if I have any.

Regards

Antoine.

From christian at python.org  Thu Jul  9 15:29:25 2015
From: christian at python.org (Christian Heimes)
Date: Thu, 09 Jul 2015 15:29:25 +0200
Subject: [Python-Dev] OpenSSL Security Advisory [9 Jul 2015]
Message-ID: <mnlsvl$5bd$1@ger.gmane.org>

Hi,

this just came in. According to Zachary all Windows builds use 1.0.2c.
The version is vulnerable to a critical bug in the CA validation code of
OpenSSL. The bug can be abused to turn any valid server certificate into
a CA cert.

We should consider a security release of Python ASAP.



Alternative chains certificate forgery (CVE-2015-1793)
======================================================

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n
and 1.0.2b) will attempt to find an alternative certificate chain if the
first attempt to build such a chain fails. An error in the
implementation of this logic can mean that an attacker could cause
certain checks on untrusted certificates to be bypassed, such as the CA
flag, enabling them to use a valid leaf certificate to act as a CA and
"issue" an invalid certificate.

This issue will impact any application that verifies certificates
including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client
authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam
Langley/David Benjamin (Google/BoringSSL). The fix was developed by the
BoringSSL project.

Note
====

As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL
versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security
updates for these releases will be provided after that date. Users of
these releases are advised to upgrade.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv_20150709.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html



From christian at python.org  Thu Jul  9 15:39:22 2015
From: christian at python.org (Christian Heimes)
Date: Thu, 09 Jul 2015 15:39:22 +0200
Subject: [Python-Dev] OpenSSL Security Advisory [9 Jul 2015]
In-Reply-To: <mnlsvl$5bd$1@ger.gmane.org>
References: <mnlsvl$5bd$1@ger.gmane.org>
Message-ID: <559E798A.6080004@python.org>

On 2015-07-09 15:29, Christian Heimes wrote:
> Hi,
> 
> this just came in. According to Zachary all Windows builds use 1.0.2c.
> The version is vulnerable to a critical bug in the CA validation code of
> OpenSSL. The bug can be abused to turn any valid server certificate into
> a CA cert.
> 
> We should consider a security release of Python ASAP.

Good news! I was too fast and it looks like we are mostly safe.

1.0.2c is only used in 3.5b3. The production builds are either using
1.0.2a or 1.0.1j.

Christian

From barry at python.org  Thu Jul  9 15:45:06 2015
From: barry at python.org (Barry Warsaw)
Date: Thu, 9 Jul 2015 09:45:06 -0400
Subject: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta
 exception requested)
In-Reply-To: <CADiSq7eOh6VPRtuvvRgBP9zqEPvaAnwzb4mz8rXVYw=r3_CAYg@mail.gmail.com>
References: <20150707135250.795a9420@limelight.wooz.org>
 <mnh76q$qjk$1@ger.gmane.org>
 <20150707151246.2ff75ee0@anarchist.wooz.org>
 <CADiSq7eOh6VPRtuvvRgBP9zqEPvaAnwzb4mz8rXVYw=r3_CAYg@mail.gmail.com>
Message-ID: <20150709094506.5c7ee8c8@limelight.wooz.org>

On Jul 09, 2015, at 08:47 PM, Nick Coghlan wrote:

>That strikes me as just the kind of
>not-quite-as-finished-as-we-thought case that the beta cycle is
>designed to flush out, so the minor further enhancement sounds like a
>good idea to me.

Cool.  RDM provided some good feedback in the review, so I'll be committing
this at some point today.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150709/b4efa50f/attachment.sig>

From meadori at gmail.com  Thu Jul  9 16:35:01 2015
From: meadori at gmail.com (Meador Inge)
Date: Thu, 9 Jul 2015 09:35:01 -0500
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAP7+vJJn=n+WnGWCFXVtqDJgvmpkAXmPi4oKbkhigHnG-aXt_Q@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <E833D117-AD92-4B12-9E5E-24D7BC378234@gmail.com>
 <mnk0jm$cot$1@ger.gmane.org>
 <CAP7+vJJn=n+WnGWCFXVtqDJgvmpkAXmPi4oKbkhigHnG-aXt_Q@mail.gmail.com>
Message-ID: <CAK1Qooo0V9NF6v1d_ZM0ewd7_wjYZPoWgwdm7gaimU+ZT8K+hA@mail.gmail.com>

On Thu, Jul 9, 2015 at 7:41 AM, Guido van Rossum <guido at python.org> wrote:

> On Wed, Jul 8, 2015 at 10:19 PM, Serhiy Storchaka <storchaka at gmail.com>
> wrote:
>>
>> On 08.07.15 01:45, Raymond Hettinger wrote:
>>>
>>> P.S.  I don't think python-dev post was necessary or helpful (and I still
>>> haven't had a chance to read the whole thread).  It would have been
>>> sufficient to assign the tracker entry back to me.
>>
>>
>> Well, I'll open new issue and assign it to you for every your commit that
>> looks questionable to me.
>
>
> That sounds like a fine solution, and a good conclusion of the thread.

I don't have a very strong opinion on the solution, but should the dev guide
be updated to clarify the feelings expressed about the mailing lists in this
thread?  My interpretation of the dev guide always left me with the feeling
that following python-dev was expected for Python core devs:

  * https://docs.python.org/devguide/communication.html#communication

  * https://docs.python.org/devguide/coredev.html#mailing-lists

-- Meador

From cyril.scetbon at free.fr  Thu Jul  9 19:34:09 2015
From: cyril.scetbon at free.fr (Cyril Scetbon)
Date: Thu, 9 Jul 2015 19:34:09 +0200
Subject: [Python-Dev] modules dependencies issues
Message-ID: <5ACE50F8-820A-4643-98B4-EF3F22D54F2F@free.fr>

Hi,

I use pip to install modules and setuptools to install dependencies, and generate a console_script using the entry_point parameter of setup.
Here is the issue :

my current sources depend on modules, let's say A=1.0, B=1.0, C=2.0. And C depends on B=1.1
I have no problem with using pip to install dependencies. However setuptools complain that 2 versions are conflicting :

Installed /private/tmp/test/my-module
Processing dependencies for my-module==0.0.1
error: B 1.0 is installed but B==1.1 is required by set(['C'])

Forcing my-module to use B=1.1 fixes the issue. However it's just a sample and my code is using a lot of modules that use other shared modules too. Is there a way to let dependencies use their own version of the modules they need while the current use another version ?
Currently every time we need to upgrade one module, we need to make sure dependencies use this new version too :(

Thanks
-- 
Cyril SCETBON


From ethan at stoneleaf.us  Thu Jul  9 20:24:49 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 09 Jul 2015 11:24:49 -0700
Subject: [Python-Dev] modules dependencies issues
In-Reply-To: <5ACE50F8-820A-4643-98B4-EF3F22D54F2F@free.fr>
References: <5ACE50F8-820A-4643-98B4-EF3F22D54F2F@free.fr>
Message-ID: <559EBC71.20101@stoneleaf.us>

On 07/09/2015 10:34 AM, Cyril Scetbon wrote:

[...]

Greetings!

You have found the gathering place of the Python Developers -- as in, we discuss the development /of/ Python, not developing /with/ Python.

You should ask your question on python-list, and perhaps on distutils-sig.

Good luck!

--
~Ethan~

From cyril.scetbon at free.fr  Thu Jul  9 21:06:00 2015
From: cyril.scetbon at free.fr (Cyril Scetbon)
Date: Thu, 9 Jul 2015 21:06:00 +0200
Subject: [Python-Dev] modules dependencies issues
In-Reply-To: <559EBC71.20101@stoneleaf.us>
References: <5ACE50F8-820A-4643-98B4-EF3F22D54F2F@free.fr>
 <559EBC71.20101@stoneleaf.us>
Message-ID: <AC2D118F-CF56-4984-98AF-330DBC476234@free.fr>

Okay I'll try.

Thanks
> On Jul 9, 2015, at 20:24, Ethan Furman <ethan at stoneleaf.us> wrote:
> 
> On 07/09/2015 10:34 AM, Cyril Scetbon wrote:
> 
> [...]
> 
> Greetings!
> 
> You have found the gathering place of the Python Developers -- as in, we discuss the development /of/ Python, not developing /with/ Python.
> 
> You should ask your question on python-list, and perhaps on distutils-sig.
> 
> Good luck!
> 
> --
> ~Ethan~
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/cyril.scetbon%40free.fr


From status at bugs.python.org  Fri Jul 10 18:08:27 2015
From: status at bugs.python.org (Python tracker)
Date: Fri, 10 Jul 2015 18:08:27 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150710160827.4ADCD566B1@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-07-03 - 2015-07-10)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4928 ( +6)
  closed 31439 (+40)
  total  36367 (+46)

Open issues with patches: 2257 


Issues opened (24)
==================

#24563: Encoding declaration: doc supported encodings
http://bugs.python.org/issue24563  opened by terry.reedy

#24564: shutil.copytree fails when copying NFS to NFS
http://bugs.python.org/issue24564  opened by jhamrick

#24565: the f_lineno getter is broken
http://bugs.python.org/issue24565  opened by xdegaye

#24567: random.choice IndexError due to double-rounding
http://bugs.python.org/issue24567  opened by steven.daprano

#24570: IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with Act
http://bugs.python.org/issue24570  opened by Alessandro Rosa

#24572: IDLE Text Output With ASCII Control Codes Not Working
http://bugs.python.org/issue24572  opened by Kevin Phillips (kmecpp)

#24575: timemodule build fail - missing definitions for _Py_BEGIN_SUPP
http://bugs.python.org/issue24575  opened by tnmurphy

#24577: Document asyncio behavior (logging and call to connection_lost
http://bugs.python.org/issue24577  opened by r.david.murray

#24580: Wrong or missing exception when compiling regexes with recursi
http://bugs.python.org/issue24580  opened by dhaffey

#24583: set.update(): Crash when source set is changed during merging
http://bugs.python.org/issue24583  opened by serhiy.storchaka

#24585: Windows installer does not detect existing installs
http://bugs.python.org/issue24585  opened by steve.dower

#24587: Incorrect tkinter behavior of slave widgets of Button
http://bugs.python.org/issue24587  opened by Eugene K.

#24591: offer option to suppress "clean --all" output relating to none
http://bugs.python.org/issue24591  opened by alanf

#24594: msilib.OpenDatabase Type Confusion
http://bugs.python.org/issue24594  opened by JohnLeitch

#24595: InteractiveInterpreter always prints to stdout
http://bugs.python.org/issue24595  opened by graphite

#24596: Script globals in a GC cycle not finalized when exiting with S
http://bugs.python.org/issue24596  opened by encukou

#24597: forbid redefinition of specializations in singledispatch
http://bugs.python.org/issue24597  opened by pitrou

#24598: asyncio: add background task detecting reference cycles
http://bugs.python.org/issue24598  opened by haypo

#24599: urllib URLopener().open  https url returns 501 Not Implemented
http://bugs.python.org/issue24599  opened by stefano-m

#24601: bytes and unicode splitlines() methods differ on what is a lin
http://bugs.python.org/issue24601  opened by gregory.p.smith

#24602: SRE_SEARCH Integer Underflow
http://bugs.python.org/issue24602  opened by JohnLeitch

#24603: Update OpenSSL to 1.0.2d in Windows and OS X installer
http://bugs.python.org/issue24603  opened by Friedrich.Spee.von.Langenfeld

#24605: segmentation fault at asciilib_split_char.lto_priv
http://bugs.python.org/issue24605  opened by josch

#24606: segfault caused by nested calls to map()
http://bugs.python.org/issue24606  opened by David Luke??



Most recent 15 issues with no replies (15)
==========================================

#24606: segfault caused by nested calls to map()
http://bugs.python.org/issue24606

#24591: offer option to suppress "clean --all" output relating to none
http://bugs.python.org/issue24591

#24587: Incorrect tkinter behavior of slave widgets of Button
http://bugs.python.org/issue24587

#24577: Document asyncio behavior (logging and call to connection_lost
http://bugs.python.org/issue24577

#24557: Refactor LibreSSL / EGD detection
http://bugs.python.org/issue24557

#24550: maxint on 64 bit platforms breaks os.read
http://bugs.python.org/issue24550

#24542: ssl - SSL_OP_NO_TICKET not reimplemented
http://bugs.python.org/issue24542

#24527: The MimeTypes class cannot ignore global files per instance
http://bugs.python.org/issue24527

#24520: Stop using deprecated floating-point environment functions on 
http://bugs.python.org/issue24520

#24512: multiprocessing should log a warning when forking multithreade
http://bugs.python.org/issue24512

#24499: Python Installer text piles up during installation process
http://bugs.python.org/issue24499

#24498: Should ptags and eptags be removed from repo?
http://bugs.python.org/issue24498

#24477: In argparse subparser's option goes to parent parser
http://bugs.python.org/issue24477

#24466: extend_path explanation in documentation is ambiguous
http://bugs.python.org/issue24466

#24424: xml.dom.minidom: performance issue with Node.insertBefore()
http://bugs.python.org/issue24424



Most recent 15 issues waiting for review (15)
=============================================

#24602: SRE_SEARCH Integer Underflow
http://bugs.python.org/issue24602

#24594: msilib.OpenDatabase Type Confusion
http://bugs.python.org/issue24594

#24583: set.update(): Crash when source set is changed during merging
http://bugs.python.org/issue24583

#24580: Wrong or missing exception when compiling regexes with recursi
http://bugs.python.org/issue24580

#24565: the f_lineno getter is broken
http://bugs.python.org/issue24565

#24563: Encoding declaration: doc supported encodings
http://bugs.python.org/issue24563

#24557: Refactor LibreSSL / EGD detection
http://bugs.python.org/issue24557

#24536: os.pipe() should return a structsequence (or namedtuple.)
http://bugs.python.org/issue24536

#24533: Increased Test Coverage for Lib/random.py
http://bugs.python.org/issue24533

#24531: please document that no code preceding encoding declaration is
http://bugs.python.org/issue24531

#24520: Stop using deprecated floating-point environment functions on 
http://bugs.python.org/issue24520

#24518: json.dumps should accept key function for ``sort_keys``
http://bugs.python.org/issue24518

#24508: Backport 3.5's Windows build project files to 2.7
http://bugs.python.org/issue24508

#24506: make fails with gcc 4.9 due to fatal warning of unused variabl
http://bugs.python.org/issue24506

#24485: Function source inspection fails on closures
http://bugs.python.org/issue24485



Top 10 most discussed issues (10)
=================================

#24567: random.choice IndexError due to double-rounding
http://bugs.python.org/issue24567  20 msgs

#24546: sequence index bug in random.choice
http://bugs.python.org/issue24546  12 msgs

#24553: improve test coverage for subinterpreters
http://bugs.python.org/issue24553   9 msgs

#23441: rlcompleter: tab on empty prefix => insert spaces
http://bugs.python.org/issue23441   8 msgs

#24597: forbid redefinition of specializations in singledispatch
http://bugs.python.org/issue24597   8 msgs

#16487: Allow ssl certificates to be specified from memory rather than
http://bugs.python.org/issue16487   7 msgs

#24598: asyncio: add background task detecting reference cycles
http://bugs.python.org/issue24598   7 msgs

#24599: urllib URLopener().open  https url returns 501 Not Implemented
http://bugs.python.org/issue24599   7 msgs

#24136: document PEP 448: unpacking generalization
http://bugs.python.org/issue24136   6 msgs

#23601: use small object allocator for dict key storage
http://bugs.python.org/issue23601   5 msgs



Issues closed (35)
==================

#11582: Boilerplate code replaced in Python/ceval.c
http://bugs.python.org/issue11582  closed by akuchling

#18684: Pointers point out of array bound in _sre.c
http://bugs.python.org/issue18684  closed by serhiy.storchaka

#20154: Deadlock in asyncio.StreamReader.readexactly() (fix applied, n
http://bugs.python.org/issue20154  closed by haypo

#21148: avoid needless pointers initialization in small tuple creation
http://bugs.python.org/issue21148  closed by jtaylor

#24181: test_fileio crash, 3.5, Win 7
http://bugs.python.org/issue24181  closed by steve.dower

#24259: tar.extractall() does not recognize unexpected EOF
http://bugs.python.org/issue24259  closed by lars.gustaebel

#24330: Idle doc: explain "Configure Idle" not in "Options" on OSX, et
http://bugs.python.org/issue24330  closed by ned.deily

#24407: Use after free in PyDict_merge
http://bugs.python.org/issue24407  closed by python-dev

#24432: Upgrade windows builds to use OpenSSL 1.0.2c
http://bugs.python.org/issue24432  closed by steve.dower

#24524: python crash using Tkinter
http://bugs.python.org/issue24524  closed by terry.reedy

#24525: [doc] missing word
http://bugs.python.org/issue24525  closed by terry.reedy

#24540: Docstring for json.dumps skipkeys parameter is incorrect
http://bugs.python.org/issue24540  closed by ned.deily

#24548: Broken link in the unittest documentation
http://bugs.python.org/issue24548  closed by r.david.murray

#24561: [VS2013] Py_InitializeEx causes fatal error being called from 
http://bugs.python.org/issue24561  closed by steve.dower

#24562: ntpath splitdrive fails on line 161: tuple has no attribute 'r
http://bugs.python.org/issue24562  closed by r.david.murray

#24566: Unsigned Integer Overflow in sre_lib.h
http://bugs.python.org/issue24566  closed by serhiy.storchaka

#24568: Misc/NEWS: "free-after-use" -> "use-after-free"
http://bugs.python.org/issue24568  closed by python-dev

#24569: Inconsistent PEP 0448 implementation
http://bugs.python.org/issue24569  closed by python-dev

#24571: [RFE] Add asyncio.background_call API
http://bugs.python.org/issue24571  closed by gvanrossum

#24573: Using multiprocessing with tkinter frames in Python 3.4.3 cras
http://bugs.python.org/issue24573  closed by ned.deily

#24574: ANSI escape sequences breaking string justification
http://bugs.python.org/issue24574  closed by eric.smith

#24576: python27 unicode align comments
http://bugs.python.org/issue24576  closed by ned.deily

#24578: [RFE] Add asyncio.wait_for_result API
http://bugs.python.org/issue24578  closed by ncoghlan

#24579: Additional tests for urllib module
http://bugs.python.org/issue24579  closed by craign

#24581: Crash when a set is changed during iteration
http://bugs.python.org/issue24581  closed by rhettinger

#24582: Minor branch optimization in set implementation
http://bugs.python.org/issue24582  closed by rhettinger

#24584: Windows installer incorrectly detects CRT version on Windows 1
http://bugs.python.org/issue24584  closed by steve.dower

#24586: Operator precedence for 1<-1==0
http://bugs.python.org/issue24586  closed by r.david.murray

#24588: Unable to pass argument to python script from Java program
http://bugs.python.org/issue24588  closed by r.david.murray

#24589: Wrong behavior for list of lists
http://bugs.python.org/issue24589  closed by vadmium

#24590: Customized attribute access causes infinite loop
http://bugs.python.org/issue24590  closed by zorceta

#24592: global var defined in module not returned by function
http://bugs.python.org/issue24592  closed by steve.dower

#24593: [3.5.0b3] stdlib on Windows mismatches compiled version
http://bugs.python.org/issue24593  closed by r.david.murray

#24600: function(**dict) does not accept comma after dict (inside pare
http://bugs.python.org/issue24600  closed by r.david.murray

#24604: problem to install scipy manually on Centos 6
http://bugs.python.org/issue24604  closed by haypo

From robertc at robertcollins.net  Tue Jul 14 04:01:25 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Tue, 14 Jul 2015 14:01:25 +1200
Subject: [Python-Dev] Freeze exception for http://bugs.python.org/issue23661
	?
Message-ID: <CAJ3HoZ2BY30QMTvoQ2HWg17Lt+kXWmAHr_xh5sOLydU97CUyig@mail.gmail.com>

So unittest.mock regressed during 3.5, and I found out when I released
the mock backport.

The regression is pretty shallow - I've applied the fix to 3.6, its a
one-liner and comes with a patch.

Whats the process for getting this into 3.5? Its likely to affect a
lot of folk using mock (pretty much every OpenStack project got git
with it when I released mock 1.1).

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From robertc at robertcollins.net  Tue Jul 14 04:28:28 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Tue, 14 Jul 2015 14:28:28 +1200
Subject: [Python-Dev] Freeze exception for
 http://bugs.python.org/issue23661 ?
In-Reply-To: <20150714022509.307CAB140A2@webabinitio.net>
References: <CAJ3HoZ2BY30QMTvoQ2HWg17Lt+kXWmAHr_xh5sOLydU97CUyig@mail.gmail.com>
 <20150714022509.307CAB140A2@webabinitio.net>
Message-ID: <CAJ3HoZ3uEGT67EYDqxmMKgePjnRFHZtHg03pMhRXbV957Gmm2A@mail.gmail.com>

On 14 July 2015 at 14:25, R. David Murray <rdmurray at bitdance.com> wrote:
> On Tue, 14 Jul 2015 14:01:25 +1200, Robert Collins <robertc at robertcollins.net> wrote:
>> So unittest.mock regressed during 3.5, and I found out when I released
>> the mock backport.
>>
>> The regression is pretty shallow - I've applied the fix to 3.6, its a
>> one-liner and comes with a patch.
>>
>> Whats the process for getting this into 3.5? Its likely to affect a
>> lot of folk using mock (pretty much every OpenStack project got git
>> with it when I released mock 1.1).
>
> 3.5 hasn't been released yet.  The patch ideally would have gone into
> 3.5 first, then been merged to 3.6.  As it is, you'll apply it to
> 3.5, and then do a null merge to 3.6.  It will get released in the
> next 3.5 beta.

What I'm unclear on is the approval process for doing ^.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From rdmurray at bitdance.com  Tue Jul 14 04:25:08 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 13 Jul 2015 22:25:08 -0400
Subject: [Python-Dev] Freeze exception for
	http://bugs.python.org/issue23661 ?
In-Reply-To: <CAJ3HoZ2BY30QMTvoQ2HWg17Lt+kXWmAHr_xh5sOLydU97CUyig@mail.gmail.com>
References: <CAJ3HoZ2BY30QMTvoQ2HWg17Lt+kXWmAHr_xh5sOLydU97CUyig@mail.gmail.com>
Message-ID: <20150714022509.307CAB140A2@webabinitio.net>

On Tue, 14 Jul 2015 14:01:25 +1200, Robert Collins <robertc at robertcollins.net> wrote:
> So unittest.mock regressed during 3.5, and I found out when I released
> the mock backport.
> 
> The regression is pretty shallow - I've applied the fix to 3.6, its a
> one-liner and comes with a patch.
> 
> Whats the process for getting this into 3.5? Its likely to affect a
> lot of folk using mock (pretty much every OpenStack project got git
> with it when I released mock 1.1).

3.5 hasn't been released yet.  The patch ideally would have gone into
3.5 first, then been merged to 3.6.  As it is, you'll apply it to
3.5, and then do a null merge to 3.6.  It will get released in the
next 3.5 beta.

--David

From ncoghlan at gmail.com  Tue Jul 14 06:32:31 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 14 Jul 2015 14:32:31 +1000
Subject: [Python-Dev] Freeze exception for
 http://bugs.python.org/issue23661 ?
In-Reply-To: <CAJ3HoZ3uEGT67EYDqxmMKgePjnRFHZtHg03pMhRXbV957Gmm2A@mail.gmail.com>
References: <CAJ3HoZ2BY30QMTvoQ2HWg17Lt+kXWmAHr_xh5sOLydU97CUyig@mail.gmail.com>
 <20150714022509.307CAB140A2@webabinitio.net>
 <CAJ3HoZ3uEGT67EYDqxmMKgePjnRFHZtHg03pMhRXbV957Gmm2A@mail.gmail.com>
Message-ID: <CADiSq7eovzq6F2bXNX0h_Y5oCKcQhtXzDcMQYi20WZwyUY4CZA@mail.gmail.com>

On 14 July 2015 at 12:28, Robert Collins <robertc at robertcollins.net> wrote:
> On 14 July 2015 at 14:25, R. David Murray <rdmurray at bitdance.com> wrote:
>> On Tue, 14 Jul 2015 14:01:25 +1200, Robert Collins <robertc at robertcollins.net> wrote:
>>> So unittest.mock regressed during 3.5, and I found out when I released
>>> the mock backport.
>>>
>>> The regression is pretty shallow - I've applied the fix to 3.6, its a
>>> one-liner and comes with a patch.
>>>
>>> Whats the process for getting this into 3.5? Its likely to affect a
>>> lot of folk using mock (pretty much every OpenStack project got git
>>> with it when I released mock 1.1).
>>
>> 3.5 hasn't been released yet.  The patch ideally would have gone into
>> 3.5 first, then been merged to 3.6.  As it is, you'll apply it to
>> 3.5, and then do a null merge to 3.6.  It will get released in the
>> next 3.5 beta.
>
> What I'm unclear on is the approval process for doing ^.

During the beta period, 3.5 is open for normal maintenance (i.e.
anything that would be acceptable in a 3.5.1 release).

The 3.5 changes that need a +1 from Larry as release manager are the
ones where beta feedback reveals an "incomplete feature", where we
need to make a more significant change to resolve it that would
normally be disallowed on a maintenance branch (e.g. sorting out the
data model for PEP 492 after Ben Darnell's attempts to integrate
native coroutines with Tornado highlighted a number of shortcomings in
the original design).

The 3.4 branch also remains open for general maintenance until 3.4.4
goes out, at which put I assume Larry will put that branch into
security fix only mode.

I wonder: should we start putting some of these process details for
the different phases in the release PEPs themselves? Larry sent a good
summary to python-committers for 3.5 a while back, but they'd be
easier to find in the PEPs, and it would also make it clear which
aspects a new RM was keeping, and which they wanted to try doing
differently.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From stephen at xemacs.org  Tue Jul 14 09:19:24 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 14 Jul 2015 16:19:24 +0900
Subject: [Python-Dev] Freeze exception for
 http://bugs.python.org/issue23661 ?
In-Reply-To: <CADiSq7eovzq6F2bXNX0h_Y5oCKcQhtXzDcMQYi20WZwyUY4CZA@mail.gmail.com>
References: <CAJ3HoZ2BY30QMTvoQ2HWg17Lt+kXWmAHr_xh5sOLydU97CUyig@mail.gmail.com>
 <20150714022509.307CAB140A2@webabinitio.net>
 <CAJ3HoZ3uEGT67EYDqxmMKgePjnRFHZtHg03pMhRXbV957Gmm2A@mail.gmail.com>
 <CADiSq7eovzq6F2bXNX0h_Y5oCKcQhtXzDcMQYi20WZwyUY4CZA@mail.gmail.com>
Message-ID: <87d1zvfbpf.fsf@uwakimon.sk.tsukuba.ac.jp>

Nick Coghlan writes:

 > I wonder: should we start putting some of these process details for
 > the different phases in the release PEPs themselves? Larry sent a good
 > summary to python-committers for 3.5 a while back, but they'd be
 > easier to find in the PEPs, and it would also make it clear which
 > aspects a new RM was keeping, and which they wanted to try doing
 > differently.

It may be overkill, but my take would be a BCP PEP that summarizes
consensus best practice as well as option rules for releases, and then
each release would have its own PEP briefly describing any deviations
from the BCP, including both "I use variant A" and "I'm experimenting
with practice Alpha".  The former should be explained in the BCP, the
rationale for the latter in the release PEP.


From ncoghlan at gmail.com  Tue Jul 14 12:53:50 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 14 Jul 2015 20:53:50 +1000
Subject: [Python-Dev] Freeze exception for
 http://bugs.python.org/issue23661 ?
In-Reply-To: <87d1zvfbpf.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAJ3HoZ2BY30QMTvoQ2HWg17Lt+kXWmAHr_xh5sOLydU97CUyig@mail.gmail.com>
 <20150714022509.307CAB140A2@webabinitio.net>
 <CAJ3HoZ3uEGT67EYDqxmMKgePjnRFHZtHg03pMhRXbV957Gmm2A@mail.gmail.com>
 <CADiSq7eovzq6F2bXNX0h_Y5oCKcQhtXzDcMQYi20WZwyUY4CZA@mail.gmail.com>
 <87d1zvfbpf.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CADiSq7cYN-EKrbnB8RPUT0g72w4gv3bHUMs1CG62=mmFq-aGwQ@mail.gmail.com>

On 14 July 2015 at 17:19, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Nick Coghlan writes:
>
>  > I wonder: should we start putting some of these process details for
>  > the different phases in the release PEPs themselves? Larry sent a good
>  > summary to python-committers for 3.5 a while back, but they'd be
>  > easier to find in the PEPs, and it would also make it clear which
>  > aspects a new RM was keeping, and which they wanted to try doing
>  > differently.
>
> It may be overkill, but my take would be a BCP PEP that summarizes
> consensus best practice as well as option rules for releases, and then
> each release would have its own PEP briefly describing any deviations
> from the BCP, including both "I use variant A" and "I'm experimenting
> with practice Alpha".  The former should be explained in the BCP, the
> rationale for the latter in the release PEP.

That would be the developer's guide, rather than a new PEP:
https://docs.python.org/devguide/devcycle.html

Unfortunately, I forgot that page existed earlier that, otherwise I
would have linked to it in my original reply.

Assuming the release managers agree explicitly referencing those
definitions from the release PEPs would be a good idea, I figure the
actual formatting of the additions would be their call.

As an example though, given Larry's approach of calling out his
experiments as Sphinx notes, it would likely be sufficient to just say
"See the `development lifecycle guide
<https://docs.python.org/devguide/devcycle.html#stages>`__ for
committer expectations during the different development stages".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From dimaqq at gmail.com  Tue Jul 14 14:06:14 2015
From: dimaqq at gmail.com (Dima Tisnek)
Date: Tue, 14 Jul 2015 14:06:14 +0200
Subject: [Python-Dev] How far to go with user-friendliness
Message-ID: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>

https://bugs.python.org/issue21238 introduces detection of
missing/misspelt mock.assert_xxx() calls on getattr level in Python
3.5

Michael and Kushal are of the opinion that "assret" is a common typo
of "assert" and should be supported in a sense that it also triggers
AttributeError and is not silently ignored like a mocked user
attribute.

I disagree

Google search for "assret" site:github.com yields 9 hits in total, of which:
1 (cliques.c) is a variable with intended spelling;
1 issue with a warning about the variable above
1 typo in a readme file
2 comments
1 email address
3 references to this very Python change

Thus the question, how far should Python go to detect possible
erroneous user behaviour?

Granted it is in tests only, but why not detect assrte, sasert, saster
and assrat?

Shouldn't linters and IDEs take care of this anyway?

d.

From ncoghlan at gmail.com  Tue Jul 14 14:39:20 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 14 Jul 2015 22:39:20 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
Message-ID: <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>

On 14 July 2015 at 22:06, Dima Tisnek <dimaqq at gmail.com> wrote:
> Thus the question, how far should Python go to detect possible
> erroneous user behaviour?
>
> Granted it is in tests only, but why not detect assrte, sasert, saster
> and assrat?

Because "r" and "e" are right next to each other on a QWERTY keyboard
(so it's an easy typo to make), and transposing them doesn't change
the overall shape of the word (so it's a hard typo to detect).

If you get the "a" or "t" out of position you change the shape of the
word so typos involving those are easier to detect visually, while "s"
and "e" are on different keyboard rows so typos at that point in the
word are less likely in the first place.

Drawing the line at only rejecting "assert_" *would* have been a
reasonable alternative design choice, but it isn't the one Kushal and
Michael made, and there isn't a compelling argument in favour of
changing the implementation of the new guard to allow the typo'ed
prefix.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From python-dev at masklinn.net  Tue Jul 14 14:53:40 2015
From: python-dev at masklinn.net (Xavier Morel)
Date: Tue, 14 Jul 2015 14:53:40 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
Message-ID: <B4CA2470-8947-4F7E-9294-8E36425E3C9B@masklinn.net>


On 2015-07-14, at 14:39 , Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 14 July 2015 at 22:06, Dima Tisnek <dimaqq at gmail.com> wrote:
>> Thus the question, how far should Python go to detect possible
>> erroneous user behaviour?
>> 
>> Granted it is in tests only, but why not detect assrte, sasert, saster
>> and assrat?
> 
> Because "r" and "e" are right next to each other on a QWERTY keyboard
> (so it's an easy typo to make), and transposing them doesn't change
> the overall shape of the word (so it's a hard typo to detect).

> If you get the "a" or "t" out of position you change the shape of the
> word so typos involving those are easier to detect visually, while "s"
> and "e" are on different keyboard rows so typos at that point in the
> word are less likely in the first place.

"sasert" fits these rules though.


From ncoghlan at gmail.com  Tue Jul 14 15:09:50 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 14 Jul 2015 23:09:50 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <B4CA2470-8947-4F7E-9294-8E36425E3C9B@masklinn.net>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
 <B4CA2470-8947-4F7E-9294-8E36425E3C9B@masklinn.net>
Message-ID: <CADiSq7fdi7-KOhnA920=sqjNU+3jWgJHuZCoN6ZtFyUzGj3SdQ@mail.gmail.com>

On 14 July 2015 at 22:53, Xavier Morel <python-dev at masklinn.net> wrote:
>
> On 2015-07-14, at 14:39 , Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 14 July 2015 at 22:06, Dima Tisnek <dimaqq at gmail.com> wrote:
>>> Thus the question, how far should Python go to detect possible
>>> erroneous user behaviour?
>>>
>>> Granted it is in tests only, but why not detect assrte, sasert, saster
>>> and assrat?
>>
>> Because "r" and "e" are right next to each other on a QWERTY keyboard
>> (so it's an easy typo to make), and transposing them doesn't change
>> the overall shape of the word (so it's a hard typo to detect).
>
>> If you get the "a" or "t" out of position you change the shape of the
>> word so typos involving those are easier to detect visually, while "s"
>> and "e" are on different keyboard rows so typos at that point in the
>> word are less likely in the first place.
>
> "sasert" fits these rules though.

That changes one of the end letters, and human word recognition is
generally pretty good at picking up changes to the first and last
letter. It's the ones in the middle that can be a problem, especially
when they're all the same height like "sser". And that's with typical
word recognition capabilities - my understanding is that for folks
that actually have dyslexia, discrepancies in letter order are even
harder to detect.

Dima's right that the main defence against this kind of error is
actually linters and IDEs, but detecting this particular one at
runtime is harmless, so there's no particular reason *not* to do it
when it's possible to construct a reasonable rationale for "Why this
particular typo?" and not all the other possible ways of transposing
adjacent letters in "assert".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From steve at pearwood.info  Tue Jul 14 15:41:56 2015
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 14 Jul 2015 23:41:56 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
Message-ID: <20150714134156.GB21874@ando.pearwood.info>

On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
> https://bugs.python.org/issue21238 introduces detection of
> missing/misspelt mock.assert_xxx() calls on getattr level in Python
> 3.5
> 
> Michael and Kushal are of the opinion that "assret" is a common typo
> of "assert" and should be supported in a sense that it also triggers
> AttributeError and is not silently ignored like a mocked user
> attribute.
> 
> I disagree

I must admit I don't use mock so don't quite understand what is going on 
in this bug report. But I don't imagine that anything good will come out 
of treating *one* typo differently from all the other possible typos. 
Why should "assret" be treated differently from other easy-to-make typos 
like "asert", "assrt", "asset"? Or "assort", which is not only a 
standard and common English word, but "e" and "o" are right next to each 
other on Dvorak keyboards, making it an easy typo to make.

Surely this is an obvious case where the Zen should apply. "Special 
cases aren't special enough..." -- either all such typos raise 
AttributeError, or they are all silent.


-- 
Steve

From python at mrabarnett.plus.com  Tue Jul 14 15:43:14 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 14 Jul 2015 14:43:14 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7fdi7-KOhnA920=sqjNU+3jWgJHuZCoN6ZtFyUzGj3SdQ@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
 <B4CA2470-8947-4F7E-9294-8E36425E3C9B@masklinn.net>
 <CADiSq7fdi7-KOhnA920=sqjNU+3jWgJHuZCoN6ZtFyUzGj3SdQ@mail.gmail.com>
Message-ID: <55A511F2.1060908@mrabarnett.plus.com>

On 2015-07-14 14:09, Nick Coghlan wrote:
> On 14 July 2015 at 22:53, Xavier Morel <python-dev at masklinn.net> wrote:
>>
>> On 2015-07-14, at 14:39 , Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 14 July 2015 at 22:06, Dima Tisnek <dimaqq at gmail.com> wrote:
>>>> Thus the question, how far should Python go to detect possible
>>>> erroneous user behaviour?
>>>>
>>>> Granted it is in tests only, but why not detect assrte, sasert, saster
>>>> and assrat?
>>>
>>> Because "r" and "e" are right next to each other on a QWERTY keyboard
>>> (so it's an easy typo to make), and transposing them doesn't change
>>> the overall shape of the word (so it's a hard typo to detect).
>>
>>> If you get the "a" or "t" out of position you change the shape of the
>>> word so typos involving those are easier to detect visually, while "s"
>>> and "e" are on different keyboard rows so typos at that point in the
>>> word are less likely in the first place.
>>
>> "sasert" fits these rules though.
>
> That changes one of the end letters, and human word recognition is
> generally pretty good at picking up changes to the first and last
> letter. It's the ones in the middle that can be a problem, especially
> when they're all the same height like "sser". And that's with typical
> word recognition capabilities - my understanding is that for folks
> that actually have dyslexia, discrepancies in letter order are even
> harder to detect.
>
> Dima's right that the main defence against this kind of error is
> actually linters and IDEs, but detecting this particular one at
> runtime is harmless, so there's no particular reason *not* to do it
> when it's possible to construct a reasonable rationale for "Why this
> particular typo?" and not all the other possible ways of transposing
> adjacent letters in "assert".
>
What about "aasert"?


From barry at python.org  Tue Jul 14 15:47:03 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 14 Jul 2015 09:47:03 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
Message-ID: <20150714094703.43e79b61@limelight.wooz.org>

On Jul 14, 2015, at 02:06 PM, Dima Tisnek wrote:

>Michael and Kushal are of the opinion that "assret" is a common typo
>of "assert" and should be supported in a sense that it also triggers
>AttributeError and is not silently ignored like a mocked user
>attribute.

It's seems like a dubious special case.

Cheers,
-Barry

From me at the-compiler.org  Tue Jul 14 15:51:42 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 14 Jul 2015 15:51:42 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150714134156.GB21874@ando.pearwood.info>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
Message-ID: <20150714135142.GW32275@tonks>

* Steven D'Aprano <steve at pearwood.info> [2015-07-14 23:41:56 +1000]:
> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
> > https://bugs.python.org/issue21238 introduces detection of
> > missing/misspelt mock.assert_xxx() calls on getattr level in Python
> > 3.5
> > 
> > Michael and Kushal are of the opinion that "assret" is a common typo
> > of "assert" and should be supported in a sense that it also triggers
> > AttributeError and is not silently ignored like a mocked user
> > attribute.
> > 
> > I disagree
> 
> I must admit I don't use mock so don't quite understand what is going on 
> in this bug report.

Without using spec/autospec, a mock (by design) supports calling any
method on itself, which returns another mock:

    >>> m = mock.Mock()
    >>> m.eggs()
    <Mock name='mock.eggs()' id='140373912833384'>
    >>> m.bacon()
    <Mock name='mock.bacon()' id='140373910240616'>

However, it also has some special methods to see if it has been
called:

    >>> m.assert_called_with()
    [...]
    AssertionError: Expected call: mock()
    Not called

Now because of that, if you do a typo, you won't notice in a test:

    >>> m.assert_caled_with()
    <Mock name='mock.assert_caled_with()' id='140373910240672'>

With the patch, an AttributeError is raised if you call something
starting with assert or assret instead.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150714/13872b7a/attachment.sig>

From rosuav at gmail.com  Tue Jul 14 15:59:42 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 14 Jul 2015 23:59:42 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150714135142.GW32275@tonks>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
Message-ID: <CAPTjJmqjgNshyaPTBRRdTb-azLCQbhcNP7y05PcWdgV5czzGYQ@mail.gmail.com>

On Tue, Jul 14, 2015 at 11:51 PM, Florian Bruhin <me at the-compiler.org> wrote:
> However, it also has some special methods to see if it has been
> called:
>
>     >>> m.assert_called_with()
>     [...]
>     AssertionError: Expected call: mock()
>     Not called

I suppose it's too late to change this so these aren't methods... ISTM
the problem is this collision of usage on attribute lookup - on the
one hand, it's conjuring mock method calls, and on the other, it's
implementing methods of its own.

ChrisA

From steve at pearwood.info  Tue Jul 14 16:00:42 2015
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 15 Jul 2015 00:00:42 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7fdi7-KOhnA920=sqjNU+3jWgJHuZCoN6ZtFyUzGj3SdQ@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
 <B4CA2470-8947-4F7E-9294-8E36425E3C9B@masklinn.net>
 <CADiSq7fdi7-KOhnA920=sqjNU+3jWgJHuZCoN6ZtFyUzGj3SdQ@mail.gmail.com>
Message-ID: <20150714140042.GC21874@ando.pearwood.info>

On Tue, Jul 14, 2015 at 11:09:50PM +1000, Nick Coghlan wrote:

> Dima's right that the main defence against this kind of error is
> actually linters and IDEs, but detecting this particular one at
> runtime is harmless, so there's no particular reason *not* to do it
> when it's possible to construct a reasonable rationale for "Why this
> particular typo?" and not all the other possible ways of transposing
> adjacent letters in "assert".

I've read this thread and the bug report and I'm not sure about this 
reasonable rationale. It seems like an utterly arbitrary choice to 
single out a single typo for special treatment while ignoring other 
equivalent typos, equally easy to make and equally difficult to spot. 
You even mentioned people with dyslexia yourself. As I understand it, 
dyslexics would find assert and assery equally hard to distinguish as 
assret versus assert, and t and y are next to each other on the same row 
of QWERTY keyboards.

BTW, am I missing something? The issue tracker says that the patch was 
accepted and a new "unsafe" keyword argument was added over a year ago, 
but that doesn't seem to be documented anywhere here:

https://docs.python.org/3/library/unittest.mock.html


-- 
Steve

From p.f.moore at gmail.com  Tue Jul 14 16:06:17 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 14 Jul 2015 15:06:17 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150714135142.GW32275@tonks>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
Message-ID: <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>

On 14 July 2015 at 14:51, Florian Bruhin <me at the-compiler.org> wrote:
> * Steven D'Aprano <steve at pearwood.info> [2015-07-14 23:41:56 +1000]:
>> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
>> > https://bugs.python.org/issue21238 introduces detection of
>> > missing/misspelt mock.assert_xxx() calls on getattr level in Python
>> > 3.5
>> >
>> > Michael and Kushal are of the opinion that "assret" is a common typo
>> > of "assert" and should be supported in a sense that it also triggers
>> > AttributeError and is not silently ignored like a mocked user
>> > attribute.
>> >
>> > I disagree
>>
>> I must admit I don't use mock so don't quite understand what is going on
>> in this bug report.
>
> Without using spec/autospec, a mock (by design) supports calling any
> method on itself, which returns another mock:
>
>     >>> m = mock.Mock()
>     >>> m.eggs()
>     <Mock name='mock.eggs()' id='140373912833384'>
>     >>> m.bacon()
>     <Mock name='mock.bacon()' id='140373910240616'>
>
> However, it also has some special methods to see if it has been
> called:
>
>     >>> m.assert_called_with()
>     [...]
>     AssertionError: Expected call: mock()
>     Not called
>
> Now because of that, if you do a typo, you won't notice in a test:
>
>     >>> m.assert_caled_with()
>     <Mock name='mock.assert_caled_with()' id='140373910240672'>
>
> With the patch, an AttributeError is raised if you call something
> starting with assert or assret instead.

In retrospect, this seems like a mistake in the design. Much like
namedtuple, mocks should carefully separate "actual" methods from
mocked ones (in the case of namedtuple, from tuple element names). If
Guido would let us use the time machine, I'd argue that maybe the
special methods should be _assert_called_with (or something similar).

Given that it's way too late to take that path, I can see the value of
trying to detect common errors. Particularly as the result of failing
to do so is an apparently-passing test.

In effect, this patch is "reserving" all attributes starting with
"assert" or "assret" as actual methods of the mock object, and not
mocked attributes.

Reserving "assert" seems fair.
Reserving "assret" seems odd, as people say why just this
mis-spelling? Is there any specific evidence that this typo happens
more often "in the wild" than any other? Given that the original issue
was raised by Michael Foord (the author of mock), I'd be inclined to
assume that he'd encountered evidence to that effect.

So ultimately I'm +1 on reserving "assert" (given that a more radical
fix isn't possible) and +0 on adding "assret" (simply on the basis
that someone more knowledgeable than me says it makes sense).

Paul

From berker.peksag at gmail.com  Tue Jul 14 17:06:32 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Tue, 14 Jul 2015 18:06:32 +0300
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150714140042.GC21874@ando.pearwood.info>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
 <B4CA2470-8947-4F7E-9294-8E36425E3C9B@masklinn.net>
 <CADiSq7fdi7-KOhnA920=sqjNU+3jWgJHuZCoN6ZtFyUzGj3SdQ@mail.gmail.com>
 <20150714140042.GC21874@ando.pearwood.info>
Message-ID: <CAF4280KdUZ1OKVoHrkf28VGu7yriypuxx1+SF4datgF9UgEeNQ@mail.gmail.com>

On Tue, Jul 14, 2015 at 5:00 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, Jul 14, 2015 at 11:09:50PM +1000, Nick Coghlan wrote:
>
>> Dima's right that the main defence against this kind of error is
>> actually linters and IDEs, but detecting this particular one at
>> runtime is harmless, so there's no particular reason *not* to do it
>> when it's possible to construct a reasonable rationale for "Why this
>> particular typo?" and not all the other possible ways of transposing
>> adjacent letters in "assert".
>
> I've read this thread and the bug report and I'm not sure about this
> reasonable rationale. It seems like an utterly arbitrary choice to
> single out a single typo for special treatment while ignoring other
> equivalent typos, equally easy to make and equally difficult to spot.
> You even mentioned people with dyslexia yourself. As I understand it,
> dyslexics would find assert and assery equally hard to distinguish as
> assret versus assert, and t and y are next to each other on the same row
> of QWERTY keyboards.
>
> BTW, am I missing something? The issue tracker says that the patch was
> accepted and a new "unsafe" keyword argument was added over a year ago,
> but that doesn't seem to be documented anywhere here:
>
> https://docs.python.org/3/library/unittest.mock.html

It's new in Python 3.5:
https://docs.python.org/3.5/library/unittest.mock.html#unittest.mock.Mock

"unsafe: By default if any attribute starts with assert or assret will
raise an AttributeError. Passing unsafe=True will allow access to
these attributes."

--Berker

From senthil at uthcode.com  Tue Jul 14 17:17:42 2015
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 14 Jul 2015 08:17:42 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
Message-ID: <CAPOVWOSDHtsVhAM4dJ2n1G80DD4Au9tLZdKWN=KmrLkq6EO5_A@mail.gmail.com>

On Tue, Jul 14, 2015 at 5:06 AM, Dima Tisnek <dimaqq at gmail.com> wrote:

> https://bugs.python.org/issue21238 introduces detection of
> missing/misspelt mock.assert_xxx() calls on getattr level in Python
> 3.5


It was controversial when it got committed too. Discussions happened in
python-committers and IRC.
Michael is the BDFL of mock and felt alright with the change.

The sad part is once introduced and released, deprecation takes more time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150714/44af2bc2/attachment.html>

From ron3200 at gmail.com  Tue Jul 14 18:15:51 2015
From: ron3200 at gmail.com (Ron Adam)
Date: Tue, 14 Jul 2015 12:15:51 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150714134156.GB21874@ando.pearwood.info>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
Message-ID: <mo3cjo$1eg$1@ger.gmane.org>



On 07/14/2015 09:41 AM, Steven D'Aprano wrote:
> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
>> >https://bugs.python.org/issue21238  introduces detection of
>> >missing/misspelt mock.assert_xxx() calls on getattr level in Python
>> >3.5
>> >
>> >Michael and Kushal are of the opinion that "assret" is a common typo
>> >of "assert" and should be supported in a sense that it also triggers
>> >AttributeError and is not silently ignored like a mocked user
>> >attribute.
>> >
>> >I disagree
> I must admit I don't use mock so don't quite understand what is going on
> in this bug report. But I don't imagine that anything good will come out
> of treating*one*  typo differently from all the other possible typos.
> Why should "assret" be treated differently from other easy-to-make typos
> like "asert", "assrt", "asset"? Or "assort", which is not only a
> standard and common English word, but "e" and "o" are right next to each
> other on Dvorak keyboards, making it an easy typo to make.
>
> Surely this is an obvious case where the Zen should apply. "Special
> cases aren't special enough..." -- either all such typos raise
> AttributeError, or they are all silent.

I agree with Steven that it doesn't seem correct to not raise 
AttributeError here.

For what it's worth, I have a life long sleep disorder and am a tarrable 
(<-- like this)  speller because of it.   I still don't want spell, or 
grammar, checkers to not report my mistakes.  And I don't recall ever 
making the particular error of using "assret" in place of "assert".  I'd be 
more likely to mispell it as "assirt" if I wasn't already so familiar with 
"assert".

If people do misspell it, I think they do learn not to in after it happens 
a few times.

Regards,
    Ron


From bobcatfish at gmail.com  Tue Jul 14 18:36:53 2015
From: bobcatfish at gmail.com (Christie Wilson)
Date: Tue, 14 Jul 2015 09:36:53 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <mo3cjo$1eg$1@ger.gmane.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
Message-ID: <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>

>
> If people do misspell it, I think they do learn not to in after it happens
> a few times.


Unless the line silently executes and they don't notice the mistake for
years :'(

On Tue, Jul 14, 2015 at 9:15 AM, Ron Adam <ron3200 at gmail.com> wrote:

>
>
> On 07/14/2015 09:41 AM, Steven D'Aprano wrote:
>
>> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
>>
>>> >https://bugs.python.org/issue21238  introduces detection of
>>> >missing/misspelt mock.assert_xxx() calls on getattr level in Python
>>> >3.5
>>> >
>>> >Michael and Kushal are of the opinion that "assret" is a common typo
>>> >of "assert" and should be supported in a sense that it also triggers
>>> >AttributeError and is not silently ignored like a mocked user
>>> >attribute.
>>> >
>>> >I disagree
>>>
>> I must admit I don't use mock so don't quite understand what is going on
>> in this bug report. But I don't imagine that anything good will come out
>> of treating*one*  typo differently from all the other possible typos.
>> Why should "assret" be treated differently from other easy-to-make typos
>> like "asert", "assrt", "asset"? Or "assort", which is not only a
>> standard and common English word, but "e" and "o" are right next to each
>> other on Dvorak keyboards, making it an easy typo to make.
>>
>> Surely this is an obvious case where the Zen should apply. "Special
>> cases aren't special enough..." -- either all such typos raise
>> AttributeError, or they are all silent.
>>
>
> I agree with Steven that it doesn't seem correct to not raise
> AttributeError here.
>
> For what it's worth, I have a life long sleep disorder and am a tarrable
> (<-- like this)  speller because of it.   I still don't want spell, or
> grammar, checkers to not report my mistakes.  And I don't recall ever
> making the particular error of using "assret" in place of "assert".  I'd be
> more likely to mispell it as "assirt" if I wasn't already so familiar with
> "assert".
>
> If people do misspell it, I think they do learn not to in after it happens
> a few times.
>
> Regards,
>    Ron
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com
>



-- 
Christie Wilson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150714/8a310026/attachment.html>

From ethan at stoneleaf.us  Tue Jul 14 18:53:33 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 14 Jul 2015 09:53:33 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
Message-ID: <55A53E8D.5090009@stoneleaf.us>

On 07/14/2015 07:06 AM, Paul Moore wrote:
> On 14 July 2015 at 14:51, Florian Bruhin wrote:
>>> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:

>>>> https://bugs.python.org/issue21238 introduces detection of
>>>> missing/misspelt mock.assert_xxx() calls on getattr level in Python
>>>> 3.5
>>>>
>>>> Michael and Kushal are of the opinion that "assret" is a common typo
>>>> of "assert" and should be supported in a sense that it also triggers
>>>> AttributeError and is not silently ignored like a mocked user
>>>> attribute.

This is ridiculous.

>> With the patch, an AttributeError is raised if you call something
>> starting with assert or assret instead.

> In effect, this patch is "reserving" all attributes starting with
> "assert" or "assret" as actual methods of the mock object, and not
> mocked attributes.
>
> Reserving "assert" seems fair.

Agreed.

> Reserving "assret" seems odd, as people say why just this
> mis-spelling?

Refuse the temptation to guess.  Imagine that English is not the only language people use, and assret is either an actual word or logical abbreviation in some other language -- we just broke their tests.

Part of writing tests is making sure they fail (and for the right reason) -- proper testing of the tests would reveal such a typo.

--
~Ethan~

From ron3200 at gmail.com  Tue Jul 14 19:12:34 2015
From: ron3200 at gmail.com (Ron Adam)
Date: Tue, 14 Jul 2015 13:12:34 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
Message-ID: <mo3fu3$q8m$1@ger.gmane.org>



On 07/14/2015 12:36 PM, Christie Wilson wrote:
>     If people do misspell it, I think they do learn not to after it
>     happens a few times.
>
>
> Unless the line silently executes and they don't notice the mistake for
> years :'(

Yes, and I'm concerned that allowing it in one location may bring about a 
self fulfilling cause.  ie.. it will become a common error if it works in 
some places, but not others, while it's really not that common at the 
present time.

On the plus side.. having it in only one module, and only one place, 
probably won't be "that" bad or even that noticeable.  But maybe it can be 
a motivating factor for not doing similar things in other places.

Cheers,
    Ron


From andrew3 at r3dsolutions.com  Tue Jul 14 12:22:05 2015
From: andrew3 at r3dsolutions.com (Andrew Robinson)
Date: Tue, 14 Jul 2015 10:22:05 +0000
Subject: [Python-Dev] Cross compiling C-python 2.7.10 maintenance release
 for ARM on 64 bit x86_64 systems.
Message-ID: <55A4E2CD.2070704@r3dsolutions.com>

Hi.

I'm trying to cross compile C-python 2.7.10 for an embedded system. (Eg: 
a Kobo reader).
But there appears to be some bugs that do not allow the latest 
maintenance release of Python to correctly cross compile on an x86-64 
build system, for a 32 bit arm system.

I have researched the problem, and there are apparently two different bugs;
1'st -- the Makefile doesn't disable PYTHONPATH for the arm libraries, 
and the x86 64 bit platform will attempt to link to the arm libraries 
during the compile process producing an wrong elf class error.

I found some online examples of cross compiling older versions of python 
which suggest adding a '-' before "PYTHONPATH' to prevent that from 
happening.  When I do that, it does compile -- but:

2'nd -- If I build python 2.7.10 with the above change, and with no 
debugging information or switches; it builds fine, but the resulting 
binary segfaults randomly on the Kobo reader, and will not import 
libraries without segfaulting.

If I build it with all available debugging information (-g3 -ggdb 
-gdwarf 4), the random segfaulting stops -- and instead, python raises 
an exception any time I attempt to import a library.

-----------------------------------------------------------------------
Python 2.7.10 (default, Jun 29 2015, 23:00:31)
[GCC 4.8.1 20130401 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import math
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ImportError: /mnt/user/lib/python2.7/lib-dynload/math.so: undefined 
symbol: Py_InitModule4
[40857 refs]
 >>>
-------------------------------------------------------------------------

The symbol is indeed missing when I check with nm, and from what little 
information I can find online -- this appears to have something to do 
with a 32 bit vs. 64 bit incompatibility; eg: even though it's compiling 
for 32 bits ARM -- it still seems to be trying to use symbols associated 
with 64 bit processing.

I attempted to compile a 32 bit python interpreter on the build system, 
to make PYTHON_FOR_BUILD, and PGEN_FOR_BUILD ; but it didn't rectify the 
problem.

What is the proper way to cross compile 2.7.10 for 32 bit arm, on a 
x86_64 bit platform  / what am I doing wrong ?

-------------------------------------------------------------------------------------- 

Supplimentary information:

I'm using the linaro-gcc compiler from the kobolabs git repository, () 
eg: an arm-linux-gnueabihf-gcc on a 64 bit Slackware 14.1 machine with 
multilib x86 gcc available on the build system.

I have a separate 8GB partition with the Kobo kernel source code, 
stdlibs, etc. all installed from the github source and compiled to a 
target directory stored in an environment variable called ${DEVICEROOT} 
; All files found on the KOBO reader are located under ${DEVICEROOT} on 
the BUILD machine, and the arm GCC processor uses -I 
${DEVICEROOT}/usr/include and other appropriate paths so that GCC finds 
them naturally.

The following bash script shows the steps I used to compile Python with 
-- and it is followed by another bash script which sets up the compile 
environment variables, so you can see how the compiler environment is 
configured.

I have no problem compiling C source code in general using the Kobo 
compiler tools, and have compiled gnuplot, and bash, and several other 
packages with absolutely no problems.  It is only python which is not 
compiling correctly.

---------------------------------------------------------------------------------------------------------------------------------------------- 


set -x

# A parser generator and build system version of python are supposed to be
# needed to run parts of the cross compilation;  I do see python used in 
the
# Makefile, but no references to a buid version of PGEN are defined,
# so I don't know if PGEN gets used or not -- but I build it anyway...
# As this is what receipies on the web say to do...

make distclean
(
. /etc/profile.d/32dev.sh
export LIBDIRSUFFIX=""
./configure # --build=x86_64-unknown-linux-gnu 
--host=i486-unknown-linux-gnu #(uncomment to build 32bit)

make Parser/pgen python
mv python python_for_build
mv Parser/pgen Parser/pgen_for_build
make distclean
)

# fix setup.py to handle installing to the target system's fake install
# directory found on the build system at $DEVICEROOT.

# We want utf-8, unicode terminal handling -- so make sure python compiles
# with ncursesw substituted for curses.

CURSESFLAGS=`pkg-config --cflags ncursesw`

# Configure python to be built
CFLAGS="${CFLAGS} ${CURSESFLAGS} -g3 -ggdb -gdwarf-4" ./configure 
--host=${CROSSTARGET} --build=i486-unknown-linux-gnu --enable-unicode 
--enable-shared --with-pydebug --prefix=/mnt/user --disable-ipv6 
--without-pymalloc ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no 
ac_cv_have_long_long_format=yes PYTHON_FOR_BUILD=${PWD}/python_for_build 
PGEN_FOR_BUILD=${PWD}/Parser/pgen_for_build

# Fix a bug in the Makefile
# The build version of python, ought not try to actually use the ARM 
libraries.
sed -i -e 's%\([[:space:]]\)\(PYTHONPATH=$(DESTDIR)$(LIBDEST)\)%\1-\2%' 
Makefile
echo "background the process now to Fix the makefile manually if you can"
sleep 10

make PYTHON_FOR_BUILD=${PWD}/python_for_build CROSS_COMPILE_TARGET=yes

echo " Waiting to allow you to see error messages before installing "
sleep 10

# Optionally, binary file stripping could be carried out on the python 
binary
# Don't strip if you are doing debugging of python
# strip --strip-unneeded python

make install DESTDIR=${DEVICEROOT} 
PYTHON_FOR_BUILD=${PWD}/python_for_build 
PGEN_FOR_BUILD=${PWD}/Parser/pgen_for_build

---------------------------------------------------------------------------------------------------------------- 


###### A bash file used to set up gcc paths for cross compiling on the 
kobo follows a (-----).
# There are two compilers in the KOBO git repository:
# https://github.com/kobolabs/Kobo-Reader/tree/master/toolchain

# a linaro-gcc, and code-sourcery-gcc.   The code sourcery gcc does not 
have the standard C libraries and
# perhaps does not use hardware floats, or have those startup files, and 
is strictly for compiling the linux kernel.
# Only the linaro compiler is needed to compile Python.
# The linaro compiler is invoked by using ${CROSSTARGET} as a prefix, 
while the kernel compiler is invoked
# using ${CROSS_COMPILE}
# eg: use arm-linux-gnueabihf-gcc for linaro  vs. 
arm-none-linux-gnueabi-gcc for code sourcercy (kernel compiler).
#
# All tools are installed on a partition or thumb drive, with the 
following bash script located at THUMBDRIVEPATH/.local/bin and the path 
added to my user PATH.
# The script will auto locate the gcc tools relative to its' own install 
directory, so THUMBDRIVE path can be changed without needing to 
re-editing the script.
# I installed the linaro compiler, path relative, at:
# 
THUMBDRIVEPATH/.local/gcc-linaro-arm-linux-gnueabihg-4.8-2013.04-20130417_linux/ 
... etc.

---------------------------------------------------------------------------------------------------------------- 


#!/bin/bash --init-file
# this file is: use_kobo
echo "Starting subshell with KOBO/ARM linaro gcc and Sourcery_G++_Lite 
in the path"

set -e
path=`whereis -b use_kobo`
name="${path%%:*}"
path="${path##* /}"
path="/${path%%/${name}}"

export SOURCERYDIR=${path}/../CodeSourcery/Sourcery_G++_Lite
export 
LINARODIR=${path}/../gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux
echo "Adding CodeSourcery eabi and linaro eabihf compiler suites to the 
path"
export PATH=${SOURCERYDIR}/bin:${LINARODIR}/bin:${PATH}

export KOBOLABS=${path}/../../KoboLabs

export DEVICEROOT=${KOBOLABS}/deviceroot
#export CROSSTARGET="arm-none-linux-gnueabi"
export CROSSTARGET="arm-linux-gnueabihf"

# Build the linux kernel with these variables
export CROSS_COMPILE="arm-none-linux-gnueabi-"
export ARCH="arm"

# Clean out system shell varaibles that can affect program compilation

unset CC
unset CFLAGS
unset LDFLAGS
unset CPPFLAGS
unset CPP
unset CXX
unset CXXFLAGS
unset CXXCPP
unset C_INCLUDE_PATH
unset CPLUS_INCLUDE_PATH
unset QT4DIR
unset OBJC_INCLUDE_PATH
unset PKG_CONFIG_PATH
unset PKG_CONFIG_LIBDIR
unset PKG_CONFIG_SYSROOT_DIR

mkdir -p /tmp/kobo-gcc-cross
export TMPDIR=/tmp/kobo-gcc-cross
export CPATH=${DEVICEROOT}/usr/include:${DEVICEROOT}/mnt/user/include
export 
LIBRARY_PATH="${DEVICEROOT}/lib:${DEVICEROOT}/usr/lib":${DEVICEROOT}/mnt/user/lib
export LDFLAGS="-L${DEVICEROOT}/lib -L${DEVICEROOT}/usr/lib 
-L${DEVICEROOT}/mnt/user/lib"
# Set up PKGCONFIG to prefer programs that were compiled later, over 
earlier.
export 
PKG_CONFIG_PATH="${DEVICEROOT}/mnt/user/lib/pkgconfig:${DEVICEROOT}/usr/lib/pkgconfig:${DEVICEROOT}/lib/pkgconfig"
export PKG_CONFIG_LIBDIR="${PKG_CONFIG_PATH}"
export PKG_CONFIG_SYSROOT_DIR="${DEVICEROOT}"

cleanup() {
echo -e '\033]2;Unknown xterm\007'

trap EXIT
exit $1 $2 $3 $4
}
trap cleanup EXIT

echo -e '\033]2;ARM Sourcery_G++_Lite & linaro-gcc for KOBO shell\007'
set +e
set -o vi

From rdmurray at bitdance.com  Tue Jul 14 19:35:47 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 14 Jul 2015 13:35:47 -0400
Subject: [Python-Dev] Cross compiling C-python 2.7.10 maintenance
	release for ARM on 64 bit x86_64 systems.
In-Reply-To: <55A4E2CD.2070704@r3dsolutions.com>
References: <55A4E2CD.2070704@r3dsolutions.com>
Message-ID: <20150714173548.801E0B14089@webabinitio.net>

On Tue, 14 Jul 2015 10:22:05 -0000, Andrew Robinson <andrew3 at r3dsolutions.com> wrote:
> I'm trying to cross compile C-python 2.7.10 for an embedded system. (Eg: 
> a Kobo reader).
> But there appears to be some bugs that do not allow the latest 
> maintenance release of Python to correctly cross compile on an x86-64 
> build system, for a 32 bit arm system.

To my understanding we don't yet fully support this (though we'd like
to), because we don't have a buildbot that regularly does cross compiles.
There are open issues in the tracker, perhaps you can vet and/or submit
some patches.[*]  Or contribute a buildbot?

--David

[8} See eg http://bugs.python.org/issue5404; I'm guessing there are others.

From tjreedy at udel.edu  Tue Jul 14 20:11:37 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 14 Jul 2015 14:11:37 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
Message-ID: <mo3jd8$l50$1@ger.gmane.org>

On 7/14/2015 8:39 AM, Nick Coghlan wrote:
> On 14 July 2015 at 22:06, Dima Tisnek <dimaqq at gmail.com> wrote:
>> Thus the question, how far should Python go to detect possible
>> erroneous user behaviour?
>>
>> Granted it is in tests only, but why not detect assrte, sasert, saster
>> and assrat?

> Drawing the line at only rejecting "assert_" *would* have been a
> reasonable alternative design choice, but it isn't the one Kushal and
> Michael made, and there isn't a compelling argument in favour of
> changing the implementation of the new guard to allow the typo'ed
> prefix.

I strongly disagree that there is no compelling argument for reversal. 
Part of the reason for beta is so we have time to evaluate whether an 
enhancement is even a good idea. Many of us think special-casing 
'assret' is an awful one. This idea never got consensus or even majority 
approval.

1. It is false that 'assret' is necessarily a typo. Someone might quite 
legitimately use it as an attribute. Aside from the fact that it might 
be an *intentional* misspelling to avoid a clash with 'assert', I found 
the following on Google.
a. It appears to be both a (person) name (Turkey?) and a username.
b. It can be a contraction, abbreviation, or pair of acronym: ass-et 
ret-ention, ass-istant ret-ired (?), and something in connection with 
high-pressure oil lines.  Python usage is not restricted to 
English-speaking geeks.

2. It gives the impression that 'assret' is a legitimate alias for 
'assert'.  See 
https://stackoverflow.com/questions/31382895/any-core-real-reference-to-assret-as-alias-to-assert
This may have been what prompted Dima to go look on Google.

If the doc is revised to counter this impression, then I predict that 
this will join the list of Python warts and reasons to ridicule Python.

3. It violates Python design principles. To many, the beauty of Python 
is that it is relatively clean and simple, and not filled with hundreds 
of nitpicky exceptions and special cases.  Being BDFL for a module 
should not be a license to add junk like this.

-- 
Terry Jan Reedy


From g.brandl at gmx.net  Tue Jul 14 20:38:21 2015
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 14 Jul 2015 20:38:21 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
Message-ID: <mo3kut$brf$1@ger.gmane.org>

On 07/14/2015 02:39 PM, Nick Coghlan wrote:

> Drawing the line at only rejecting "assert_" *would* have been a
> reasonable alternative design choice, but it isn't the one Kushal and
> Michael made, and there isn't a compelling argument in favour of
> changing the implementation of the new guard to allow the typo'ed
> prefix.

I'd like to request installing "phyton" as a symlink to "python" in the
next version.

Georg


From matt.j.keeter at gmail.com  Tue Jul 14 20:28:31 2015
From: matt.j.keeter at gmail.com (Matthew Keeter)
Date: Tue, 14 Jul 2015 14:28:31 -0400
Subject: [Python-Dev] cpython: locals dictionary in PyRun_String
Message-ID: <3CCD3946-F553-4CAB-9CE9-BE6BE8A5AB9D@gmail.com>

The docs for PyRun_String say that both globals and locals should be dictionaries [1].

However, digging into the source [2] shows me that locals doesn?t need to be a dictionary;
it just needs to implement the mapping protocol.  Is it a bad idea to rely on this fact?

(Context: I?m plugging a custom object into locals that uses __getitem__ to track lookups.)

Thanks,
Matt

[1] https://docs.python.org/3.4/c-api/veryhigh.html#c.PyRun_StringFlags
[2] https://github.com/python/cpython/blob/master/Objects/frameobject.c#L628-L629
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150714/ad5f8394/attachment.html>

From brett at python.org  Tue Jul 14 20:47:45 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Jul 2015 18:47:45 +0000
Subject: [Python-Dev] cpython: locals dictionary in PyRun_String
In-Reply-To: <3CCD3946-F553-4CAB-9CE9-BE6BE8A5AB9D@gmail.com>
References: <3CCD3946-F553-4CAB-9CE9-BE6BE8A5AB9D@gmail.com>
Message-ID: <CAP1=2W5WT35xCeg38-4BMQswOZCP85B0ZqWgDqoW7EdWBZUv7w@mail.gmail.com>

On Tue, Jul 14, 2015 at 11:39 AM Matthew Keeter <matt.j.keeter at gmail.com>
wrote:

> The docs for PyRun_String say that both globals and locals should be
> dictionaries [1].
>
> However, digging into the source [2] shows me that locals doesn?t need to
> be a dictionary;
> it just needs to implement the mapping protocol.  Is it a bad idea to rely
> on this fact?
>
> (Context: I?m plugging a custom object into locals that uses __getitem__
> to track lookups.)
>

As you pointed out in the code, that's in the frame creation code and not
directly the PyRun_StringFlags code, so technically there is a chance for
us to insert a PyDict_CheckExact() call before hitting the code you linked
to.

As to whether we could loosen the documented restrictions so they are
guaranteed, it would be best to file an issue at bugs.python.org requesting
the restriction be officially loosened and if people are amenable then a
test to make sure no one accidentally breaks the API promise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150714/2bc35a6e/attachment.html>

From robertc at robertcollins.net  Tue Jul 14 21:27:14 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 15 Jul 2015 07:27:14 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
Message-ID: <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>

On 15 July 2015 at 02:06, Paul Moore <p.f.moore at gmail.com> wrote:
> On 14 July 2015 at 14:51, Florian Bruhin <me at the-compiler.org> wrote:
>> * Steven D'Aprano <steve at pearwood.info> [2015-07-14 23:41:56 +1000]:
...
>> With the patch, an AttributeError is raised if you call something
>> starting with assert or assret instead.
>
> In retrospect, this seems like a mistake in the design. Much like
> namedtuple, mocks should carefully separate "actual" methods from
> mocked ones (in the case of namedtuple, from tuple element names). If
> Guido would let us use the time machine, I'd argue that maybe the
> special methods should be _assert_called_with (or something similar).

Well.

I'd go further and just separate the APIs.

mock.assert_called_with(a_mock, *args, **kwargs)

mock can know how to poke under the covers (e.g. using
__Mock_assert_called_with) without leaking it into the users objects.

> Given that it's way too late to take that path, I can see the value of
> trying to detect common errors. Particularly as the result of failing
> to do so is an apparently-passing test.

We can add a new API and gradually deprecate the old one. With the
presence of 'mock' as a rolling backport, this can be used by folk on
Python 3.3 and 3.4 so they don't get locked into one release of Python
or another.

> In effect, this patch is "reserving" all attributes starting with
> "assert" or "assret" as actual methods of the mock object, and not
> mocked attributes.

Yes, and thats ugly. OTOH it caught hundreds of useless tests in
OpenStack when this got ported into mock 1.1.0.

> Reserving "assert" seems fair.
> Reserving "assret" seems odd, as people say why just this
> mis-spelling? Is there any specific evidence that this typo happens
> more often "in the wild" than any other? Given that the original issue
> was raised by Michael Foord (the author of mock), I'd be inclined to
> assume that he'd encountered evidence to that effect.
>
> So ultimately I'm +1 on reserving "assert" (given that a more radical
> fix isn't possible) and +0 on adding "assret" (simply on the basis
> that someone more knowledgeable than me says it makes sense).

Since assret is solely a 'you may not use this' case, I think we can
remove the check for that quite trivially, at any point we want to.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From rob.cliffe at btinternet.com  Tue Jul 14 21:26:49 2015
From: rob.cliffe at btinternet.com (Rob Cliffe)
Date: Tue, 14 Jul 2015 20:26:49 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <mo3jd8$l50$1@ger.gmane.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <CADiSq7e9vY53rAopksfoEnPQbYWzgYo4YK+f=sq5770b7i1yMw@mail.gmail.com>
 <mo3jd8$l50$1@ger.gmane.org>
Message-ID: <55A56279.2070309@btinternet.com>



On 14/07/2015 19:11, Terry Reedy wrote:
>  To many, the beauty of Python is that it is relatively clean and 
> simple, and not filled with hundreds of nitpicky exceptions and 
> special cases.  Being BDFL for a module should not be a license to add 
> junk like this.
>
+1.  Speaking as someone who has to work with a language full of 
nitpicky exceptions and special cases.  (Don't ask.)
Rob Cliffe

From p.f.moore at gmail.com  Tue Jul 14 21:39:08 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 14 Jul 2015 20:39:08 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
Message-ID: <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>

On 14 July 2015 at 20:27, Robert Collins <robertc at robertcollins.net> wrote:
> Well.
>
> I'd go further and just separate the APIs.
>
> mock.assert_called_with(a_mock, *args, **kwargs)
>
> mock can know how to poke under the covers (e.g. using
> __Mock_assert_called_with) without leaking it into the users objects.

As someone who makes limited use of mock, and therefore whose opinion
shouldn't carry too much weight, I like this option.

>> Given that it's way too late to take that path, I can see the value of
>> trying to detect common errors. Particularly as the result of failing
>> to do so is an apparently-passing test.
>
> We can add a new API and gradually deprecate the old one. With the
> presence of 'mock' as a rolling backport, this can be used by folk on
> Python 3.3 and 3.4 so they don't get locked into one release of Python
> or another.

You're right - I hadn't thought of this approach.

>> In effect, this patch is "reserving" all attributes starting with
>> "assert" or "assret" as actual methods of the mock object, and not
>> mocked attributes.
>
> Yes, and thats ugly. OTOH it caught hundreds of useless tests in
> OpenStack when this got ported into mock 1.1.0.

... which I guess counts as strong evidence that this *is* a common
typo, at least in certain contexts.

Paul

From robertc at robertcollins.net  Tue Jul 14 21:40:57 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 15 Jul 2015 07:40:57 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
Message-ID: <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>

On 15 July 2015 at 07:39, Paul Moore <p.f.moore at gmail.com> wrote:
> On 14 July 2015 at 20:27, Robert Collins <robertc at robertcollins.net> wrote:

>>> In effect, this patch is "reserving" all attributes starting with
>>> "assert" or "assret" as actual methods of the mock object, and not
>>> mocked attributes.
>>
>> Yes, and thats ugly. OTOH it caught hundreds of useless tests in
>> OpenStack when this got ported into mock 1.1.0.
>
> ... which I guess counts as strong evidence that this *is* a common
> typo, at least in certain contexts.

For clarity: None of the caught failures were assret as far as I know.
They were things like assert_called_onec_with, or assert_called.

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From matt.j.keeter at gmail.com  Tue Jul 14 21:44:46 2015
From: matt.j.keeter at gmail.com (Matthew Keeter)
Date: Tue, 14 Jul 2015 15:44:46 -0400
Subject: [Python-Dev] cpython: locals dictionary in PyRun_String
In-Reply-To: <CAP1=2W5WT35xCeg38-4BMQswOZCP85B0ZqWgDqoW7EdWBZUv7w@mail.gmail.com>
References: <3CCD3946-F553-4CAB-9CE9-BE6BE8A5AB9D@gmail.com>
 <CAP1=2W5WT35xCeg38-4BMQswOZCP85B0ZqWgDqoW7EdWBZUv7w@mail.gmail.com>
Message-ID: <B0523534-FF96-45B8-98F6-8F9DD4EE63BB@gmail.com>

One more data point:
On the Python side, exec has documentation (https://docs.python.org/3/library/functions.html#exec)
that nicely reflects what?s going on in the frame code (where globals must be a dict but locals can be
any mapping object).

I?ll file a bug to see what people think about loosening the restrictions in the C API (which will make it
match exec?s documented restrictions).

Thanks,
Matt

On Jul 14, 2015, at 2:47 PM, Brett Cannon <brett at python.org> wrote:

> 
> 
> On Tue, Jul 14, 2015 at 11:39 AM Matthew Keeter <matt.j.keeter at gmail.com> wrote:
> The docs for PyRun_String say that both globals and locals should be dictionaries [1].
> 
> However, digging into the source [2] shows me that locals doesn?t need to be a dictionary;
> it just needs to implement the mapping protocol.  Is it a bad idea to rely on this fact?
> 
> (Context: I?m plugging a custom object into locals that uses __getitem__ to track lookups.)
> 
> As you pointed out in the code, that's in the frame creation code and not directly the PyRun_StringFlags code, so technically there is a chance for us to insert a PyDict_CheckExact() call before hitting the code you linked to.
> 
> As to whether we could loosen the documented restrictions so they are guaranteed, it would be best to file an issue at bugs.python.org requesting the restriction be officially loosened and if people are amenable then a test to make sure no one accidentally breaks the API promise. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150714/b5c40af0/attachment.html>

From amk at amk.ca  Tue Jul 14 23:41:14 2015
From: amk at amk.ca (A.M. Kuchling)
Date: Tue, 14 Jul 2015 17:41:14 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <55A53E8D.5090009@stoneleaf.us>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
Message-ID: <20150714214114.GA54001@natl2235llmcal2.cmg.int>

On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote:
> Part of writing tests is making sure they fail (and for the right reason) -- proper testing of the tests would reveal such a typo.

And there are other failure modes for writing tests that succeed but
are not testing what you think.  For example, you might re-use the
same method name:

   def test_connection(self):
       # Never executed
       ...

   ... 200 lines and 10 other test methods later ...

   def test_connection(self):
       ...

Or misuse assertRaises:

   with self.assertRaises(TypeError):
       1 + "a"
       # Second statement never reached
       [] + 'b'

I don't think unittest can protect its users from such things.

--amk

From robertc at robertcollins.net  Tue Jul 14 23:53:30 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 15 Jul 2015 09:53:30 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150714214114.GA54001@natl2235llmcal2.cmg.int>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
Message-ID: <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>

On 15 July 2015 at 09:41, A.M. Kuchling <amk at amk.ca> wrote:
> On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote:
>> Part of writing tests is making sure they fail (and for the right reason) -- proper testing of the tests would reveal such a typo.
>
> And there are other failure modes for writing tests that succeed but
> are not testing what you think.  For example, you might re-use the
> same method name:
>
>    def test_connection(self):
>        # Never executed
>        ...
>
>    ... 200 lines and 10 other test methods later ...
>
>    def test_connection(self):
>        ...
>
> Or misuse assertRaises:
>
>    with self.assertRaises(TypeError):
>        1 + "a"
>        # Second statement never reached
>        [] + 'b'
>
> I don't think unittest can protect its users from such things.

It can't, but there is a sliding scale of API usability, and we should
try to be up the good end of that :).

http://sweng.the-davies.net/Home/rustys-api-design-manifesto

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From ethan at stoneleaf.us  Wed Jul 15 00:05:19 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 14 Jul 2015 15:05:19 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
Message-ID: <55A5879F.1050305@stoneleaf.us>

On 07/14/2015 02:53 PM, Robert Collins wrote:
> On 15 July 2015 at 09:41, A.M. Kuchling <amk at amk.ca> wrote:
>> On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote:
>>> Part of writing tests is making sure they fail (and for the right reason) -- proper testing of the tests would reveal such a typo.
>>
>> And there are other failure modes for writing tests that succeed but
>> are not testing what you think.  For example, you might re-use the
>> same method name:
>>
>>     def test_connection(self):
>>         # Never executed
>>         ...
>>
>>     ... 200 lines and 10 other test methods later ...
>>
>>     def test_connection(self):
>>         ...
>>
>> Or misuse assertRaises:
>>
>>     with self.assertRaises(TypeError):
>>         1 + "a"
>>         # Second statement never reached
>>         [] + 'b'
>>
>> I don't think unittest can protect its users from such things.
>
> It can't, but there is a sliding scale of API usability, and we should
> try to be up the good end of that :).

I hope you're not suggesting that supporting misspellings, and thereby ruling out the proper use of an otherwise fine variable name, is at the good end of that scale?

--
~Ethan~

From robertc at robertcollins.net  Wed Jul 15 00:22:14 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 15 Jul 2015 10:22:14 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <55A5879F.1050305@stoneleaf.us>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
Message-ID: <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>

On 15 July 2015 at 10:05, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 07/14/2015 02:53 PM, Robert Collins wrote:
...
>>> I don't think unittest can protect its users from such things.
>>
>>
>> It can't, but there is a sliding scale of API usability, and we should
>> try to be up the good end of that :).
>
>
> I hope you're not suggesting that supporting misspellings, and thereby
> ruling out the proper use of an otherwise fine variable name, is at the good
> end of that scale?

I'm not supporting the misspelling thing - see my suggestion earlier
in this thread to move the mock assertions to standalone functions,
removing the bug in that area *entirely* and eventually removing the
check for method names starting with assert from mock entirely.

What I am doing is rejecting the argument that because we can't fix
every mis-use users might make, we therefore should not fix the cases
where we can fix it.

For clarity, I think we should:
 - remove the assret check, it is I think spurious.
 - add a set of functions to the mock module that should be used in
preference to Mock.assert*
 - mark the Mock.assert* functions as PendingDeprecation
 - in 3.6 move the PendingDeprecation to Deprecated
 - in 3.7 remove the Mock.assert* functions and the check for method
names beginning with assert entirely.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From brett at python.org  Wed Jul 15 00:28:06 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Jul 2015 22:28:06 +0000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
Message-ID: <CAP1=2W6yUr3P7c359Un0TqttvcUFc5T_Npif+JLbd5WUd1EJug@mail.gmail.com>

On Tue, Jul 14, 2015 at 3:22 PM Robert Collins <robertc at robertcollins.net>
wrote:

> On 15 July 2015 at 10:05, Ethan Furman <ethan at stoneleaf.us> wrote:
> > On 07/14/2015 02:53 PM, Robert Collins wrote:
> ...
> >>> I don't think unittest can protect its users from such things.
> >>
> >>
> >> It can't, but there is a sliding scale of API usability, and we should
> >> try to be up the good end of that :).
> >
> >
> > I hope you're not suggesting that supporting misspellings, and thereby
> > ruling out the proper use of an otherwise fine variable name, is at the
> good
> > end of that scale?
>
> I'm not supporting the misspelling thing - see my suggestion earlier
> in this thread to move the mock assertions to standalone functions,
> removing the bug in that area *entirely* and eventually removing the
> check for method names starting with assert from mock entirely.
>
> What I am doing is rejecting the argument that because we can't fix
> every mis-use users might make, we therefore should not fix the cases
> where we can fix it.
>
> For clarity, I think we should:
>  - remove the assret check, it is I think spurious.
>  - add a set of functions to the mock module that should be used in
> preference to Mock.assert*
>  - mark the Mock.assert* functions as PendingDeprecation
>  - in 3.6 move the PendingDeprecation to Deprecated
>  - in 3.7 remove the Mock.assert* functions and the check for method
> names beginning with assert entirely.
>

+1 from me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150714/4fdf122e/attachment.html>

From python at mrabarnett.plus.com  Wed Jul 15 00:28:40 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 14 Jul 2015 23:28:40 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <55A5879F.1050305@stoneleaf.us>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
Message-ID: <55A58D18.30608@mrabarnett.plus.com>

On 2015-07-14 23:05, Ethan Furman wrote:
> On 07/14/2015 02:53 PM, Robert Collins wrote:
>> On 15 July 2015 at 09:41, A.M. Kuchling <amk at amk.ca> wrote:
>>> On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote:
>>>> Part of writing tests is making sure they fail (and for the right reason) -- proper testing of the tests would reveal such a typo.
>>>
>>> And there are other failure modes for writing tests that succeed but
>>> are not testing what you think.  For example, you might re-use the
>>> same method name:
>>>
>>>     def test_connection(self):
>>>         # Never executed
>>>         ...
>>>
>>>     ... 200 lines and 10 other test methods later ...
>>>
>>>     def test_connection(self):
>>>         ...
>>>
>>> Or misuse assertRaises:
>>>
>>>     with self.assertRaises(TypeError):
>>>         1 + "a"
>>>         # Second statement never reached
>>>         [] + 'b'
>>>
>>> I don't think unittest can protect its users from such things.
>>
>> It can't, but there is a sliding scale of API usability, and we should
>> try to be up the good end of that :).
>
> I hope you're not suggesting that supporting misspellings, and thereby ruling out the proper use of an otherwise fine variable name, is at the good end of that scale?
>
Somewhat OT, but did you know that the Unicode "Line_Break" property
has "Inseparable" as one of its possible values, and that "Inseperable"
is a permitted alias of it? <yuck/>


From berker.peksag at gmail.com  Wed Jul 15 00:58:44 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Wed, 15 Jul 2015 01:58:44 +0300
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
Message-ID: <CAF4280K4z0YWJN9aO_34=UNg2uiMkRK+g8LRHvKFxoZSu_Muiw@mail.gmail.com>

On Wed, Jul 15, 2015 at 1:22 AM, Robert Collins
<robertc at robertcollins.net> wrote:
> On 15 July 2015 at 10:05, Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 07/14/2015 02:53 PM, Robert Collins wrote:
> ...
>>>> I don't think unittest can protect its users from such things.
>>>
>>>
>>> It can't, but there is a sliding scale of API usability, and we should
>>> try to be up the good end of that :).
>>
>>
>> I hope you're not suggesting that supporting misspellings, and thereby
>> ruling out the proper use of an otherwise fine variable name, is at the good
>> end of that scale?
>
> I'm not supporting the misspelling thing - see my suggestion earlier
> in this thread to move the mock assertions to standalone functions,
> removing the bug in that area *entirely* and eventually removing the
> check for method names starting with assert from mock entirely.
>
> What I am doing is rejecting the argument that because we can't fix
> every mis-use users might make, we therefore should not fix the cases
> where we can fix it.
>
> For clarity, I think we should:
>  - remove the assret check, it is I think spurious.
>  - add a set of functions to the mock module that should be used in
> preference to Mock.assert*
>  - mark the Mock.assert* functions as PendingDeprecation
>  - in 3.6 move the PendingDeprecation to Deprecated
>  - in 3.7 remove the Mock.assert* functions and the check for method
> names beginning with assert entirely.

+1, but I think we need to get Larry's approval for the steps 2 and 3
because 3.5 is in feature-freeze mode.

--Berker

From breamoreboy at yahoo.co.uk  Wed Jul 15 01:07:44 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Wed, 15 Jul 2015 00:07:44 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
Message-ID: <mo44o9$8n6$1@ger.gmane.org>

On 14/07/2015 23:22, Robert Collins wrote:
>
> For clarity, I think we should:
>   - remove the assret check, it is I think spurious.
>   - add a set of functions to the mock module that should be used in
> preference to Mock.assert*
>   - mark the Mock.assert* functions as PendingDeprecation
>   - in 3.6 move the PendingDeprecation to Deprecated
>   - in 3.7 remove the Mock.assert* functions and the check for method
> names beginning with assert entirely.
>
> -Rob

+1 from me as not even Baldrick could do better, see 
https://en.wikipedia.org/wiki/Baldrick :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From ncoghlan at gmail.com  Wed Jul 15 02:41:44 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 15 Jul 2015 10:41:44 +1000
Subject: [Python-Dev] cpython: locals dictionary in PyRun_String
In-Reply-To: <B0523534-FF96-45B8-98F6-8F9DD4EE63BB@gmail.com>
References: <3CCD3946-F553-4CAB-9CE9-BE6BE8A5AB9D@gmail.com>
 <CAP1=2W5WT35xCeg38-4BMQswOZCP85B0ZqWgDqoW7EdWBZUv7w@mail.gmail.com>
 <B0523534-FF96-45B8-98F6-8F9DD4EE63BB@gmail.com>
Message-ID: <CADiSq7cgY0oz+ZtVmHk4E5oq9aoHAA3O4BfMwHLBxbp2HyxdtA@mail.gmail.com>

On 15 July 2015 at 05:44, Matthew Keeter <matt.j.keeter at gmail.com> wrote:
> One more data point:
> On the Python side, exec has documentation
> (https://docs.python.org/3/library/functions.html#exec)
> that nicely reflects what?s going on in the frame code (where globals must
> be a dict but locals can be
> any mapping object).

I was about to post about that. exec used to also require that locals
be exactly a dictionary, so my suspicion is that we simply missed
updating the PyRun_SimpleString docs when the constraint was removed
from the underlying frame execution code.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Wed Jul 15 02:59:50 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 15 Jul 2015 10:59:50 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAF4280K4z0YWJN9aO_34=UNg2uiMkRK+g8LRHvKFxoZSu_Muiw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAF4280K4z0YWJN9aO_34=UNg2uiMkRK+g8LRHvKFxoZSu_Muiw@mail.gmail.com>
Message-ID: <CADiSq7dcf-=XBbD3t4XM9GF1GHaR8CjWAsDtSTuj1XDtyOsw2A@mail.gmail.com>

On 15 July 2015 at 08:58, Berker Peksa? <berker.peksag at gmail.com> wrote:
> On Wed, Jul 15, 2015 at 1:22 AM, Robert Collins
>> For clarity, I think we should:
>>  - remove the assret check, it is I think spurious.
>>  - add a set of functions to the mock module that should be used in
>> preference to Mock.assert*
>>  - mark the Mock.assert* functions as PendingDeprecation
>>  - in 3.6 move the PendingDeprecation to Deprecated
>>  - in 3.7 remove the Mock.assert* functions and the check for method
>> names beginning with assert entirely.
>
> +1, but I think we need to get Larry's approval for the steps 2 and 3
> because 3.5 is in feature-freeze mode.

There is zero urgency here, so nothing needs to change for 3.5.
Robert's plan is a fine one to propose for 3.6 (and the PyPI mock
backport).

Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more
obnoxious behavours we can inflict on fellow open source maintainers
giving us the gift of their time and energy. If we're putting folks at
risk of losing data or otherwise having their systems compromised,
then by all means yell loudly, but for anything less, remember:

* it's almost certainly not urgent
* tolerating the occasional design decision we dislike won't ruin our lives
* a red bikeshed will still shelter our bikes, even if we'd have preferred blue
* it's just software, so we can put a blue wrapper around the red
bikeshed if we prefer it

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From steve at pearwood.info  Wed Jul 15 04:07:56 2015
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 15 Jul 2015 12:07:56 +1000
Subject: [Python-Dev] Why wasn't I consulted [was How far to go with
	user-friendliness]
In-Reply-To: <CADiSq7dcf-=XBbD3t4XM9GF1GHaR8CjWAsDtSTuj1XDtyOsw2A@mail.gmail.com>
References: <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAF4280K4z0YWJN9aO_34=UNg2uiMkRK+g8LRHvKFxoZSu_Muiw@mail.gmail.com>
 <CADiSq7dcf-=XBbD3t4XM9GF1GHaR8CjWAsDtSTuj1XDtyOsw2A@mail.gmail.com>
Message-ID: <20150715020756.GD21874@ando.pearwood.info>

On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote:

> Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more
> obnoxious behavours we can inflict on fellow open source maintainers
> giving us the gift of their time and energy.

Nick makes a good point, but it's more complicated than that.

OpenSource is not just a family of licences. It is also a social 
movement, a culture, even a brand. We spend a lot of effort trying to 
get people to care, not just intellectually but also emotionally, and 
then when they react emotionally we're dismissive and tell them they're 
being obnoxious. Maybe they are, but if so, that's the price you pay for 
having people care.


-- 
Steve

From stephen at xemacs.org  Wed Jul 15 05:00:29 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 15 Jul 2015 12:00:29 +0900
Subject: [Python-Dev] Consenting adults considered beneficial [was: How far
 to go with user-friendliness]
In-Reply-To: <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
Message-ID: <878uaif7le.fsf@uwakimon.sk.tsukuba.ac.jp>

Robert Collins writes:

 > What I am doing is rejecting the argument that because we can't fix
 > every mis-use users might make, we therefore should not fix the cases
 > where we can fix it.

This involves a value judgment, every time a new fix is proposed, as
to whether it's a mis-use that deserves fixing or a permitted-to-
consenting-adults behavior.  IMO, it's a bad idea to institutionalize
that kind of bikeshedding, especially when such "fixes" involve
overriding user choices that are permitted everywhere else.

Arbitrary choices that *some* users want to be protected from ("stop
me before I 'assret' again!") belong in linters, not in Python or the
stdlib.

To be frank, I think you have the Pythonic approach exactly backwards
here (though I am no authority on Pythonicity).  ISTM that in general
Python takes the attitude that if a particular "mis-use" seems to be
common, then we should figure out what it is about Python that
encourages that "mistake", or makes an otherwise arbitrary user choice
into a "mistake", and fix Python -- not restrict users.

Of course that's not always possible, but that's the first choice
AIUI.

From robertc at robertcollins.net  Wed Jul 15 05:08:43 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 15 Jul 2015 15:08:43 +1200
Subject: [Python-Dev] Consenting adults considered beneficial [was: How
	far to go with user-friendliness]
In-Reply-To: <878uaif7le.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <878uaif7le.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAJ3HoZ1UB5vYwrPOJZDTnR-z3Z0iz1eHoz9yDpRFURg=o4MB7A@mail.gmail.com>

On 15 July 2015 at 15:00, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Robert Collins writes:
>
>  > What I am doing is rejecting the argument that because we can't fix
>  > every mis-use users might make, we therefore should not fix the cases
>  > where we can fix it.
>
> This involves a value judgment, every time a new fix is proposed, as
> to whether it's a mis-use that deserves fixing or a permitted-to-
> consenting-adults behavior.  IMO, it's a bad idea to institutionalize
> that kind of bikeshedding, especially when such "fixes" involve
> overriding user choices that are permitted everywhere else.

I'm thoroughly confused by this.

> Arbitrary choices that *some* users want to be protected from ("stop
> me before I 'assret' again!") belong in linters, not in Python or the
> stdlib.

I agree with this.

> To be frank, I think you have the Pythonic approach exactly backwards
> here (though I am no authority on Pythonicity).  ISTM that in general
> Python takes the attitude that if a particular "mis-use" seems to be
> common, then we should figure out what it is about Python that
> encourages that "mistake", or makes an otherwise arbitrary user choice
> into a "mistake", and fix Python -- not restrict users.
>
> Of course that's not always possible, but that's the first choice
> AIUI.

And these two paragraphs confuse me again.

Lets be really specific here.

Mock today has the following behaviour:
x = Mock()
x.foo()
x.bar()
...

all will just work and are mock methods that magically appear on demand.

And it includes some methods:
x.assert_called_with()

which are not mock methods, can't be mocked, and if you make a typo
you got *no* signal back to say that you'd messed up, until the patch
that added assert_ and assret_ prefix checking was added.

Which part of that API is Pythonic?

I rejected an argument that just because some APIs are are
intrinsically able to be misused, that we should not try to write
better APIs.

I then gave an plan, for this case, which appears to have been
enthusiastically recieved by a bunch of long-time Python devs.

In what way is that unPythonic behaviour or design?

Confusedly-yrs.
Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From robertc at robertcollins.net  Wed Jul 15 05:13:24 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 15 Jul 2015 15:13:24 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7dcf-=XBbD3t4XM9GF1GHaR8CjWAsDtSTuj1XDtyOsw2A@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAF4280K4z0YWJN9aO_34=UNg2uiMkRK+g8LRHvKFxoZSu_Muiw@mail.gmail.com>
 <CADiSq7dcf-=XBbD3t4XM9GF1GHaR8CjWAsDtSTuj1XDtyOsw2A@mail.gmail.com>
Message-ID: <CAJ3HoZ2qN1BoG-P7LGmR_9QUdYtze=jaUEEOknHS75tiqVONUA@mail.gmail.com>

On 15 July 2015 at 12:59, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> There is zero urgency here, so nothing needs to change for 3.5.
> Robert's plan is a fine one to propose for 3.6 (and the PyPI mock
> backport).

Right - the bad API goes back to the very beginning. I'm not planning
on writing the new thing I sketched, though it should be straight
forward if someone wishes to do so. I'll probably file a ticket in the
tracker asking for it once this thread quiesces.

-Rob

From stephen at xemacs.org  Wed Jul 15 05:55:51 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 15 Jul 2015 12:55:51 +0900
Subject: [Python-Dev] Consenting adults considered beneficial [was:
	How	far to go with user-friendliness]
In-Reply-To: <CAJ3HoZ1UB5vYwrPOJZDTnR-z3Z0iz1eHoz9yDpRFURg=o4MB7A@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <878uaif7le.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAJ3HoZ1UB5vYwrPOJZDTnR-z3Z0iz1eHoz9yDpRFURg=o4MB7A@mail.gmail.com>
Message-ID: <877fq2f514.fsf@uwakimon.sk.tsukuba.ac.jp>

Robert Collins writes:

 > I rejected an argument that just because some APIs are are
 > intrinsically able to be misused, that we should not try to write
 > better APIs.

Well, at least to me what you wrote was inconsistent with that
explanation of what you wanted to express:

 >> What I am doing is rejecting the argument that because we can't
 >> fix every mis-use users might make, we therefore should not fix
 >> the cases where we can fix it.

As far as I can tell, that sentence says it is permissible to "fix"
*user mis-use* of APIs, not the Python *APIs themselves*, and in
context it seemed to imply we *should* "fix" user code (perhaps by
invalidating it, as this feature in mock does), although you didn't
think that appropriate in this case.  So I completely misread your
intention despite the fact that we are in violent agreement.  I'm
sorry.

BTW, I changed Subject: precisely because I have no quarrel in
principle with the path you proposed to dealing with this issue in
mock, but lack the knowledge to comment on the practical feasibility
or desirability of your proposal.

From ncoghlan at gmail.com  Wed Jul 15 06:57:26 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 15 Jul 2015 14:57:26 +1000
Subject: [Python-Dev] Why wasn't I consulted [was How far to go with
	user-friendliness]
In-Reply-To: <20150715020756.GD21874@ando.pearwood.info>
References: <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAF4280K4z0YWJN9aO_34=UNg2uiMkRK+g8LRHvKFxoZSu_Muiw@mail.gmail.com>
 <CADiSq7dcf-=XBbD3t4XM9GF1GHaR8CjWAsDtSTuj1XDtyOsw2A@mail.gmail.com>
 <20150715020756.GD21874@ando.pearwood.info>
Message-ID: <CADiSq7ep2zuf0grk9ccm0C-+YGTVZhJRd7dS8Gehn2xnRKiRQg@mail.gmail.com>

On 15 July 2015 at 12:07, Steven D'Aprano <steve at pearwood.info> wrote:
> On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote:
>
>> Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more
>> obnoxious behavours we can inflict on fellow open source maintainers
>> giving us the gift of their time and energy.
>
> Nick makes a good point, but it's more complicated than that.
>
> OpenSource is not just a family of licences. It is also a social
> movement, a culture, even a brand. We spend a lot of effort trying to
> get people to care, not just intellectually but also emotionally, and
> then when they react emotionally we're dismissive and tell them they're
> being obnoxious. Maybe they are, but if so, that's the price you pay for
> having people care.

Aye, there's definitely a balance to be struck (and *me* telling folks
not to be passionate about topics they care about would be the height
of hypocrisy).

The kinds of questions I'm encouraging folks to ask themselves to help
calibrate our degree of concern are:

* What change are we asking for?
* What will the practical end user benefit of that change be?
* What will the near term maintainer cost of that change be?
* What will the long term maintainer benefit of that change be?

Those are the questions other people are going to want answers to
anyway, so it makes sense to ask them of ourselves first.

In the case of partially reverting this change to Mock objects, the answers are:

* "Restoring support for 'assret_*' methods on Mock objects"
* "End users will be able to access their 'assret_*' methods on Mock objects"
* "Maintainers would need to modify the check itself and the related
tests and documentation"
* "Maintainers won't have to explain why 'assret_*' methods are
blocked and other 'assert_*' typos aren't"

Thus, the case for spending *any* time on reversion is incredibly
weak, even if folks agree with the premise that blocking *any* typos
at all is undesirable.

Robert's suggestion is different, as it focuses on addressing the near
term concern with a solution that genuinely improves the API design:

* "Move Mock assertions from methods to module functions"
* "End users will gain from clear structural separation between
Mock'ed methods and Mock assertions, such that method name typos don't
result in silently ignoring test failures"
* "Maintainers would need to design the new API and device a
recommended transition plan for end users that accounts for end users
wanting to support multiple Python versions"
* "Once the migration from the old API to the new API is deemed
complete, maintainers should eventually find that the improved
separation of concerns between Mock'ed methods and Mock assertions
makes the module easier to maintain"

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From solipsis at pitrou.net  Wed Jul 15 09:17:51 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 15 Jul 2015 09:17:51 +0200
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
Message-ID: <20150715091751.29906e60@fsol>

On Wed, 15 Jul 2015 10:22:14 +1200
Robert Collins <robertc at robertcollins.net> wrote:
> 
> For clarity, I think we should:
>  - remove the assret check, it is I think spurious.
>  - add a set of functions to the mock module that should be used in
> preference to Mock.assert*
>  - mark the Mock.assert* functions as PendingDeprecation
>  - in 3.6 move the PendingDeprecation to Deprecated
>  - in 3.7 remove the Mock.assert* functions and the check for method
> names beginning with assert entirely.

I think removing them is a bit too strong. There's software out there
that would like to have cross-version-compatible test suites.

Regards

Antoine.



From robertc at robertcollins.net  Wed Jul 15 10:39:37 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 15 Jul 2015 20:39:37 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150715091751.29906e60@fsol>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <20150715091751.29906e60@fsol>
Message-ID: <CAJ3HoZ0g2Fgyev3pVbC0Qn4XntyCCvueL2=SSVG61sQS=w4tUA@mail.gmail.com>

On 15 July 2015 at 19:17, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 15 Jul 2015 10:22:14 +1200
> Robert Collins <robertc at robertcollins.net> wrote:
>>
>> For clarity, I think we should:
>>  - remove the assret check, it is I think spurious.
>>  - add a set of functions to the mock module that should be used in
>> preference to Mock.assert*
>>  - mark the Mock.assert* functions as PendingDeprecation
>>  - in 3.6 move the PendingDeprecation to Deprecated
>>  - in 3.7 remove the Mock.assert* functions and the check for method
>> names beginning with assert entirely.
>
> I think removing them is a bit too strong. There's software out there
> that would like to have cross-version-compatible test suites.

Which they can do using 'mock'.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From chris at simplistix.co.uk  Thu Jul 16 09:52:11 2015
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 16 Jul 2015 08:52:11 +0100
Subject: [Python-Dev] documentation / implementation question for
	subprocess.check_output
Message-ID: <55A762AB.1040805@simplistix.co.uk>

Hi All,

Curious to see this in the docs for subprocess.check_output: "Do not use 
stderr=PIPE with this function as that can deadlock based on the child 
process error volume. Use Popen with the communicate() method when you 
need a stderr pipe."

Given that check_output's implementation uses communicate(), how could 
stderr=PIPE cause a deadlock in a way that wouldn't happen if you called 
Popen.communicate() yourself?

cheers,

Chris

From guido at python.org  Thu Jul 16 12:35:58 2015
From: guido at python.org (Guido van Rossum)
Date: Thu, 16 Jul 2015 12:35:58 +0200
Subject: [Python-Dev] documentation / implementation question for
	subprocess.check_output
In-Reply-To: <55A762AB.1040805@simplistix.co.uk>
References: <55A762AB.1040805@simplistix.co.uk>
Message-ID: <CAP7+vJLUwUK8Kezw7hiJrMFK1D+NT3tA+5GpJArha6AW0PvWNw@mail.gmail.com>

In which version? I don't see that phrase in the 3.5 docs.

On Thu, Jul 16, 2015 at 9:52 AM, Chris Withers <chris at simplistix.co.uk>
wrote:

> Hi All,
>
> Curious to see this in the docs for subprocess.check_output: "Do not use
> stderr=PIPE with this function as that can deadlock based on the child
> process error volume. Use Popen with the communicate() method when you need
> a stderr pipe."
>
> Given that check_output's implementation uses communicate(), how could
> stderr=PIPE cause a deadlock in a way that wouldn't happen if you called
> Popen.communicate() yourself?
>
> cheers,
>
> Chris
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150716/225b645e/attachment.html>

From ncoghlan at gmail.com  Thu Jul 16 17:27:32 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 17 Jul 2015 01:27:32 +1000
Subject: [Python-Dev] documentation / implementation question for
	subprocess.check_output
In-Reply-To: <CAP7+vJLUwUK8Kezw7hiJrMFK1D+NT3tA+5GpJArha6AW0PvWNw@mail.gmail.com>
References: <55A762AB.1040805@simplistix.co.uk>
 <CAP7+vJLUwUK8Kezw7hiJrMFK1D+NT3tA+5GpJArha6AW0PvWNw@mail.gmail.com>
Message-ID: <CADiSq7diWkZ3iP2sMesdRD-8kq6eG7AABGnQwSDwX9XbAOHyUA@mail.gmail.com>

On 16 July 2015 at 20:35, Guido van Rossum <guido at python.org> wrote:
> In which version? I don't see that phrase in the 3.5 docs.

The equivalent note in 3.x is "Do not use stdout=PIPE or stderr=PIPE
with this function. The child process will block if it generates
enough output to a pipe to fill up the OS pipe buffer as the pipes are
not being read from."

I think Chris is right that it's a docs bug - the warning is
applicable to subprocess.call and subprocess.check_call (which use
Popen.wait), but not to subprocess.check_output (which uses
Popen.communicate).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From rymg19 at gmail.com  Thu Jul 16 21:11:36 2015
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Thu, 16 Jul 2015 14:11:36 -0500
Subject: [Python-Dev] Where are bugs with the web site reported?
Message-ID: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>

I have encountered this weird issue on Chrome for Android where scrolling up just a little causes the page to dart to the top. I was going to report it in the bug tracker, but I didn't see a label for the web site itself.

Worst part is, this is stopping me from reading the humor page!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150716/0fd5de16/attachment.html>

From v+python at g.nevcal.com  Thu Jul 16 21:24:45 2015
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Thu, 16 Jul 2015 12:24:45 -0700
Subject: [Python-Dev] Where are bugs with the web site reported?
In-Reply-To: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>
References: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>
Message-ID: <55A804FD.3080401@g.nevcal.com>

On 7/16/2015 12:11 PM, Ryan Gonzalez wrote:
> I have encountered this weird issue on Chrome for Android where 
> scrolling up just a little causes the page to dart to the top. I was 
> going to report it in the bug tracker, but I didn't see a label for 
> the web site itself.
>
> Worst part is, this is stopping me from reading the humor page!

Sounds more like a bug in Chrome than on the site, unless it is 
repeatable using other browsers, or unless the site has Chrome-specific 
code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150716/ae12ef6a/attachment.html>

From skip.montanaro at gmail.com  Thu Jul 16 21:53:51 2015
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Thu, 16 Jul 2015 14:53:51 -0500
Subject: [Python-Dev] Where are bugs with the web site reported?
In-Reply-To: <55A804FD.3080401@g.nevcal.com>
References: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>
 <55A804FD.3080401@g.nevcal.com>
Message-ID: <CANc-5UxwExur+-_vLN6A7QbMPOKD6jW7+urpHTd_U1a+sf0KzA@mail.gmail.com>

It's a known issue -- which I thought was fixed recently. I would have
responded sooner, but I couldn't remember where website bugs are to be
reported and figured someone would chime in with the link. I *don't*
think it's bugs.python.org, though I could be wrong.

Skip

From berker.peksag at gmail.com  Thu Jul 16 21:55:29 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Thu, 16 Jul 2015 22:55:29 +0300
Subject: [Python-Dev] Where are bugs with the web site reported?
In-Reply-To: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>
References: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>
Message-ID: <CAF4280+0yc0Z_d_e8HsEq34tBF=Mybb=uy4uQNNLQOSG4+jneg@mail.gmail.com>

On Thu, Jul 16, 2015 at 10:11 PM, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> I have encountered this weird issue on Chrome for Android where scrolling up
> just a little causes the page to dart to the top. I was going to report it
> in the bug tracker, but I didn't see a label for the web site itself.
>
> Worst part is, this is stopping me from reading the humor page!

Hi,

Already reported at https://github.com/python/pythondotorg/issues/531

--Berker

From rdmurray at bitdance.com  Thu Jul 16 21:57:01 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 16 Jul 2015 15:57:01 -0400
Subject: [Python-Dev] Where are bugs with the web site reported?
In-Reply-To: <55A804FD.3080401@g.nevcal.com>
References: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>
 <55A804FD.3080401@g.nevcal.com>
Message-ID: <20150716195701.A4D80B1408B@webabinitio.net>

On Thu, 16 Jul 2015 12:24:45 -0700, Glenn Linderman <v+python at g.nevcal.com> wrote:
> On 7/16/2015 12:11 PM, Ryan Gonzalez wrote:
> > I have encountered this weird issue on Chrome for Android where 
> > scrolling up just a little causes the page to dart to the top. I was 
> > going to report it in the bug tracker, but I didn't see a label for 
> > the web site itself.
> >
> > Worst part is, this is stopping me from reading the humor page!
> 
> Sounds more like a bug in Chrome than on the site, unless it is 
> repeatable using other browsers, or unless the site has Chrome-specific 
> code.

python.org bugs are *not* reported on bugs.python.org.  I don't remember
where they are reported...it's on github somewhere I think.

The fact that it isn't obvious may be a good candidate for a bug
report :)

--David

From fuzzyman at gmail.com  Thu Jul 16 22:29:31 2015
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 16 Jul 2015 21:29:31 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
Message-ID: <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>

On Tuesday, 14 July 2015, Christie Wilson <bobcatfish at gmail.com> wrote:
>> If people do misspell it, I think they do learn not to in after it
happens a few times.
>
> Unless the line silently executes and they don't notice the mistake for
years :'(

Indeed. This has been a problem with mock, misspelled (usually
misremembered) assert methods silently did nothing.

With this fix in place several failing tests were revealed in code bases!

As for assret, it's the common misspelling people have told me about. It
seems a ridiculous thing for people to get worked up about, but people
enjoy getting worked up.

Michael


> On Tue, Jul 14, 2015 at 9:15 AM, Ron Adam <ron3200 at gmail.com> wrote:
>>
>>
>> On 07/14/2015 09:41 AM, Steven D'Aprano wrote:
>>>
>>> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
>>>>
>>>> >https://bugs.python.org/issue21238  introduces detection of
>>>> >missing/misspelt mock.assert_xxx() calls on getattr level in Python
>>>> >3.5
>>>> >
>>>> >Michael and Kushal are of the opinion that "assret" is a common typo
>>>> >of "assert" and should be supported in a sense that it also triggers
>>>> >AttributeError and is not silently ignored like a mocked user
>>>> >attribute.
>>>> >
>>>> >I disagree
>>>
>>> I must admit I don't use mock so don't quite understand what is going on
>>> in this bug report. But I don't imagine that anything good will come out
>>> of treating*one*  typo differently from all the other possible typos.
>>> Why should "assret" be treated differently from other easy-to-make typos
>>> like "asert", "assrt", "asset"? Or "assort", which is not only a
>>> standard and common English word, but "e" and "o" are right next to each
>>> other on Dvorak keyboards, making it an easy typo to make.
>>>
>>> Surely this is an obvious case where the Zen should apply. "Special
>>> cases aren't special enough..." -- either all such typos raise
>>> AttributeError, or they are all silent.
>>
>> I agree with Steven that it doesn't seem correct to not raise
AttributeError here.
>>
>> For what it's worth, I have a life long sleep disorder and am a tarrable
(<-- like this)  speller because of it.   I still don't want spell, or
grammar, checkers to not report my mistakes.  And I don't recall ever
making the particular error of using "assret" in place of "assert".  I'd be
more likely to mispell it as "assirt" if I wasn't already so familiar with
"assert".
>>
>> If people do misspell it, I think they do learn not to in after it
happens a few times.
>>
>> Regards,
>>    Ron
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com
>
>
>
> --
> Christie Wilson

-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150716/3bd05a32/attachment.html>

From fuzzyman at gmail.com  Thu Jul 16 22:34:01 2015
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 16 Jul 2015 21:34:01 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAJ3HoZ2qN1BoG-P7LGmR_9QUdYtze=jaUEEOknHS75tiqVONUA@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAF4280K4z0YWJN9aO_34=UNg2uiMkRK+g8LRHvKFxoZSu_Muiw@mail.gmail.com>
 <CADiSq7dcf-=XBbD3t4XM9GF1GHaR8CjWAsDtSTuj1XDtyOsw2A@mail.gmail.com>
 <CAJ3HoZ2qN1BoG-P7LGmR_9QUdYtze=jaUEEOknHS75tiqVONUA@mail.gmail.com>
Message-ID: <CAKCKLWzjDXXKQ6NN8rfoeYw5k1oPsxUvoO_CRzWyUMw5AwMZ8Q@mail.gmail.com>

On Wednesday, 15 July 2015, Robert Collins <robertc at robertcollins.net>
wrote:
> On 15 July 2015 at 12:59, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> There is zero urgency here, so nothing needs to change for 3.5.
>> Robert's plan is a fine one to propose for 3.6 (and the PyPI mock
>> backport).
>
> Right - the bad API goes back to the very beginning. I'm not planning


I disagree it's a bad api. It's part of why mock was so easy to use and
part of why it was so successful. With the new check for non-existent
assert methods it's no longer dangerous and so doesn't need fixing.

So -1 from me.

Michael


> on writing the new thing I sketched, though it should be straight
> forward if someone wishes to do so. I'll probably file a ticket in the
> tracker asking for it once this thread quiesces.
>
> -Rob
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>

-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150716/c280e7ab/attachment.html>

From ethan at stoneleaf.us  Thu Jul 16 22:52:15 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 16 Jul 2015 13:52:15 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
Message-ID: <55A8197F.1060500@stoneleaf.us>

On 07/16/2015 01:29 PM, Michael Foord wrote:
> On Tuesday, 14 July 2015, Christie Wilson wrote:

>> Unless the line silently executes and they don't notice the mistake for years :'(
>
> Indeed. This has been a problem with mock, misspelled (usually misremembered) assert methods silently did nothing.
>
> With this fix in place several failing tests were revealed in code bases!

This is good.  :)


> As for assret, it's the common misspelling people have told me about. It seems a ridiculous
>  thing for people to get worked up about, but people enjoy getting worked up.

It's the only exercise some of us get.  ;)

On the serious side, Python is not a DWIM language, and making accommodations for a misspelling feels very DWIMish.  As I said in an earlier email part of writing good tests is double-checking that a 
test is failing (and for the right reasons).  And yes, I am guilty of writing bad tests, and getting bit by it, and no, I still don't want the testing framework (or any part of Python) guessing what I 
meant.

--
~Ethan~

From ben+python at benfinney.id.au  Thu Jul 16 22:59:16 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 17 Jul 2015 06:59:16 +1000
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us>
Message-ID: <85lhefu8d7.fsf@benfinney.id.au>

Ethan Furman <ethan at stoneleaf.us> writes:

> On 07/16/2015 01:29 PM, Michael Foord wrote:
> > On Tuesday, 14 July 2015, Christie Wilson wrote:
>
> >> Unless the line silently executes and they don't notice the mistake for years :'(
> >
> > Indeed. This has been a problem with mock, misspelled (usually misremembered) assert methods silently did nothing.
> >
> > With this fix in place several failing tests were revealed in code bases!
>
> This is good.  :)

It's good that bugs were found. That does not argue for making an alias
in the library, though; it better argues for those projects adding a
linter check for the common misspellings.

> > As for assret, it's the common misspelling people have told me
> > about. It seems a ridiculous thing for people to get worked up
> > about, but people enjoy getting worked up.

Advocating for a clean API is ridiculous? That's a disturbing attitude
to hear from a Python standard library contributor.

> On the serious side, Python is not a DWIM language, and making
> accommodations for a misspelling feels very DWIMish. As I said in an
> earlier email part of writing good tests is double-checking that a
> test is failing (and for the right reasons). And yes, I am guilty of
> writing bad tests, and getting bit by it, and no, I still don't want
> the testing framework (or any part of Python) guessing what I meant.

+1.

These checks are a good thing, but they belong in a linter tool not as
aliases in the API.

-- 
 \      ?You say ?Carmina?, and I say ?Burana?, You say ?Fortuna?, and |
  `\    I say ?cantata?, Carmina, Burana, Fortuna, cantata, Let's Carl |
_o__)                                the whole thing Orff.? ?anonymous |
Ben Finney


From solipsis at pitrou.net  Thu Jul 16 23:10:03 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 16 Jul 2015 23:10:03 +0200
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
Message-ID: <20150716231003.356b91b4@fsol>

On Fri, 17 Jul 2015 06:59:16 +1000
Ben Finney <ben+python at benfinney.id.au> wrote:
> 
> +1.
> 
> These checks are a good thing, but they belong in a linter tool not as
> aliases in the API.

Practicality beats purity. Unless you have been actually *bitten* by
those checks I don't think there's any serious reason to complain.

Regards

Antoine.



From greg.ewing at canterbury.ac.nz  Thu Jul 16 23:47:34 2015
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 17 Jul 2015 09:47:34 +1200
Subject: [Python-Dev] Where are bugs with the web site reported?
In-Reply-To: <20150716195701.A4D80B1408B@webabinitio.net>
References: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>
 <55A804FD.3080401@g.nevcal.com> <20150716195701.A4D80B1408B@webabinitio.net>
Message-ID: <55A82676.9040403@canterbury.ac.nz>

R. David Murray wrote:
> python.org bugs are *not* reported on bugs.python.org.  I don't remember
> where they are reported...it's on github somewhere I think.
> 
> The fact that it isn't obvious may be a good candidate for a bug
> report :)

But... which bug tracker should it be reported to? :-)

-- 
Greg

From rymg19 at gmail.com  Fri Jul 17 00:09:04 2015
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Thu, 16 Jul 2015 17:09:04 -0500
Subject: [Python-Dev] Where are bugs with the web site reported?
In-Reply-To: <55A804FD.3080401@g.nevcal.com>
References: <04B6599C-F812-4D11-A656-68F6F3A589D5@gmail.com>
 <55A804FD.3080401@g.nevcal.com>
Message-ID: <CAO41-mPofN-1iMQfMdk=JY0WRpyOaSBQMfBOYQhr6_mTN0hfzg@mail.gmail.com>

Response from the Chrome devs:

This site has JS that reacts to the viewport resize event from top controls
showing by scrolling to the top.  I guess the intent might be to scroll to
the top when the phone rotates, and it overtriggers here.  I don't think
there's a short-term fix, but this seems like an interesting case to keep
in mind while evolving viewport resize behaviors.


On Thu, Jul 16, 2015 at 2:24 PM, Glenn Linderman <v+python at g.nevcal.com>
wrote:

>  On 7/16/2015 12:11 PM, Ryan Gonzalez wrote:
>
> I have encountered this weird issue on Chrome for Android where scrolling
> up just a little causes the page to dart to the top. I was going to report
> it in the bug tracker, but I didn't see a label for the web site itself.
>
> Worst part is, this is stopping me from reading the humor page!
>
>
> Sounds more like a bug in Chrome than on the site, unless it is repeatable
> using other browsers, or unless the site has Chrome-specific code.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something?s wrong.
http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150716/de4afe32/attachment.html>

From ben+python at benfinney.id.au  Fri Jul 17 00:30:59 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 17 Jul 2015 08:30:59 +1000
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol>
Message-ID: <85h9p3u44c.fsf@benfinney.id.au>

Antoine Pitrou <solipsis at pitrou.net> writes:

> On Fri, 17 Jul 2015 06:59:16 +1000
> Ben Finney <ben+python at benfinney.id.au> wrote:
> > 
> > +1.
> > 
> > These checks are a good thing, but they belong in a linter tool not as
> > aliases in the API.
>
> Practicality beats purity. Unless you have been actually *bitten* by
> those checks I don't think there's any serious reason to complain.

By definition, advocating to not add cruft to an API is going to be in
advance of being bitten by those additions.

Your position seems to be, then, that any complaint about additions to
an API can be dismissed out of hand.

I hope that's not what you mean, but I can't see what else you could be
saying.

-- 
 \         ?Of all classes the rich are the most noticed and the least |
  `\      studied.? ?John Kenneth Galbraith, _The Age of Uncertainty_, |
_o__)                                                             1977 |
Ben Finney


From ischwabacher at wisc.edu  Thu Jul 16 23:11:30 2015
From: ischwabacher at wisc.edu (ISAAC J SCHWABACHER)
Date: Thu, 16 Jul 2015 21:11:30 +0000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <85lhefu8d7.fsf@benfinney.id.au>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
Message-ID: <SN1PR06MB1824B21214788704FDA056E2B6990@SN1PR06MB1824.namprd06.prod.outlook.com>

From: Python-Dev <python-dev-bounces+ischwabacher=wisc.edu at python.org> on behalf of Ben Finney <ben+python at benfinney.id.au>
Sent: Thursday, July 16, 2015 15:59
To: python-dev at python.org
Subject: Re: [Python-Dev] How far to go with user-friendliness

> Ethan Furman <ethan at stoneleaf.us> writes:
> 
> > On 07/16/2015 01:29 PM, Michael Foord wrote:
> > > On Tuesday, 14 July 2015, Christie Wilson wrote:
> >
> > >> Unless the line silently executes and they don't notice the mistake for years :'(
> > >
> > > Indeed. This has been a problem with mock, misspelled (usually misremembered) assert methods silently did nothing.
> > >
> > > With this fix in place several failing tests were revealed in code bases!
> >
> > This is good.  :)
> 
> It's good that bugs were found. That does not argue for making an alias
> in the library, though; it better argues for those projects adding a
> linter check for the common misspellings.
> 
> > > As for assret, it's the common misspelling people have told me
> > > about. It seems a ridiculous thing for people to get worked up
> > > about, but people enjoy getting worked up.
> 
> Advocating for a clean API is ridiculous? That's a disturbing attitude
> to hear from a Python standard library contributor.
> 
> > On the serious side, Python is not a DWIM language, and making
> > accommodations for a misspelling feels very DWIMish. As I said in an
> > earlier email part of writing good tests is double-checking that a
> > test is failing (and for the right reasons). And yes, I am guilty of
> > writing bad tests, and getting bit by it, and no, I still don't want
> > the testing framework (or any part of Python) guessing what I meant.
> 
> +1.
> 
> These checks are a good thing, but they belong in a linter tool not as
> aliases in the API.

+1

> --
>  \      ?You say ?Carmina?, and I say ?Burana?, You say ?Fortuna?, and |
>   `\    I say ?cantata?, Carmina, Burana, Fortuna, cantata, Let's Carl |
> _o__)                                the whole thing Orff.? ?anonymous |

+1 000 000

ijs

From solipsis at pitrou.net  Fri Jul 17 01:03:13 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 17 Jul 2015 01:03:13 +0200
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
Message-ID: <20150717010313.73a561aa@fsol>

On Fri, 17 Jul 2015 08:30:59 +1000
Ben Finney <ben+python at benfinney.id.au> wrote:
> Antoine Pitrou <solipsis at pitrou.net> writes:
> 
> > On Fri, 17 Jul 2015 06:59:16 +1000
> > Ben Finney <ben+python at benfinney.id.au> wrote:
> > > 
> > > +1.
> > > 
> > > These checks are a good thing, but they belong in a linter tool not as
> > > aliases in the API.
> >
> > Practicality beats purity. Unless you have been actually *bitten* by
> > those checks I don't think there's any serious reason to complain.
> 
> By definition, advocating to not add cruft to an API is going to be in
> advance of being bitten by those additions.

This sounds very much like FUD to me. I specifically talked about being
*actually* bitten by it, not speculating that you may one day be bitten
by it without even giving any specifics as to why you think that,
except some vague stance on purity.

On the other hand, the maintainer mentioned there were concrete cases
where some people's test suites were *helped* by the change.

You may of course continue this theoretical argument, but I doubt doing
so will sway anyone's opinion.

Regards

Antoine.



From solipsis at pitrou.net  Fri Jul 17 01:15:03 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 17 Jul 2015 01:15:03 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAJ3HoZ0g2Fgyev3pVbC0Qn4XntyCCvueL2=SSVG61sQS=w4tUA@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <20150715091751.29906e60@fsol>
 <CAJ3HoZ0g2Fgyev3pVbC0Qn4XntyCCvueL2=SSVG61sQS=w4tUA@mail.gmail.com>
Message-ID: <20150717011503.302aa834@fsol>

On Wed, 15 Jul 2015 20:39:37 +1200
Robert Collins <robertc at robertcollins.net> wrote:
> On 15 July 2015 at 19:17, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Wed, 15 Jul 2015 10:22:14 +1200
> > Robert Collins <robertc at robertcollins.net> wrote:
> >>
> >> For clarity, I think we should:
> >>  - remove the assret check, it is I think spurious.
> >>  - add a set of functions to the mock module that should be used in
> >> preference to Mock.assert*
> >>  - mark the Mock.assert* functions as PendingDeprecation
> >>  - in 3.6 move the PendingDeprecation to Deprecated
> >>  - in 3.7 remove the Mock.assert* functions and the check for method
> >> names beginning with assert entirely.
> >
> > I think removing them is a bit too strong. There's software out there
> > that would like to have cross-version-compatible test suites.
> 
> Which they can do using 'mock'.

You mean the backported version?

Regards

Antoine.

From solipsis at pitrou.net  Fri Jul 17 01:18:18 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 17 Jul 2015 01:18:18 +0200
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
Message-ID: <20150717011818.38176504@fsol>

On Wed, 15 Jul 2015 07:40:57 +1200
Robert Collins <robertc at robertcollins.net> wrote:

> On 15 July 2015 at 07:39, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 14 July 2015 at 20:27, Robert Collins <robertc at robertcollins.net> wrote:
> 
> >>> In effect, this patch is "reserving" all attributes starting with
> >>> "assert" or "assret" as actual methods of the mock object, and not
> >>> mocked attributes.
> >>
> >> Yes, and thats ugly. OTOH it caught hundreds of useless tests in
> >> OpenStack when this got ported into mock 1.1.0.
> >
> > ... which I guess counts as strong evidence that this *is* a common
> > typo, at least in certain contexts.
> 
> For clarity: None of the caught failures were assret as far as I know.
> They were things like assert_called_onec_with, or assert_called.

By the way, I've also been bitten by this several times, so I
appreciate the desire to at least warn users (or raise an exception, or
whatever).

Regards

Antoine.



From xr.lists at gmail.com  Fri Jul 17 01:35:53 2015
From: xr.lists at gmail.com (Alexander)
Date: Fri, 17 Jul 2015 11:35:53 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150717011818.38176504@fsol>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
Message-ID: <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>

> By the way, I've also been bitten by this several times, so I
> appreciate the desire to at least warn users (or raise an exception, or
> whatever).

It is not an intention to make tests more robust. It is the
implementation, which is questionable at least. I actually still hope
that the whole thing is a joke.

I do not want to read mistyped code from other developers and try to
guess whether it will work properly or not.



On Fri, Jul 17, 2015 at 11:18 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 15 Jul 2015 07:40:57 +1200
> Robert Collins <robertc at robertcollins.net> wrote:
>
>> On 15 July 2015 at 07:39, Paul Moore <p.f.moore at gmail.com> wrote:
>> > On 14 July 2015 at 20:27, Robert Collins <robertc at robertcollins.net> wrote:
>>
>> >>> In effect, this patch is "reserving" all attributes starting with
>> >>> "assert" or "assret" as actual methods of the mock object, and not
>> >>> mocked attributes.
>> >>
>> >> Yes, and thats ugly. OTOH it caught hundreds of useless tests in
>> >> OpenStack when this got ported into mock 1.1.0.
>> >
>> > ... which I guess counts as strong evidence that this *is* a common
>> > typo, at least in certain contexts.
>>
>> For clarity: None of the caught failures were assret as far as I know.
>> They were things like assert_called_onec_with, or assert_called.
>
> By the way, I've also been bitten by this several times, so I
> appreciate the desire to at least warn users (or raise an exception, or
> whatever).
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/xr.lists%40gmail.com

From solipsis at pitrou.net  Fri Jul 17 01:48:51 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 17 Jul 2015 01:48:51 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
Message-ID: <20150717014851.2813b7bf@fsol>

On Fri, 17 Jul 2015 11:35:53 +1200
Alexander <xr.lists at gmail.com> wrote:
> 
> I do not want to read mistyped code from other developers and try to
> guess whether it will work properly or not.

You don't have to guess anything. If it's mistyped, either it raises
AttributeError (because it starts with "assert_"), or it doesn't do
anything. So, in both cases, it *doesn't* work properly.

Regards

Antoine.

From ethan at stoneleaf.us  Fri Jul 17 02:11:40 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 16 Jul 2015 17:11:40 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150717014851.2813b7bf@fsol>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <20150717014851.2813b7bf@fsol>
Message-ID: <55A8483C.70705@stoneleaf.us>

On 07/16/2015 04:48 PM, Antoine Pitrou wrote:
> On Fri, 17 Jul 2015 11:35:53 +1200 Alexander wrote:
>>
>> I do not want to read mistyped code from other developers and try to
>> guess whether it will work properly or not.
>
> You don't have to guess anything. If it's mistyped, either it raises
> AttributeError (because it starts with "assert_"), or it doesn't do
> anything. So, in both cases, it *doesn't* work properly.

Yes, but in the case of "assrt_*" it won't work properly and won't not work properly.  And neither should "assret_*".

--
~Ethan~

From robertc at robertcollins.net  Fri Jul 17 03:50:40 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Fri, 17 Jul 2015 13:50:40 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAKCKLWzjDXXKQ6NN8rfoeYw5k1oPsxUvoO_CRzWyUMw5AwMZ8Q@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAF4280K4z0YWJN9aO_34=UNg2uiMkRK+g8LRHvKFxoZSu_Muiw@mail.gmail.com>
 <CADiSq7dcf-=XBbD3t4XM9GF1GHaR8CjWAsDtSTuj1XDtyOsw2A@mail.gmail.com>
 <CAJ3HoZ2qN1BoG-P7LGmR_9QUdYtze=jaUEEOknHS75tiqVONUA@mail.gmail.com>
 <CAKCKLWzjDXXKQ6NN8rfoeYw5k1oPsxUvoO_CRzWyUMw5AwMZ8Q@mail.gmail.com>
Message-ID: <CAJ3HoZ1dTHof=reXst2AHArMHMg3qrG+VVjHsY_fNRoi9H8Ntg@mail.gmail.com>

On 17 Jul 2015 08:34, "Michael Foord" <fuzzyman at gmail.com> wrote:
>
>
>
> On Wednesday, 15 July 2015, Robert Collins <robertc at robertcollins.net>
wrote:
> > On 15 July 2015 at 12:59, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>
> >> There is zero urgency here, so nothing needs to change for 3.5.
> >> Robert's plan is a fine one to propose for 3.6 (and the PyPI mock
> >> backport).
> >
> > Right - the bad API goes back to the very beginning. I'm not planning
>
>
> I disagree it's a bad api. It's part of why mock was so easy to use and
part of why it was so successful. With the new check for non-existent
assert methods it's no longer dangerous and so doesn't need fixing.

Could you help me understand how the presence of assert... on the mock vs
in the mock module affected ease of use?

-Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150717/ca214fdd/attachment-0001.html>

From ncoghlan at gmail.com  Fri Jul 17 08:30:51 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 17 Jul 2015 16:30:51 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <85h9p3u44c.fsf@benfinney.id.au>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
Message-ID: <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>

On 17 July 2015 at 08:30, Ben Finney <ben+python at benfinney.id.au> wrote:
> By definition, advocating to not add cruft to an API is going to be in
> advance of being bitten by those additions.

That's not what people are doing. Folks are actually arguing for
*restoring* the ability to mock out method names starting with
"assret_*".

I still don't know why anyone thinks restoring that would be a
worthwhile use of a maintainers' time (or why they thinking arguing in
favour of such a capability is a worthwhile use of theirs).

None of the perspectives presented in this thread are new, although
the apparent obsession over such a minor detail has made it abundantly
clear that this kind of helper simply isn't worth the distraction it
creates for maintainers, *regardless* of whether or not it helps end
users.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Fri Jul 17 08:37:04 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 17 Jul 2015 16:37:04 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
Message-ID: <CADiSq7donuLHZKbsaQcLyGXttY-2mwm7UPkEtx4A6wB05hWCrA@mail.gmail.com>

On 17 July 2015 at 09:35, Alexander <xr.lists at gmail.com> wrote:
>> By the way, I've also been bitten by this several times, so I
>> appreciate the desire to at least warn users (or raise an exception, or
>> whatever).
>
> It is not an intention to make tests more robust. It is the
> implementation, which is questionable at least. I actually still hope
> that the whole thing is a joke.
>
> I do not want to read mistyped code from other developers and try to
> guess whether it will work properly or not.

*Any* operation starting with "assret_*" on a Mock object will throw
AttributeError in 3.5+. The only way to get it to *work* is to spell
it properly.

The specific typo that is checked is the only one that changes the
spelling without also changing the overall length and shape of the
word.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From chris at simplistix.co.uk  Fri Jul 17 09:44:43 2015
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2015 08:44:43 +0100
Subject: [Python-Dev] documentation / implementation question for
	subprocess.check_output
In-Reply-To: <CADiSq7diWkZ3iP2sMesdRD-8kq6eG7AABGnQwSDwX9XbAOHyUA@mail.gmail.com>
References: <55A762AB.1040805@simplistix.co.uk>	<CAP7+vJLUwUK8Kezw7hiJrMFK1D+NT3tA+5GpJArha6AW0PvWNw@mail.gmail.com>
 <CADiSq7diWkZ3iP2sMesdRD-8kq6eG7AABGnQwSDwX9XbAOHyUA@mail.gmail.com>
Message-ID: <55A8B26B.5070604@simplistix.co.uk>

On 16/07/2015 16:27, Nick Coghlan wrote:
> On 16 July 2015 at 20:35, Guido van Rossum <guido at python.org> wrote:
>> In which version? I don't see that phrase in the 3.5 docs.
> The equivalent note in 3.x is "Do not use stdout=PIPE or stderr=PIPE
> with this function. The child process will block if it generates
> enough output to a pipe to fill up the OS pipe buffer as the pipes are
> not being read from."
>
> I think Chris is right that it's a docs bug - the warning is
> applicable to subprocess.call and subprocess.check_call (which use
> Popen.wait), but not to subprocess.check_output (which uses
> Popen.communicate).
Cool, if I get a chance, I'll try and work up a patch, but it's been so 
long since I last did any core-dev work that I'd need to read up on what 
current processes are.

cheers,

Chris

From status at bugs.python.org  Fri Jul 17 18:08:15 2015
From: status at bugs.python.org (Python tracker)
Date: Fri, 17 Jul 2015 18:08:15 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150717160815.0EF3C568E0@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-07-10 - 2015-07-17)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4947 (+19)
  closed 31468 (+29)
  total  36415 (+48)

Open issues with patches: 2260 


Issues opened (31)
==================

#24612: not operator expression raising a syntax error
http://bugs.python.org/issue24612  opened by candide

#24613: array.fromstring Use After Free
http://bugs.python.org/issue24613  opened by JohnLeitch

#24616: 'make install' fails installation of man pages for Python 2.7.
http://bugs.python.org/issue24616  opened by ronbarak

#24617: os.makedirs()'s [mode] not correct
http://bugs.python.org/issue24617  opened by John Jones

#24618: Invalid read in PyCode_New
http://bugs.python.org/issue24618  opened by blarsen

#24619: async/await parser issues
http://bugs.python.org/issue24619  opened by skrah

#24620: Segfault with nonsensical random state
http://bugs.python.org/issue24620  opened by skrah

#24621: zipfile.BadZipFile: File is not a zip file
http://bugs.python.org/issue24621  opened by Yasar L. Ahmed

#24622: tokenize.py: missing EXACT_TOKEN_TYPES
http://bugs.python.org/issue24622  opened by skrah

#24623: Parser: broken line numbers for triple-quoted strings
http://bugs.python.org/issue24623  opened by skrah

#24626: please sync cgi.parse document
http://bugs.python.org/issue24626  opened by xwhhsprings

#24632: Improve documentation about __main__.py
http://bugs.python.org/issue24632  opened by ezio.melotti

#24633: README file installed into site-packages conflicts with packag
http://bugs.python.org/issue24633  opened by S??bastien Celles

#24634: Importing uuid should not try to load libc on Windows
http://bugs.python.org/issue24634  opened by steve.dower

#24635: test_typing is flaky
http://bugs.python.org/issue24635  opened by r.david.murray

#24637: locals dictionary in PyRun_String
http://bugs.python.org/issue24637  opened by Matthew Keeter

#24638: asyncio "loop argument must agree with future" error message c
http://bugs.python.org/issue24638  opened by r.david.murray

#24640: no ensurepip in embedded Windows distribution
http://bugs.python.org/issue24640  opened by chriskrycho

#24641: Log type of unserializable value when raising JSON TypeError
http://bugs.python.org/issue24641  opened by Madison May

#24642: Will there be an MSI installer?
http://bugs.python.org/issue24642  opened by tritium

#24643: VS 2015 pyconfig.h #define timezone _timezone conflicts with t
http://bugs.python.org/issue24643  opened by James Salter

#24645: logging.handlers.QueueHandler should not lock when handling a 
http://bugs.python.org/issue24645  opened by jsbronder

#24646: Python accepts SSL certificate that should be rejected on OSX
http://bugs.python.org/issue24646  opened by jpakkane

#24647: Document argparse.REMAINDER as being equal to "..."
http://bugs.python.org/issue24647  opened by Antony.Lee

#24648: Allocation of values array in split dicts should use small obj
http://bugs.python.org/issue24648  opened by Mark.Shannon

#24649: python -mtrace --help is wrong
http://bugs.python.org/issue24649  opened by Antony.Lee

#24650: Error in yield expression documentation
http://bugs.python.org/issue24650  opened by swanson

#24651: Mock.assert* API is in user namespace
http://bugs.python.org/issue24651  opened by rbcollins

#24652: C-API Pure Embedding enhancement
http://bugs.python.org/issue24652  opened by Justin Huang

#24653: Mock.assert_has_calls([]) incorrectly passes
http://bugs.python.org/issue24653  opened by rbcollins

#24654: PEP 492 - example benchmark doesn't work (TypeError)
http://bugs.python.org/issue24654  opened by wodny



Most recent 15 issues with no replies (15)
==========================================

#24654: PEP 492 - example benchmark doesn't work (TypeError)
http://bugs.python.org/issue24654

#24652: C-API Pure Embedding enhancement
http://bugs.python.org/issue24652

#24651: Mock.assert* API is in user namespace
http://bugs.python.org/issue24651

#24650: Error in yield expression documentation
http://bugs.python.org/issue24650

#24649: python -mtrace --help is wrong
http://bugs.python.org/issue24649

#24647: Document argparse.REMAINDER as being equal to "..."
http://bugs.python.org/issue24647

#24641: Log type of unserializable value when raising JSON TypeError
http://bugs.python.org/issue24641

#24637: locals dictionary in PyRun_String
http://bugs.python.org/issue24637

#24626: please sync cgi.parse document
http://bugs.python.org/issue24626

#24623: Parser: broken line numbers for triple-quoted strings
http://bugs.python.org/issue24623

#24619: async/await parser issues
http://bugs.python.org/issue24619

#24618: Invalid read in PyCode_New
http://bugs.python.org/issue24618

#24591: offer option to suppress "clean --all" output relating to none
http://bugs.python.org/issue24591

#24577: Document asyncio behavior (logging and call to connection_lost
http://bugs.python.org/issue24577

#24557: Refactor LibreSSL / EGD detection
http://bugs.python.org/issue24557



Most recent 15 issues waiting for review (15)
=============================================

#24645: logging.handlers.QueueHandler should not lock when handling a 
http://bugs.python.org/issue24645

#24637: locals dictionary in PyRun_String
http://bugs.python.org/issue24637

#24634: Importing uuid should not try to load libc on Windows
http://bugs.python.org/issue24634

#24633: README file installed into site-packages conflicts with packag
http://bugs.python.org/issue24633

#24622: tokenize.py: missing EXACT_TOKEN_TYPES
http://bugs.python.org/issue24622

#24620: Segfault with nonsensical random state
http://bugs.python.org/issue24620

#24613: array.fromstring Use After Free
http://bugs.python.org/issue24613

#24594: msilib.OpenDatabase Type Confusion
http://bugs.python.org/issue24594

#24580: Wrong or missing exception when compiling regexes with recursi
http://bugs.python.org/issue24580

#24567: random.choice IndexError due to double-rounding
http://bugs.python.org/issue24567

#24565: the f_lineno getter is broken
http://bugs.python.org/issue24565

#24563: Encoding declaration: doc supported encodings
http://bugs.python.org/issue24563

#24557: Refactor LibreSSL / EGD detection
http://bugs.python.org/issue24557

#24536: os.pipe() should return a structsequence (or namedtuple.)
http://bugs.python.org/issue24536

#24533: Increased Test Coverage for Lib/random.py
http://bugs.python.org/issue24533



Top 10 most discussed issues (10)
=================================

#24567: random.choice IndexError due to double-rounding
http://bugs.python.org/issue24567  17 msgs

#24379: operator.subscript
http://bugs.python.org/issue24379   9 msgs

#24632: Improve documentation about __main__.py
http://bugs.python.org/issue24632   9 msgs

#24643: VS 2015 pyconfig.h #define timezone _timezone conflicts with t
http://bugs.python.org/issue24643   9 msgs

#14373: C implementation of functools.lru_cache
http://bugs.python.org/issue14373   7 msgs

#21750: mock_open data is visible only once for the life of the class
http://bugs.python.org/issue21750   7 msgs

#23220: Documents input/output effects of how IDLE runs user code
http://bugs.python.org/issue23220   7 msgs

#24612: not operator expression raising a syntax error
http://bugs.python.org/issue24612   7 msgs

#23601: use small object allocator for dict key storage
http://bugs.python.org/issue23601   6 msgs

#24633: README file installed into site-packages conflicts with packag
http://bugs.python.org/issue24633   6 msgs



Issues closed (29)
==================

#18622: reset_mock on mock created by mock_open causes infinite recurs
http://bugs.python.org/issue18622  closed by rbcollins

#23247: Crash in the reset() method of StreamWriter of CJK codecs
http://bugs.python.org/issue23247  closed by python-dev

#23530: os and multiprocessing.cpu_count do not respect cpuset/affinit
http://bugs.python.org/issue23530  closed by neologix

#23661: Setting a exception side_effect on a mock from create_autospec
http://bugs.python.org/issue23661  closed by berker.peksag

#23963: Windows build error using original openssl source
http://bugs.python.org/issue23963  closed by python-dev

#24508: Backport 3.5's Windows build project files to 2.7
http://bugs.python.org/issue24508  closed by python-dev

#24572: IDLE Text Output With ASCII Control Codes Not Working
http://bugs.python.org/issue24572  closed by terry.reedy

#24583: set.update(): Crash when source set is changed during merging
http://bugs.python.org/issue24583  closed by rhettinger

#24587: Tkinter stacking versus focus behavior on Windows
http://bugs.python.org/issue24587  closed by ned.deily

#24601: bytes and unicode splitlines() methods differ on what is a lin
http://bugs.python.org/issue24601  closed by gregory.p.smith

#24602: SRE_SEARCH Integer Underflow
http://bugs.python.org/issue24602  closed by serhiy.storchaka

#24606: segfault caused by nested calls to map()
http://bugs.python.org/issue24606  closed by serhiy.storchaka

#24607: standardize sh module
http://bugs.python.org/issue24607  closed by r.david.murray

#24608: Certain inputs to wave.open() result in readframes returning a
http://bugs.python.org/issue24608  closed by serhiy.storchaka

#24609: shutil.copytree fails with symlinks to directories when symlin
http://bugs.python.org/issue24609  closed by berker.peksag

#24610: Incorrect example Unicode string in docs footnote
http://bugs.python.org/issue24610  closed by python-dev

#24611: Compiling Python 2.7.10 Error on Unixware 7.1.4
http://bugs.python.org/issue24611  closed by serhiy.storchaka

#24614: 404 link in Documenting Python, Style Guide
http://bugs.python.org/issue24614  closed by berker.peksag

#24615: 'make install' fails installation of man pages for Python 2.7.
http://bugs.python.org/issue24615  closed by ronbarak

#24624: Itertools documentation says iterator when iterable is intende
http://bugs.python.org/issue24624  closed by r.david.murray

#24625: py.exe executes #! in windows
http://bugs.python.org/issue24625  closed by paul.moore

#24627: Import bsddb result in error on OS X (Python 2.7.10)
http://bugs.python.org/issue24627  closed by ned.deily

#24628: load_workbook giving ValueError: invalid literal for int()
http://bugs.python.org/issue24628  closed by berker.peksag

#24629: unittest.main shadows unittest.main module
http://bugs.python.org/issue24629  closed by vadmium

#24630: null pointer dereference in `load_newobj_ex`
http://bugs.python.org/issue24630  closed by serhiy.storchaka

#24631: Regression in timeit with multyline setup
http://bugs.python.org/issue24631  closed by serhiy.storchaka

#24636: re.search not respecting anchor markers in or-ed construction
http://bugs.python.org/issue24636  closed by serhiy.storchaka

#24639: Documentation: broken link on unittest page
http://bugs.python.org/issue24639  closed by r.david.murray

#24644: --help for runnable stdlib modules
http://bugs.python.org/issue24644  closed by r.david.murray

From steve at pearwood.info  Fri Jul 17 18:20:52 2015
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 18 Jul 2015 02:20:52 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7donuLHZKbsaQcLyGXttY-2mwm7UPkEtx4A6wB05hWCrA@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <CADiSq7donuLHZKbsaQcLyGXttY-2mwm7UPkEtx4A6wB05hWCrA@mail.gmail.com>
Message-ID: <20150717162052.GH21874@ando.pearwood.info>

On Fri, Jul 17, 2015 at 04:37:04PM +1000, Nick Coghlan wrote:

> The specific typo that is checked is the only one that changes the
> spelling without also changing the overall length and shape of the
> word.

I don't think your comment above is correct.

    assert => aasert aseert azzert essert assort

all have the same overall length and shape.

Not all spelling errors are typos (hitting the wrong key). I've seen 
spelling errors this bad, or worse, from native English writers. Poor 
spelling, bad keyboards, distraction, and dyslexia can all contribute. 
And those who aren't fluent in English will make their own spelling 
errors, and may not even notice if the length of the word changes:

    assert => asert

For those who are dyslexic, there are spelling errors and typos that may 
be difficult to tell apart even though the shape of the word changes:

    assert => assery asserh 

(perhaps -- I'm not dyslexic, I'm just going by what I've read about 
their experience).

In my opinion, this sets a bad precedent for adding special case after 
special case, and the risk is that people will feel slighted if they are 
told that their typos aren't important enough to be made a special case 
too.

If Michael wishes to argue that this is a useful feature rather than an 
ugly DWIM wart, that's his perogative, but the justification that 
"assret" is the *only* such plausible typo is just plain wrong. We've 
already heard from Robert Collins that he found a bunch of silently 
failing assertions in his mocks, and none of them started with "assret".


All-spelling-errors-are-deliberate-to-provide-new-and-exciting-ways-to-spell-old-words-ly y'rs,

-- 
Steve

From mertz at gnosis.cx  Fri Jul 17 18:55:14 2015
From: mertz at gnosis.cx (David Mertz)
Date: Fri, 17 Jul 2015 09:55:14 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150717162052.GH21874@ando.pearwood.info>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <CADiSq7donuLHZKbsaQcLyGXttY-2mwm7UPkEtx4A6wB05hWCrA@mail.gmail.com>
 <20150717162052.GH21874@ando.pearwood.info>
Message-ID: <CAEbHw4bdhOZvpYcjk+EoV0QFe+UgtSNfabBbRZJrR76X46tgsg@mail.gmail.com>

Nothing huge to add, and I'm not experienced using mock.  But the special
handling of 'assret' as a "misspelling of 'assert'" definitely strikes me
as a wart also.  That sort of thing really has no place in a library
itself, but rather only in a linter.

On Fri, Jul 17, 2015 at 9:20 AM, Steven D'Aprano <steve at pearwood.info>
wrote:

> On Fri, Jul 17, 2015 at 04:37:04PM +1000, Nick Coghlan wrote:
>
> > The specific typo that is checked is the only one that changes the
> > spelling without also changing the overall length and shape of the
> > word.
>
> I don't think your comment above is correct.
>
>     assert => aasert aseert azzert essert assort
>
> all have the same overall length and shape.
>
> Not all spelling errors are typos (hitting the wrong key). I've seen
> spelling errors this bad, or worse, from native English writers. Poor
> spelling, bad keyboards, distraction, and dyslexia can all contribute.
> And those who aren't fluent in English will make their own spelling
> errors, and may not even notice if the length of the word changes:
>
>     assert => asert
>
> For those who are dyslexic, there are spelling errors and typos that may
> be difficult to tell apart even though the shape of the word changes:
>
>     assert => assery asserh
>
> (perhaps -- I'm not dyslexic, I'm just going by what I've read about
> their experience).
>
> In my opinion, this sets a bad precedent for adding special case after
> special case, and the risk is that people will feel slighted if they are
> told that their typos aren't important enough to be made a special case
> too.
>
> If Michael wishes to argue that this is a useful feature rather than an
> ugly DWIM wart, that's his perogative, but the justification that
> "assret" is the *only* such plausible typo is just plain wrong. We've
> already heard from Robert Collins that he found a bunch of silently
> failing assertions in his mocks, and none of them started with "assret".
>
>
> All-spelling-errors-are-deliberate-to-provide-new-and-exciting-ways-to-spell-old-words-ly
> y'rs,
>
> --
> Steve
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150717/52001c0b/attachment.html>

From ethan at stoneleaf.us  Sat Jul 18 00:11:59 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 17 Jul 2015 15:11:59 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
Message-ID: <55A97DAF.1000605@stoneleaf.us>

On 07/16/2015 11:30 PM, Nick Coghlan wrote:
> On 17 July 2015 at 08:30, Ben Finney wrote:

>> By definition, advocating to not add cruft to an API is going to be in
>> advance of being bitten by those additions.
>
> That's not what people are doing. Folks are actually arguing for
> *restoring* the ability to mock out method names starting with
> "assret_*".

Why is that surprising?  As somebody already mentioned (Terry, I think?) "assret" is a fine abbreviation, as well as possibly being a foreign word.

> I still don't know why anyone thinks restoring that would be a
> worthwhile use of a maintainers' time (or why they thinking arguing in
> favour of such a capability is a worthwhile use of theirs).

1) Because it shouldn't have been added in the first place.

2) Because DWIM does not belong in Python.

> None of the perspectives presented in this thread are new, although
> the apparent obsession over such a minor detail has made it abundantly
> clear that this kind of helper simply isn't worth the distraction it
> creates for maintainers, *regardless* of whether or not it helps end
> users.

To be clear:

   - those who are upset over "assret" are not upset over "assert"

   - it is not Python's job (nor the stdlib's) to correct spelling errors

--
~Ethan~

From solipsis at pitrou.net  Sat Jul 18 01:40:21 2015
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 18 Jul 2015 01:40:21 +0200
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us>
Message-ID: <20150718014021.59200f65@fsol>


Frankly, this kind of inept discussion, where a bunch of folks get hung
up about an extremely minor design decision (who cares whether "assret"
is being special-cased or not? in the actual world, not the fantasy
world of righteous indignation and armchair architects?), is amongst
the reasons why I'm stopping contributing to CPython.

Keep up the good work, you're making this place totally repulsive to
participate in. Every maintainer or contributor now has an army of
voluntary hair-splitters to bother about, most of whom probably aren't
relying on said functionality to begin with.

Regards

Antoine.



On Fri, 17 Jul 2015 15:11:59 -0700
Ethan Furman <ethan at stoneleaf.us> wrote:
> On 07/16/2015 11:30 PM, Nick Coghlan wrote:
> > On 17 July 2015 at 08:30, Ben Finney wrote:
> 
> >> By definition, advocating to not add cruft to an API is going to be in
> >> advance of being bitten by those additions.
> >
> > That's not what people are doing. Folks are actually arguing for
> > *restoring* the ability to mock out method names starting with
> > "assret_*".
> 
> Why is that surprising?  As somebody already mentioned (Terry, I think?) "assret" is a fine abbreviation, as well as possibly being a foreign word.
> 
> > I still don't know why anyone thinks restoring that would be a
> > worthwhile use of a maintainers' time (or why they thinking arguing in
> > favour of such a capability is a worthwhile use of theirs).
> 
> 1) Because it shouldn't have been added in the first place.
> 
> 2) Because DWIM does not belong in Python.
> 
> > None of the perspectives presented in this thread are new, although
> > the apparent obsession over such a minor detail has made it abundantly
> > clear that this kind of helper simply isn't worth 		the distraction it
> > creates for maintainers, *regardless* of whether or not it helps end
> > users.
> 
> To be clear:
> 
>    - those who are upset over "assret" are not upset over "assert"
> 
>    - it is not Python's job (nor the stdlib's) to correct spelling errors
> 
> --
> ~Ethan~




From rymg19 at gmail.com  Sat Jul 18 02:00:50 2015
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Fri, 17 Jul 2015 19:00:50 -0500
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150718014021.59200f65@fsol>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
Message-ID: <9CA047B0-213A-40F8-AFF2-E14896C9B2C1@gmail.com>

I am tempted to reply with a slightly sarcastic message involving a cookie...

On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>Frankly, this kind of inept discussion, where a bunch of folks get hung
>up about an extremely minor design decision (who cares whether "assret"
>is being special-cased or not? in the actual world, not the fantasy
>world of righteous indignation and armchair architects?), is amongst
>the reasons why I'm stopping contributing to CPython.
>
>Keep up the good work, you're making this place totally repulsive to
>participate in. Every maintainer or contributor now has an army of
>voluntary hair-splitters to bother about, most of whom probably aren't
>relying on said functionality to begin with.
>
>Regards
>
>Antoine.
>
>
>
>On Fri, 17 Jul 2015 15:11:59 -0700
>Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 07/16/2015 11:30 PM, Nick Coghlan wrote:
>> > On 17 July 2015 at 08:30, Ben Finney wrote:
>> 
>> >> By definition, advocating to not add cruft to an API is going to
>be in
>> >> advance of being bitten by those additions.
>> >
>> > That's not what people are doing. Folks are actually arguing for
>> > *restoring* the ability to mock out method names starting with
>> > "assret_*".
>> 
>> Why is that surprising?  As somebody already mentioned (Terry, I
>think?) "assret" is a fine abbreviation, as well as possibly being a
>foreign word.
>> 
>> > I still don't know why anyone thinks restoring that would be a
>> > worthwhile use of a maintainers' time (or why they thinking arguing
>in
>> > favour of such a capability is a worthwhile use of theirs).
>> 
>> 1) Because it shouldn't have been added in the first place.
>> 
>> 2) Because DWIM does not belong in Python.
>> 
>> > None of the perspectives presented in this thread are new, although
>> > the apparent obsession over such a minor detail has made it
>abundantly
>> > clear that this kind of helper simply isn't worth 		the distraction
>it
>> > creates for maintainers, *regardless* of whether or not it helps
>end
>> > users.
>> 
>> To be clear:
>> 
>>    - those who are upset over "assret" are not upset over "assert"
>> 
>>    - it is not Python's job (nor the stdlib's) to correct spelling
>errors
>> 
>> --
>> ~Ethan~
>
>
>
>_______________________________________________
>Python-Dev mailing list
>Python-Dev at python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150717/6e944564/attachment.html>

From breamoreboy at yahoo.co.uk  Sat Jul 18 02:08:03 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Sat, 18 Jul 2015 01:08:03 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <9CA047B0-213A-40F8-AFF2-E14896C9B2C1@gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <9CA047B0-213A-40F8-AFF2-E14896C9B2C1@gmail.com>
Message-ID: <moc5df$qhn$1@ger.gmane.org>

On 18/07/2015 01:00, Ryan Gonzalez wrote:
> I am tempted to reply with a slightly sarcastic message involving a
> cookie...

I'm not tempted, I will ask, what the hell are you on about?

>
> On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>
>     Frankly, this kind of inept discussion, where a bunch of folks get hung
>     up about an extremely minor design decision (who cares whether "assret"
>     is being special-cased or not? in the actual world, not the fantasy
>     world of righteous indignation and armchair architects?), is amongst
>     the reasons why I'm stopping contributing to CPython.
>
>     Keep up the good work, you're making this place totally repulsive to
>     participate in. Every maintainer or contributor now has an army of
>     voluntary hair-splitters to bother about, most of whom probably aren't
>     relying on said functionality to begin with.
>
>     Regards
>
>     Antoine.
>

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From ncoghlan at gmail.com  Sat Jul 18 02:11:18 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 18 Jul 2015 10:11:18 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <55A97DAF.1000605@stoneleaf.us>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us>
Message-ID: <CADiSq7f=xNcgT1rkRyjNO1UF0K+qW+A+s=8pW9JMAWzjSnyfoQ@mail.gmail.com>

On 18 Jul 2015 8:13 am, "Ethan Furman" <ethan at stoneleaf.us> wrote:
>
> On 07/16/2015 11:30 PM, Nick Coghlan wrote:
>
>> On 17 July 2015 at 08:30, Ben Finney wrote:
>
>
>>> By definition, advocating to not add cruft to an API is going to be in
>>> advance of being bitten by those additions.
>>
>>
>> That's not what people are doing. Folks are actually arguing for
>> *restoring* the ability to mock out method names starting with
>> "assret_*".
>
>
> Why is that surprising?  As somebody already mentioned (Terry, I think?)
"assret" is a fine abbreviation, as well as possibly being a foreign word.
>
>
>> I still don't know why anyone thinks restoring that would be a
>> worthwhile use of a maintainers' time (or why they thinking arguing in
>> favour of such a capability is a worthwhile use of theirs).
>
>
> 1) Because it shouldn't have been added in the first place.
>
> 2) Because DWIM does not belong in Python.

Then volunteer to do all of the work to revert the change yourself, or
offer to pay someone for it. Do NOT spend days nitpicking tiny details of
work that has already been done to the point where people are wondering why
they bother giving the gift of their time and contributions to our
community.

Core committers are core committers because we're willing to trust their
judgement in borderline design calls in their areas of expertise - the rest
of the role could be automated (and hopefully eventually will be). Once
they've made a decision, we have the entire internet to continue to voice
our dissatisfaction with the outcome, but incessantly repeating the same
points that were already considered in making the original decision
constitutes unwelcome noise on the core mailing lists.

Regards,
Nick.

>
>
>> None of the perspectives presented in this thread are new, although
>> the apparent obsession over such a minor detail has made it abundantly
>> clear that this kind of helper simply isn't worth the distraction it
>> creates for maintainers, *regardless* of whether or not it helps end
>> users.
>
>
> To be clear:
>
>   - those who are upset over "assret" are not upset over "assert"
>
>   - it is not Python's job (nor the stdlib's) to correct spelling errors
>
>
> --
> ~Ethan~
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150718/aa168ecb/attachment.html>

From ethan at stoneleaf.us  Sat Jul 18 02:30:23 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 17 Jul 2015 17:30:23 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7f=xNcgT1rkRyjNO1UF0K+qW+A+s=8pW9JMAWzjSnyfoQ@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>	<20150714134156.GB21874@ando.pearwood.info>	<mo3cjo$1eg$1@ger.gmane.org>	<CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>	<CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>	<55A8197F.1060500@stoneleaf.us>	<85lhefu8d7.fsf@benfinney.id.au>	<20150716231003.356b91b4@fsol>	<85h9p3u44c.fsf@benfinney.id.au>	<CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>	<55A97DAF.1000605@stoneleaf.us>
 <CADiSq7f=xNcgT1rkRyjNO1UF0K+qW+A+s=8pW9JMAWzjSnyfoQ@mail.gmail.com>
Message-ID: <55A99E1F.8070204@stoneleaf.us>

On 07/17/2015 05:11 PM, Nick Coghlan wrote:

> Do NOT spend days nitpicking tiny details of work that has already been done
> to the point where people are wondering why they bother giving the gift of
>  their time and contributions to our community.

You mean like you keep expressing dismay and surprise that people care about the language and don't want warts in it?

'Cause that's a real friendly attitude right there.

Don't worry, I'm done with this thread.

--
~Ethan~

From ben+python at benfinney.id.au  Sat Jul 18 02:39:17 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2015 10:39:17 +1000
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
Message-ID: <858uaepadm.fsf@benfinney.id.au>

Nick Coghlan <ncoghlan at gmail.com> writes:

> On 17 July 2015 at 08:30, Ben Finney <ben+python at benfinney.id.au> wrote:
> > By definition, advocating to not add cruft to an API is going to be in
> > advance of being bitten by those additions.
>
> That's not what people are doing. Folks are actually arguing for
> *restoring* the ability to mock out method names starting with
> "assret_*".

You're describing a fait accompli. That doesn't justify the changes to
get to that fait.

I'm pointing out that what you call a situation to be ?restored? is what
we've got now, and a change away from that ? to add a DWIM alias for one
typo, seemingly arbitrary among typos ? needs sufficient justification.

I'm also pointing out that clarity and similicity of API is sufficiently
important that there needs to be a strong benefit to justify moving away
from that.

> I still don't know why anyone thinks restoring that would be a
> worthwhile use of a maintainers' time (or why they thinking arguing in
> favour of such a capability is a worthwhile use of theirs).

Just as easily, I could express surprise that adding DWIM aliases for
some typos and not others has somehow been thought worthwhile of the
maintainers's time. But in neither case does that argue for or against,
so I don't think that's terribly germane to the discussion.

> None of the perspectives presented in this thread are new

Must they be new? I don't see how that matters. If they haven't been
adequately addressed, it shouldn't matter how new they are; they're
still salient objections to a change when it is announced.

-- 
 \         ?In any great organization it is far, far safer to be wrong |
  `\          with the majority than to be right alone.? ?John Kenneth |
_o__)                                            Galbraith, 1989-07-28 |
Ben Finney


From ncoghlan at gmail.com  Sat Jul 18 05:19:06 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 18 Jul 2015 13:19:06 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <858uaepadm.fsf@benfinney.id.au>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
Message-ID: <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>

On 18 Jul 2015 10:40 am, "Ben Finney" <ben+python at benfinney.id.au> wrote:
>
> Nick Coghlan <ncoghlan at gmail.com> writes:
>
> > On 17 July 2015 at 08:30, Ben Finney <ben+python at benfinney.id.au> wrote:
> > > By definition, advocating to not add cruft to an API is going to be in
> > > advance of being bitten by those additions.
> >
> > That's not what people are doing. Folks are actually arguing for
> > *restoring* the ability to mock out method names starting with
> > "assret_*".
>
> You're describing a fait accompli. That doesn't justify the changes to
> get to that fait.

NOTHING new has been added by this discussion - it is merely rehashing
arguments that were already considered when the original design decision
was made. Attempting to get our way through sheer volume is not acceptable
behaviour.

Courtesy attempts to explain have been met with endless nitpicking rather
than gratitude for explanation of the original decision.

I'm with Antoine in wondering why we even bother with contributing when the
thanks we can expect is for people to feel entitled to demand we spend
hours of our time debating trivial details while huge glaring problems like
the startup sequence and the core workflow tooling languish for lack of
time to work on them.

This change *doesn't really matter* in the grand scheme things, but would
require a non-zero amount of time and effort to reverse, so unless you're
offering one of the unittest maintainers a contract gig to change it back,
let it go.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150718/67b45090/attachment.html>

From robertc at robertcollins.net  Sat Jul 18 06:18:05 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Sat, 18 Jul 2015 16:18:05 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
Message-ID: <CAJ3HoZ11OHXFiPRSUzaiK-ETR5MpBApnYEtfuCq54aSjBTiTXg@mail.gmail.com>

On 18 July 2015 at 15:19, Nick Coghlan <ncoghlan at gmail.com> wrote:
>

> This change *doesn't really matter* in the grand scheme things, but would
> require a non-zero amount of time and effort to reverse, so unless you're
> offering one of the unittest maintainers a contract gig to change it back,
> let it go.

s/unittest/mock :). But yes.

Currently only Michael is listed under 'experts' in the devguide for
unittest.mock. I've taken up the baton to keep the backport up to
date, to keep the ecosystem healthy, but I've no specific plans to
hack on mock per se. .... I think we'd probably benefit from more
names there :) I know Kushal and Berker have been doing things in the
stdlib.

But there's a tonne of important work to do before worrying about
tweaking a patch which was peer reviewed and went through the entirely
normal development process to address a critical usability issue with
mock. Which, judging from this thread, a bunch of folk don't actually
understand in the first place. [I mean no disrespect here, but there
have been multiple explanations trying to cover the distinction about
what is actually going on, and I'm well over them].

So - folk interested in unittest.mock. If you want to help, going
through the 200 open issues in https://github.com/testing-cabal/mock,
starting with the oldest, assessing whether they are:
 - still relevant
 - present only in the backport (leave them where they are)
 - or in 3.6 as well (in which case open a new ticket at
https://bugs.python.org/ linked to the github issue, and either close
the github issue or label it upstream (or both)).

THAT would be valuable, and improve users experience of unittest.mock
[and mock] much more than making a_mock.assret_called_once *not
error*.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From stephen at xemacs.org  Sat Jul 18 06:34:19 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 18 Jul 2015 13:34:19 +0900
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150718014021.59200f65@fsol>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
Message-ID: <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>

Antoine Pitrou writes:

 > Frankly, this kind of inept discussion,

I think you misunderstand what's going on.  The people who advocate
removal of a gratuitous special case may lack your perspective, but
they're not incompetent to understand it.  Specifically, you have a
senior committer's perspective on practicality.  But that's nothing
that one imbibes with mother's milk, and worse, it's not the same from
project to project.  I applaud Nick's attempts to communicate his
perspective on Pythonic practicality, both for the feature itself and
for changing it "*right* now".

 > [...] is amongst the reasons why I'm stopping contributing to
 > CPython.

We'll miss your code.  But you're only one committer, even if you've
contributed more than the average amount.  On the other hand, Python
needs to *grow* the committer group beyond its current size, and
*some* such discussion is necessary for new committers' advancement to
"benevolent dictator for one PEP" level, which is also a pain point
IMHO.  This particular case is one of the most salient, because it
involves the application of one of the most difficult principles: "but
practicality beats purity".

I note that you are responding to Ethan, who recently had a couple of
useful PEPs approved and implemented, but it is my impression that he
does not yet consider himself a BD1P candidate.[1]  Contributers like
him should be cultivated and encouraged (even if discussion should be
redirected, see below), not stifled, because they are likely to be
involved in Python at a higher level in the future.  BTW, he's not the
only one in that situation (PEP author and/or subproject leader but
not quite willing to step up for BD1P) in this thread.

 > Every maintainer or contributor now has an army of voluntary
 > hair-splitters to bother about,

I think that's something worth improving.  Specifically, I suggest
that, just as Guido occasionally invokes cloture[2] on a thread, other
senior developers do so too, in their "areas of competence".  Those
areas may need some definition, but clearly in this case Michael is
competent to say "all right girls and boys, I heard you, I disagree,
and it's not going to change".  Of course he already did that, which
is enough for seasoned committers.  What I'm suggesting is that he
should add, "so please stop discussing the issue," as Guido does.
That makes the implication explicit to less-experienced participants,
as well as to those who usually know better but are carried away by
the momentum of the discussion<wink />.

It might also be appropriate to offer the option of asking for
rationale on core-mentorship, where people who have volunteered to
help would-be committers hang out.  (I guess that would be expanding
the mission of core-mentorship, though, so it's not a no-brainer.)

Of course this means that developers with "areas of competence" need
to pay more attention to such threads, and some will resist or not be
very good at it.  But if most do it, it should do wonders to improve
the efficiency of discussion and be a net saving of time for them as
well.  It would be nice if a few volunteered for these "how to
Pythonically resolve conflict of principles" discussions on core-
mentorship, too.

As python-ideas is also a list for "business" discussions, cloture
might usefully be applied there, too, although with more caution (more
seniority required for invoking[3] cloture?) since the latitude of
discussion is intentionally wider there.

Footnotes: 
[1]  With apologies to Ethan.  I don't speak for him, and my
impressions of him have no validity outside of the current context of
a discussion about cultivating developers.

[2]  https://en.wikipedia.org/wiki/Cloture
There are alternative spellings in that article.  I'm suggesting that
if the idea is adopted, one of the traditional spellings and some of
the properties of parliamentary cloture be sanctioned as Pythonic.
Eg, one aspect of cloture in many parliaments is that it can be
proposed by any member.  Here the implementation would be a frustrated
developer who writes to the "responsible committer" and requests that
he check discussion, and issue a ruling that the thread should end
right away.

[3]  N.B. This wording may be obscure or specific to my dialect.  To
me, "invoking cloture" means *imposing an end to discussion*, as
opposed to merely *proposing* to end it by force.  As in fn [1],
anybody can propose to invoke cloture as I see it.


From victor.stinner at gmail.com  Sat Jul 18 10:11:39 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sat, 18 Jul 2015 10:11:39 +0200
Subject: [Python-Dev]  How far to go with user-friendliness
In-Reply-To: <20150718014021.59200f65@fsol>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
Message-ID: <CAMpsgwY_yt-pC1fOv1e-q+9k14vZRnKifejmRsE3t--FjDO6Ng@mail.gmail.com>

Hi Antoine,

I'm really sad to read your message. Antoine is one of the most active
Python core developer and it would be a big loss if he really stops
contributing. Antoine helped me to stop the drug called "micro
optimization", he always has good advices on the Python development.

I tried to stay away the discussion on mock, but it's hard because it is
flooding my mailbox. I had to use mox (moX, not moCK) and I don't like its
API. I really like mock API, it's natural and obvious.

When mock 1.1 was released, many people complained because "it broke
OpenStack (CI)". A few days later i unerstood that raising an error for
unkown methods with a name starting with "assert" is a good thing. It
helped to fix a lot a bugs in OpenStack tests!

For the discussion on "assret", I'm surprised how much people replied. The
mock maintainer, Michael Foord, replied: it was an explicit request from
users...

Victor

Le samedi 18 juillet 2015, Antoine Pitrou <solipsis at pitrou.net> a ?crit :

>
> Frankly, this kind of inept discussion, where a bunch of folks get hung
> up about an extremely minor design decision (who cares whether "assret"
> is being special-cased or not? in the actual world, not the fantasy
> world of righteous indignation and armchair architects?), is amongst
> the reasons why I'm stopping contributing to CPython.
>
> Keep up the good work, you're making this place totally repulsive to
> participate in. Every maintainer or contributor now has an army of
> voluntary hair-splitters to bother about, most of whom probably aren't
> relying on said functionality to begin with.
>
> Regards
>
> Antoine.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150718/af53d0f9/attachment.html>

From larry at hastings.org  Sat Jul 18 12:24:21 2015
From: larry at hastings.org (Larry Hastings)
Date: Sat, 18 Jul 2015 03:24:21 -0700
Subject: [Python-Dev] Reminder: Python 3.5 beta 4 is tagged in one week
Message-ID: <55AA2955.8030404@hastings.org>



Approximately a week from when I post this, I'll be tagging Python 3.5 
beta 4, which is the last beta before we go to release candidates.  
Please wind up all your bug fixes soon, I'd really like checkins to 3.5 
to stop soon.

And a minor reminder: when we hit Release Candidate 1, I'll be switching 
the canonical repo for 3.5 to a public Bitbucket repo. Any bug fixes 
that go in between RC 1 and final will only be merged using Bitbucket 
"pull requests".

The new workflow experiment continues,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150718/786fe9b2/attachment.html>

From stefan at bytereef.org  Sat Jul 18 13:06:37 2015
From: stefan at bytereef.org (s.krah)
Date: Sat, 18 Jul 2015 11:06:37 +0000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>



---- Ein Sa, 18 Jul 2015 04:34:19 +0000 Stephen J. Turnbull &lt;stephen at xemacs.org&gt; hat geschrieben ---- 

Antoine Pitrou writes: 
 &gt; [...] is amongst the reasons why I'm stopping contributing to 
 &gt; CPython. 
 
&gt; We'll miss your code. But you're only one committer, even if you've 
&gt; contributed more than the average amount. On the other hand, Python 
&gt; needs to *grow* the committer group beyond its current size, and 
&gt; *some* such discussion is necessary for new committers' advancement to 
&gt; "benevolent dictator for one PEP" level, which is also a pain point 
&gt; IMHO.

I don't think growing committer numbers is CPython's #1 problem. CPython
needs *relevant*contributions:  Hypothetically speaking, I'd wager that
someone writing an industrial strength concurrent garbage collector is
*far more likely* to share Antoine's attitude.

ALL developer's who fall into that category are being put off by the
current climate on python-dev and python-ideas, and there's no
shortage of other languages to contribute to.

Likewise, I don't think PEPs are the problem either: Python already has
too many features (recently I found myself thinking that C++ is a really
nice small language :).


Stefan Krah


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150718/7fe60c3e/attachment.html>

From stephen at xemacs.org  Sat Jul 18 14:47:54 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 18 Jul 2015 21:47:54 +0900
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
Message-ID: <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>

s.krah writes:

 > I don't think growing committer numbers is CPython's #1 problem.

Maybe not; not being a committer I don't have a strong opinion myself.
However, committers, and especially the group qualified for the BD1P
role, regularly post wishes for more senior developers to these lists.

 > Hypothetically speaking, I'd wager that someone writing an
 > industrial strength concurrent garbage collector is *far more
 > likely* to share Antoine's attitude.

I hope not.  It's one thing to wish that one can be surrounded by
peers with compatible workflows.  It's another to address those who
aren't one's peers with words like "keep up the good work, it's people
like you that make this a repulsive place to be."  (That may not be an
exact quote but it's in the same spirit.)

 > All developer's who fall into that category are being put off by the
 > current climate on python-dev and python-ideas, and there's no
 > shortage of other languages to contribute to.

And you propose to do what about that?  I made a concrete proposal (a
cloture rule) that would be an improvement.  It has precedent from
Guido himself.

It's not a panacea, of course, but AFAIK the committers in general
still prefer an open community; closing the lists or asking
non-committers or non-module-owners or whatever to be "seen and not
heard" is not going to get support.  So I don't think there is a
panacea.  It's unfortunate if that means some senior developers decide
to leave, but senior developers do leave projects occasionally for a
variety of reasons.  All the more reason to cultivate an environment
where new people feel free to join and participate, IMO, YMMV.

For senior developers in a community as large as Python's, with a code
base to match, to continue to get value from participation, they're
going to need to have a bit of noblesse oblige in their makeup.  In
that sense, senior developers in Python are victims of its success.

 > Likewise, I don't think PEPs are the problem either:

I'm sorry, I wasn't clear.  The point is not a need to produce and
approve more PEPs, or even commits.  It's having more people at the
levels where they're *qualified* for commit rights or the BD1P role.
Those are the people who make it fun for each other to keep working on
a large, mature project where curating existing code is a large
burden.  Partly because they're fun and productive to work with, and
partly because they can share the burden of maintenance.

Regards,

From stefan at bytereef.org  Sat Jul 18 16:16:28 2015
From: stefan at bytereef.org (s.krah)
Date: Sat, 18 Jul 2015 14:16:28 +0000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
 <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>



Stephen J. Turnbull &lt;stephen at xemacs.org&gt; wrote:

 &gt;&gt; Hypothetically speaking, I'd wager that someone writing an 
 &gt;&gt; industrial strength concurrent garbage collector is *far more 
 &gt;&gt; likely* to share Antoine's attitude. 
 
&gt; I hope not. It's one thing to wish that one can be surrounded by 
&gt; peers with compatible workflows. It's another to address those who 
&gt; aren't one's peers with words like "keep up the good work, it's people 
&gt; like you that make this a repulsive place to be." (That may not be an 
&gt; exact quote but it's in the same spirit.) 

Sorry, that amounts to twisting my words. An attitude is a general way of
approaching things and I meant it in a positive way.

I haven't read the flame you're alluding to, but an occasional flame is NOT
the defining characteristic of a person.

On the contrary, on the bug-tracker Antoine has been most helpful,
responsive and welcoming towards newcomers.


It would be a great loss if he really stops and I hope he'll reconsider.


Stefan Krah






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150718/8fbb377b/attachment.html>

From stephen at xemacs.org  Sat Jul 18 17:35:05 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 19 Jul 2015 00:35:05 +0900
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
 <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>
Message-ID: <87vbdheaxi.fsf@uwakimon.sk.tsukuba.ac.jp>

s.krah writes:

 > Sorry, that amounts to twisting my words.

Let's not play the dozens here.  That just extends the thread to no
point.

 > It would be a great loss if he really stops and I hope he'll
 > reconsider.

I agree with both points.  I don't think anybody disagrees, so let's
not belabor them, either -- after all, the point here is that people
keep posting about things that don't help solve real problems.

I have two proposals on the table ("cloture" and "redirect people
dissatisfied with the offered rationale to a more appropriate channel
for discussion").  Perhaps we could discuss those, or propose
additional or better ways to improve the situation, or a better
channel for this "meta" discussion itself?  After Nick's post, I think
there's no denying that Antoine has plenty of company in frustration
-- there is a systematic problem here.

Regards,

From ezio.melotti at gmail.com  Sat Jul 18 18:01:13 2015
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 18 Jul 2015 19:01:13 +0300
Subject: [Python-Dev] cpython: Tighten-up code in the set iterator to
 use an entry pointer rather than
In-Reply-To: <CAP7+vJJn=n+WnGWCFXVtqDJgvmpkAXmPi4oKbkhigHnG-aXt_Q@mail.gmail.com>
References: <20150707020307.11325.89553@psf.io> <mnfvtk$anv$1@ger.gmane.org>
 <E833D117-AD92-4B12-9E5E-24D7BC378234@gmail.com>
 <mnk0jm$cot$1@ger.gmane.org>
 <CAP7+vJJn=n+WnGWCFXVtqDJgvmpkAXmPi4oKbkhigHnG-aXt_Q@mail.gmail.com>
Message-ID: <CACBhJdHCeYAKWd9AhvaF7vNjAE=9mmXEFXoMm8B+Fnb0+CNwVg@mail.gmail.com>

On Thu, Jul 9, 2015 at 3:41 PM, Guido van Rossum <guido at python.org> wrote:
> On Wed, Jul 8, 2015 at 10:19 PM, Serhiy Storchaka <storchaka at gmail.com>
> wrote:
>>
>> On 08.07.15 01:45, Raymond Hettinger wrote:
>>>
>>> P.S.  I don't think python-dev post was necessary or helpful (and I still
>>> haven't had a chance to read the whole thread).  It would have been
>>> sufficient to assign the tracker entry back to me.
>>
>>
>> Well, I'll open new issue and assign it to you for every your commit that
>> looks questionable to me.
>
>
> That sounds like a fine solution, and a good conclusion of the thread.
>

Whenever I have a non-trivial commit to do, I create a patch and
upload it to the tracker, with an explanation of the problem and the
solution.  If after a few days no one commented, I commit it and close
the issue.

If a problem arises post-commit, people can reopen the issue and
comment there.  Since the issue number is included in all the commits,
it is also easy to find related discussions.

Creating an issue after the fact is an acceptable solution too, but I
would prefer to see an issue before the commit.

FWIW I only consider simple documentation issues and typo/whitespace
fixes as "trivial", YMMV.

Best Regards,
Ezio Melotti


> --
> --Guido van Rossum (python.org/~guido)
>

From ncoghlan at gmail.com  Sun Jul 19 02:13:00 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 19 Jul 2015 10:13:00 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
Message-ID: <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>

On 18 Jul 2015 1:19 pm, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> I'm with Antoine in wondering why we even bother with contributing when
the thanks we can expect is for people to feel entitled to demand we spend
hours of our time debating trivial details

Sorry, I crossed a line there - I know everyone posting to this thread is
doing so with the best interests of Python at heart.

I also know that from the questioners' side this kind of thread feels like
a perfectly reasonable request for further explanation. However, from the
core developer side, some folks are averaging more than 3 commits a day,
and we have the ever looming presence of almost *five thousand* open issues
that we haven't had the opportunity to address (I'm personally on the nosy
list for more than 400 of them).

Whenever someone offers a patch to address one of those issues, we have to
decide how fussy we want to be - every time we say "No, that's not ready
yet", there's a chance other priorities will come up for the contributor
(even when it's another core developer) that mean we end up with a patch
languishing on the tracker with unaddressed feedback rather than a resolved
issue.

As a result, the question asked about potential changes isn't generally "Is
this perfect?" but rather "Is this usable, maintainable, complete and an
improvement over the status quo?".

If a contribution passes that *second* barrier, then it's likely to be
accepted. This is also the standard we'll apply to *ourselves* in deciding
whether or not we'd like a pre-commit review on a particular change.

This means the kind of question raised in this thread has a standard
answer: the change was made because the contributor addressing the issue
wanted to address it that way, and the core developer committing the change
was willing to accept public responsibility for any *actual* (as opposed to
hypothetical) long term harm arising from the decision.

We can sometimes construct an after-the-fact rationalisation, but honestly,
it usually comes down to asking ourselves the question "Am I prepared to
reject this improvement entirely over that one potentially controversial
aspect?" and deciding that we'd prefer to accept the long term technical
risk over the near term social risk of potentially alienating the patch
author.

The *problem* with threads like this one is that they end up feeling like
punishment for being accommodating to the wishes of contributors on minor
design details. The end result of such a process isn't a better CPython -
it's *higher* barriers to contribution and *more* unresolved issues, as
core developers become ever more reluctant to accept responsibility for
contributed changes that may in any way be controversial.

Potential core developers are also likely to be put off by the prospect of
"you too can volunteer to be micromanaged by a large community mailing
list, doesn't that sound like fun?"

Review throughput is our primary bottleneck in getting fixes and
enhancements into CPython. While tooling improvements can help us make
better use of the time of the core developers we already have, and better
track and acknowledge the efforts of potential future core developers, the
reasons folks *quit* are social ones, as are the reasons folks get
discouraged from contributing in the first place.

That's the tension at the heart of open source development - every time we
object to someone else's decision or reject their work, we run the risk of
contributing to one of our peers deciding to stop volunteering their time
and energy. We run the same risk every time we use our control over
infrastructure and tools to enforce a change in process and practices.

Not taking those risks isn't the answer - that's a recipe for stagnation,
rather than continuous improvement. Rather, we want to be taking those
risks deliberately and consciously, having already asked ourselves "If this
is the final straw in someone deciding that contributing to our community
isn't a worthwhile use of their time, am I prepared to accept that
responsibility over this particular topic?".

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150719/212c77a2/attachment.html>

From stefan at bytereef.org  Sun Jul 19 11:22:44 2015
From: stefan at bytereef.org (s.krah)
Date: Sun, 19 Jul 2015 09:22:44 +0000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <87vbdheaxi.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
 <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>
 <87vbdheaxi.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <14ea59a0720.b0c7f043604411.3660687318231351792@bytereef.org>



---- Ein Sa, 18 Jul 2015 15:35:05 +0000 Stephen J. Turnbull &lt;stephen at xemacs.org&gt; hat geschrieben ---- 

s.krah writes: 
 
 &gt;&gt; Sorry, that amounts to twisting my words. 
 
&gt; Let's not play the dozens here. That just extends the thread to no 
point.

Indeed.  I'll just filter you from now on.


Stefan Krah 
 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150719/58ac777b/attachment.html>

From murashev_vitaly at mail.ru  Sun Jul 19 14:10:23 2015
From: murashev_vitaly at mail.ru (=?UTF-8?B?Vml0YWx5IE11cmFzaGV2?=)
Date: Sun, 19 Jul 2015 15:10:23 +0300
Subject: [Python-Dev] =?utf-8?q?GetFinalPathNameByHandleW_-_what_is_the_mi?=
 =?utf-8?q?nimum_windows_version_python-3=2E5_will_support_=3F?=
Message-ID: <1437307823.11841681@f409.i.mail.ru>

 I've just found out that that on Windows internal implementation of python35.dll in posixmodule.c
uses winapi function GetFinalPathNameByHandleW

By the way from MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx

Minimum supported client
? Windows Vista [desktop apps only]

Minimum supported server
? Windows Server 2008 [desktop apps only]

Does it mean, that Python-3.5 doesn't support any windows versions prior "Windows Vista" and "Windows Server 2008" ?

Best regards,
Vitaly Murashev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150719/3f7f949c/attachment.html>

From mail at timgolden.me.uk  Sun Jul 19 15:51:54 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Sun, 19 Jul 2015 14:51:54 +0100
Subject: [Python-Dev] GetFinalPathNameByHandleW - what is the minimum
 windows version python-3.5 will support ?
In-Reply-To: <1437307823.11841681@f409.i.mail.ru>
References: <1437307823.11841681@f409.i.mail.ru>
Message-ID: <55ABAB7A.7080605@timgolden.me.uk>



On 19/07/2015 13:10, Vitaly Murashev wrote:
> I've just found out that that on Windows internal implementation of
> python35.dll in posixmodule.c
> uses winapi function GetFinalPathNameByHandleW
>
> By the way from MSDN:
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx
>
> Minimum supported client
>    Windows Vista [desktop apps only]
>
> Minimum supported server
>    Windows Server 2008 [desktop apps only]
>
> Does it mean, that Python-3.5 doesn't support any windows versions prior
> "Windows Vista" and "Windows Server 2008" ?

In essence: yes.

Python's support for Windows is outlined in PEP 11:

   https://www.python.org/dev/peps/pep-0011/#microsoft-windows

which establishes that Python drops support for a Windows platform when 
Microsoft does. WinXP (somewhat noisily) finished support last year:

   http://windows.microsoft.com/en-gb/windows/end-support-help

while Server 2003 -- more quietly; I had to go and look -- came out of 
extended support this month:

   https://support.microsoft.com/en-us/lifecycle?p1=3198

Since Python 3.5 will come out after both of those platforms have 
finished support, there's no guarantee that it will run without error on 
those systems.

Obviously, all earlier releases of Python -- including the 
long-term-supported 2.7 should continue to work. Any otherwise 
undocumented failure to work on older platforms should be raised as a bug.

TJG

From ron3200 at gmail.com  Sun Jul 19 17:17:10 2015
From: ron3200 at gmail.com (Ron Adam)
Date: Sun, 19 Jul 2015 11:17:10 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150717014851.2813b7bf@fsol>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <20150717014851.2813b7bf@fsol>
Message-ID: <mogf1n$341$1@ger.gmane.org>



On 07/16/2015 07:48 PM, Antoine Pitrou wrote:
> On Fri, 17 Jul 2015 11:35:53 +1200
> Alexander<xr.lists at gmail.com>  wrote:
>> >
>> >I do not want to read mistyped code from other developers and try to
>> >guess whether it will work properly or not.

> You don't have to guess anything. If it's mistyped, either it raises
> AttributeError (because it starts with "assert_"), or it doesn't do
> anything. So, in both cases, it*doesn't*  work properly.

I had to look at the source to figure out what this thread was really all 
about.

Basically it looks to me the purpose of adding "assret" is to add an "alias 
check" for "unsafe" methods.  It doesn't actually add an "alias".  It 
allows a developer to use a valid alias to avoid conflicting with methods 
starting with assert that will still work with the mock module.

The mock module says that when "unsafe" flag is set to True, it will not 
raise AssertionError for methods beginning with "assert" and "assret".  It 
doesn't specify what "unsafe" means, and why you would want to do that.

So first do this...

     * Document "unsafe" in mock module.

I presume "unsafe" in this case means the method will not fail if an 
optimise flag is used because an assert in an assert method will not fail.

The problem I see is checking for "assert" by name convention is dubious to 
start with.  An method that begins with assert may not actually use 
"assert", and one's that don't may possibly use it.

A better way is to have a function in the inspect module that will return 
True if a function uses the "assert" keyword.

That is trickier than it sounds, because the optimize flag causes the 
asserts to be removed.  So it may require setting a flag on a function if 
it's source contained "assert".

With a reliable test for "assert", the check for an naming convention alias 
is not needed.


If I've still not quite got the gist of this issue, the please correct me.

Cheers,
     Ron























From ethan at stoneleaf.us  Sun Jul 19 17:52:13 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sun, 19 Jul 2015 08:52:13 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
Message-ID: <55ABC7AD.4020109@stoneleaf.us>

On 07/18/2015 05:13 PM, Nick Coghlan wrote:

> However, from the core developer side [...]

Participants              Core Dev?     Position on "assret"
----------------------    -----------   --------------------
Dima Tismek               no            -1
Xavier Morel              no            -1
Florian Bruhin            no             ?
Mark Lawrence             no            ?
Stephen J. Turnbull       no            -.5 (?)
Alexander                 no            -1
David Mertz               no            -1
Ron Adam                  no            ?
Christie Wilson           no            +1 (?)
Ben Finney                no            -1
Isaac Schwabacher         no            -1
MRAB                      ?*            -0 (?)

Michael Foord             yes           +1
Antoine Pitrou            yes           +1
Victor Stinner            yes           +1 (?)
Nick Coghlan              yes           +1
Paul Moore                yes           +0
A.M. Kuchling             yes           -0
Robert Collins            yes           -1
Brett Canon               yes           -.5 (?)
Berker Peksa?             yes           -.5 (?)
Steven D'Aprano           yes           -1
Barry Warsaw              yes           -.5 (?)
Ethan Furman              yes           -1

Looks like this thread was pretty evenly split between core devs and non-core devs.

Looks like a definite majority of non-core devs, and at least a slight majority of core devs, think "assret" should be removed.

Apparently you do not speak for all core devs on this issue, so please don't pretend that you do.

Oh, and just a small tidbit of info -- it took longer to research and write this email than it did to write the patch to remove "assret" checking [1].

Seems to me a lot of fuss could have been avoided by just acknowledging that a mistake may have been made, and asking for patches if anybody cared enough about it.

--
~Ethan~


[1] http://bugs.python.org/issue24656

From ethan at stoneleaf.us  Sun Jul 19 17:53:45 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sun, 19 Jul 2015 08:53:45 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAMpsgwY_yt-pC1fOv1e-q+9k14vZRnKifejmRsE3t--FjDO6Ng@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <CAMpsgwY_yt-pC1fOv1e-q+9k14vZRnKifejmRsE3t--FjDO6Ng@mail.gmail.com>
Message-ID: <55ABC809.9050604@stoneleaf.us>

On 07/18/2015 01:11 AM, Victor Stinner wrote:

> For the discussion on "assret", I'm surprised how much people replied. The mock maintainer,
>  Michael Foord, replied: it was an explicit request from users...

Users ask for lots of things that don't make it into the stdlib.

--
~Ethan~

From ethan at stoneleaf.us  Sun Jul 19 17:58:09 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sun, 19 Jul 2015 08:58:09 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <14ea59a0720.b0c7f043604411.3660687318231351792@bytereef.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
 <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>
 <87vbdheaxi.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea59a0720.b0c7f043604411.3660687318231351792@bytereef.org>
Message-ID: <55ABC911.2060003@stoneleaf.us>

On 07/19/2015 02:22 AM, s.krah wrote:
> ---- Ein Sa, 18 Jul 2015 15:35:05 +0000 *Stephen J. Turnbull hat geschrieben ----
>> s.krah writes:

>>> Sorry, that amounts to twisting my words.
>>
>> Let's not play the dozens here.  That just extends the thread to no point.
>
> Indeed.  I'll just filter you from now on.

You may as well filter me too, then, because you are acting like an ass and I'm saying so.

--
~Ethan~

From ron3200 at gmail.com  Sun Jul 19 18:52:17 2015
From: ron3200 at gmail.com (Ron Adam)
Date: Sun, 19 Jul 2015 12:52:17 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <55ABC7AD.4020109@stoneleaf.us>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
 <55ABC7AD.4020109@stoneleaf.us>
Message-ID: <mogkk2$l44$1@ger.gmane.org>



On 07/19/2015 11:52 AM, Ethan Furman wrote:
> Seems to me a lot of fuss could have been avoided by just acknowledging
> that a mistake may have been made, and asking for patches if anybody cared
> enough about it.

I'm not sure it's a mistake, but it may not be the best way to do what the 
"alias check" does.   That is, check for "unsafe" methods that may use 
"assert" in methods that start with assert or assret.  It's a name 
convention check only.

The use of "assret" may be because a developer used it in place of assert 
for a large project to avoid overwriting inherited methods accidentally and 
asked for it.  (that was suggested in this thread at one point.)  But I'm 
not able to confirm that.  It does sound reasonable though.  The check for 
it doesn't auto correct anything or alter anything outside of how the mock 
responds to existing methods. So it's not as bad as it sounds.  (But not as 
good either.)

A possibly better alternative is to have a different way to check if 
functions and methods use "assert".  Then the check by name convention 
(which is not dependable anyway) isn't needed.

Possibly adding a function, uses_assert(...), to the inspect module would 
be good.   To allow that to work, may need a flag set on function objects 
if they contain assert even if the module is compiled in optimise mode. 
(Is it doable?  Or maybe there is another way?)

Cheers,
    Ron








From tjreedy at udel.edu  Sun Jul 19 20:11:19 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 19 Jul 2015 14:11:19 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <55ABC7AD.4020109@stoneleaf.us>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
 <55ABC7AD.4020109@stoneleaf.us>
Message-ID: <mogp8t$ph4$1@ger.gmane.org>

On 7/19/2015 11:52 AM, Ethan Furman wrote:
> On 07/18/2015 05:13 PM, Nick Coghlan wrote:
>
>> However, from the core developer side [...]
>
> Participants              Core Dev?     Position on "assret"
> ----------------------    -----------   --------------------
> Dima Tismek               no            -1
> Xavier Morel              no            -1
> Florian Bruhin            no             ?
> Mark Lawrence             no            ?
> Stephen J. Turnbull       no            -.5 (?)
> Alexander                 no            -1
> David Mertz               no            -1
> Ron Adam                  no            ?
> Christie Wilson           no            +1 (?)
> Ben Finney                no            -1
> Isaac Schwabacher         no            -1
> MRAB                      ?*            -0 (?)
>
> Michael Foord             yes           +1
> Antoine Pitrou            yes           +1
> Victor Stinner            yes           +1 (?)
> Nick Coghlan              yes           +1
> Paul Moore                yes           +0
> A.M. Kuchling             yes           -0
> Robert Collins            yes           -1
> Brett Canon               yes           -.5 (?)
> Berker Peksa?             yes           -.5 (?)
> Steven D'Aprano           yes           -1
> Barry Warsaw              yes           -.5 (?)
> Ethan Furman              yes           -1

   Terry Reedy               yes           -1

> Looks like this thread was pretty evenly split between core devs and
> non-core devs.
>
> Looks like a definite majority of non-core devs, and at least a slight
> majority of core devs, think "assret" should be removed.
>
> Apparently you do not speak for all core devs on this issue, so please
> don't pretend that you do.

To be fair, I think Nick was speaking from the viewpoint of a core-dev 
who volunteers to review, edit, and commit a patch, and spends at least 
an hour doing so.  I do not believe he was pretending to speak for us 
collectively as post-commit reviewers.

> Oh, and just a small tidbit of info -- it took longer to research and
> write this email than it did to write the patch to remove "assret"
> checking [1].
>
> Seems to me a lot of fuss could have been avoided by just acknowledging
> that a mistake may have been made, and asking for patches if anybody
> cared enough about it.

I agree, and considered posting something nearly identical, but I was 
not ready to volunteer a patch.

Given that the issue is one of only partial reversion, and that a new 
patch would therefore be needed, I also think that some fuss would have 
been avoided if one of the initial objectors had done what you did, or 
volunteered to write a new patch, or had at least acknowledged that 
someone other than Michael could and should write the proposed new patch.

To me, the important issue is this: none of the people listed above are 
'stupid', and little of what we say seriously is 'stupid'.  Ditto for 
similar adjectives.  We should therefore give each other the benefit of 
the doubt (more than currently) when responding.

Bad: the patch (or in this case, a portion of it) is stupid.

Good (or certainly much better): I do not understand the rationale, or 
consider it inadequate.  It makes me queasy.  It looks like a step 
toward uglifying Python.

Bad: the objections to the patch are stupid.

Good (or certainly much better): <I think Nick already tried to fill in 
this blank>

-- 
Terry Jan Reedy



From tjreedy at udel.edu  Sun Jul 19 20:31:38 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 19 Jul 2015 14:31:38 -0400
Subject: [Python-Dev] GetFinalPathNameByHandleW - what is the minimum
 windows version python-3.5 will support ?
In-Reply-To: <55ABAB7A.7080605@timgolden.me.uk>
References: <1437307823.11841681@f409.i.mail.ru>
 <55ABAB7A.7080605@timgolden.me.uk>
Message-ID: <mogqeu$boq$1@ger.gmane.org>

On 7/19/2015 9:51 AM, Tim Golden wrote:
>
>
> On 19/07/2015 13:10, Vitaly Murashev wrote:
>> I've just found out that that on Windows internal implementation of
>> python35.dll in posixmodule.c
>> uses winapi function GetFinalPathNameByHandleW
>>
>> By the way from MSDN:
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx
>>
>>
>> Minimum supported client
>>    Windows Vista [desktop apps only]
>>
>> Minimum supported server
>>    Windows Server 2008 [desktop apps only]
>>
>> Does it mean, that Python-3.5 doesn't support any windows versions prior
>> "Windows Vista" and "Windows Server 2008" ?

There was a similar question on python-list about 3.5.0b3 not installing 
on XP.  This is at least the second of what will be many similar questions.

> In essence: yes.
>
> Python's support for Windows is outlined in PEP 11:
>
>    https://www.python.org/dev/peps/pep-0011/#microsoft-windows
>
> which establishes that Python drops support for a Windows platform when
> Microsoft does. WinXP (somewhat noisily) finished support last year:
>
>    http://windows.microsoft.com/en-gb/windows/end-support-help

I knew this part.

> while Server 2003 -- more quietly; I had to go and look -- came out of
> extended support this month:
>
>    https://support.microsoft.com/en-us/lifecycle?p1=3198

I was not aware of this.

> Since Python 3.5 will come out after both of those platforms have
> finished support, there's no guarantee that it will run without error on
> those systems.

I think this line in the PEP, "Because of this policy, no further 
Windows releases need to be listed in this PEP. " is false economy. 
Your research on server 2003 should be recorded. (The presence of a 3.5 
Server 2003 buildbot, even though not working, might lead one to the 
opposite answer.) Even if users ignore the PEP, people answering 
questions (like me) try to use it to get definitive answers.

-- 
Terry Jan Reedy


From me at the-compiler.org  Sun Jul 19 20:33:55 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sun, 19 Jul 2015 20:33:55 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <mogf1n$341$1@ger.gmane.org>
References: <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <20150717014851.2813b7bf@fsol> <mogf1n$341$1@ger.gmane.org>
Message-ID: <20150719183355.GP18503@tonks>

* Ron Adam <ron3200 at gmail.com> [2015-07-19 11:17:10 -0400]:
> I had to look at the source to figure out what this thread was really all
> about.
> 
> Basically it looks to me the purpose of adding "assret" is to add an "alias
> check" for "unsafe" methods.  It doesn't actually add an "alias".  It allows
> a developer to use a valid alias to avoid conflicting with methods starting
> with assert that will still work with the mock module.
> 
> The mock module says that when "unsafe" flag is set to True, it will not
> raise AssertionError for methods beginning with "assert" and "assret".  It
> doesn't specify what "unsafe" means, and why you would want to do that.
> 
> So first do this...
> 
>     * Document "unsafe" in mock module.

The issue is that Mock objects (if not using spec/autospec) allow
*any* method to be called, and return another mock:

    >>> m = mock.Mock()
    >>> m.foo()
    <Mock name='mock.foo()' id='140277502245632'>

But they *also* have some special methods to check if they have been
called:

    >>> m.assert_called_with()
    [...]
    AssertionError: Expected call: mock()
    Not called

But if you do a typo, the test silently doesn't fail (because it's returning a
new mock instead of checking if it has been called):

    >>> m.assert_called()
    <Mock name='mock.assert_called()' id='140277467876152'>

With the patch, everything starting with "assert" or "assret" (e.g. my
example above) raises an AttributeError so these kind of issues can't
happen.

The thing people are discussing about is whether this should also
happen if you do "m.assret_called_with()" (i.e. if this is a common
enough typo to warrant a special exception), or if *only* things
starting with assert_* are checked.

The merged patch also treats "assret_*" as a typo, and some people
think this is a wart/unnecessary/harmful and only "assert_*" should
raise an AttributionError, i.e. the patch should be amended/reverted.

> I presume "unsafe" in this case means the method will not fail if an
> optimise flag is used because an assert in an assert method will not fail.
> 
> The problem I see is checking for "assert" by name convention is dubious to
> start with.  An method that begins with assert may not actually use
> "assert", and one's that don't may possibly use it.
> 
> A better way is to have a function in the inspect module that will return
> True if a function uses the "assert" keyword.
> 
> That is trickier than it sounds, because the optimize flag causes the
> asserts to be removed.  So it may require setting a flag on a function if
> it's source contained "assert".
> 
> With a reliable test for "assert", the check for an naming convention alias
> is not needed.
> 
> 
> If I've still not quite got the gist of this issue, the please correct me.

This has nothing to do with the assert *keyword* or optimization -
only with the behaviour of mock and its "assert_*" methods.

I hope this clears things up!

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150719/2fb2deae/attachment-0001.sig>

From ethan at stoneleaf.us  Sun Jul 19 22:33:32 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sun, 19 Jul 2015 13:33:32 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <mogp8t$ph4$1@ger.gmane.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
 <55ABC7AD.4020109@stoneleaf.us> <mogp8t$ph4$1@ger.gmane.org>
Message-ID: <55AC099C.20201@stoneleaf.us>

On 07/19/2015 11:11 AM, Terry Reedy wrote:

> Given that the issue is one of only partial reversion, and that a new patch would
> therefore be needed, I also think that some fuss would have been avoided if one of
> the initial objectors had done what you did, or volunteered to write a new patch,
>  or had at least acknowledged that someone other than Michael could and should write
>  the proposed new patch.

I was waiting for somebody to say "Patches welcome" -- so far every patch I have submitted (or reviewed and enhanced) for other parts of Python have been rejected (and I fully expect this one to be as 
well :(  -- I'm just waiting for Raymond to chime in and give it the coup de gr?ce).

--
~Ethan~

From brett at python.org  Sun Jul 19 23:06:08 2015
From: brett at python.org (Brett Cannon)
Date: Sun, 19 Jul 2015 21:06:08 +0000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <55ABC911.2060003@stoneleaf.us>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
 <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>
 <87vbdheaxi.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea59a0720.b0c7f043604411.3660687318231351792@bytereef.org>
 <55ABC911.2060003@stoneleaf.us>
Message-ID: <CAP1=2W6YWvVXEkVQ2hbUeig49vR8cNDMN3PPLamxR=WvfgQezw@mail.gmail.com>

On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman <ethan at stoneleaf.us> wrote:

> On 07/19/2015 02:22 AM, s.krah wrote:
> > ---- Ein Sa, 18 Jul 2015 15:35:05 +0000 *Stephen J. Turnbull hat
> geschrieben ----
> >> s.krah writes:
>
> >>> Sorry, that amounts to twisting my words.
> >>
> >> Let's not play the dozens here.  That just extends the thread to no
> point.
> >
> > Indeed.  I'll just filter you from now on.
>
> You may as well filter me too, then, because you are acting like an ass
> and I'm saying so.


Is the name calling really necessary? Couldn't you have just as easily said
that you disapproved of Stephen K's attitude without calling him an ass?
Same goes for Stephen K's comment where he could have stated he was simply
going to ignore Stephen T and be less snippy about it. There are ways to
get the point across just as strongly without resorting to this sort of
stuff.

This whole thread has shown two problems we have on this list. One is the
occasional name calling and bad attitude that we let slide in the name of
blowing off steam or something. We are all adults here and can get the
point across that we disapprove of something without resorting to
playground antics. Plus emails can be delayed until cooler heads prevail.
It's this kind of thing that leads to the need of a CoC for this list and
contributing in general so that people can feel okay saying they thought a
comment was out of line without retaliation for it.

The other problem is letting threads drag on needlessly. The longer a
thread drags on, the greater the chance someone is going to say something
they regret. It can also lead to some people like Antoine feeling like
their time is being wasted and become frustrated. I think in this instance
debate should have been cut sooner when no clear consensus was being
reached to force a reversal of the patch and then have someone say politely
that a core dev who is the listed expert on a module made a call and if
someone disliked it they could produce a patch and propose it on the issue
tracker to see if they could change someone's mind (I believe both Nick and
Ethan have made the same point). Our niceness can be to a fault when no one
is willing to step up and simply say "this thread is in a stalemate and
nothing new is being added, please move it to the issue tracker if you wish
to discuss further where you can propose a patch" and we just be good about
telling people to move the discussion to the issue tracker if they keep
replying.

There is absolutely no reason we can't keep discussions cordial, friendly,
and on-point on this list and prevent this sort of debacle from occurring
again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150719/e17b8e4e/attachment.html>

From breamoreboy at yahoo.co.uk  Sun Jul 19 23:16:41 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Sun, 19 Jul 2015 22:16:41 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAP1=2W6YWvVXEkVQ2hbUeig49vR8cNDMN3PPLamxR=WvfgQezw@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
 <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>
 <87vbdheaxi.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea59a0720.b0c7f043604411.3660687318231351792@bytereef.org>
 <55ABC911.2060003@stoneleaf.us>
 <CAP1=2W6YWvVXEkVQ2hbUeig49vR8cNDMN3PPLamxR=WvfgQezw@mail.gmail.com>
Message-ID: <moh446$mcc$1@ger.gmane.org>

On 19/07/2015 22:06, Brett Cannon wrote:
>
>
> On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman <ethan at stoneleaf.us
> <mailto:ethan at stoneleaf.us>> wrote:
>
>     On 07/19/2015 02:22 AM, s.krah wrote:
>      > ---- Ein Sa, 18 Jul 2015 15:35:05 +0000 *Stephen J. Turnbull hat
>     geschrieben ----
>      >> s.krah writes:
>
>      >>> Sorry, that amounts to twisting my words.
>      >>
>      >> Let's not play the dozens here.  That just extends the thread to
>     no point.
>      >
>      > Indeed.  I'll just filter you from now on.
>
>     You may as well filter me too, then, because you are acting like an
>     ass and I'm saying so.
>
>
> Is the name calling really necessary? Couldn't you have just as easily
> said that you disapproved of Stephen K's attitude without calling him an
> ass? Same goes for Stephen K's comment where he could have stated he was
> simply going to ignore Stephen T and be less snippy about it. There are
> ways to get the point across just as strongly without resorting to this
> sort of stuff.
>
> This whole thread has shown two problems we have on this list. One is
> the occasional name calling and bad attitude that we let slide in the
> name of blowing off steam or something. We are all adults here and can
> get the point across that we disapprove of something without resorting
> to playground antics. Plus emails can be delayed until cooler heads
> prevail. It's this kind of thing that leads to the need of a CoC for
> this list and contributing in general so that people can feel okay
> saying they thought a comment was out of line without retaliation for it.
>
> The other problem is letting threads drag on needlessly. The longer a
> thread drags on, the greater the chance someone is going to say
> something they regret. It can also lead to some people like Antoine
> feeling like their time is being wasted and become frustrated. I think
> in this instance debate should have been cut sooner when no clear
> consensus was being reached to force a reversal of the patch and then
> have someone say politely that a core dev who is the listed expert on a
> module made a call and if someone disliked it they could produce a patch
> and propose it on the issue tracker to see if they could change
> someone's mind (I believe both Nick and Ethan have made the same point).
> Our niceness can be to a fault when no one is willing to step up and
> simply say "this thread is in a stalemate and nothing new is being
> added, please move it to the issue tracker if you wish to discuss
> further where you can propose a patch" and we just be good about telling
> people to move the discussion to the issue tracker if they keep replying.
>
> There is absolutely no reason we can't keep discussions cordial,
> friendly, and on-point on this list and prevent this sort of debacle
> from occurring again.
>

+infinity

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From rosuav at gmail.com  Sun Jul 19 23:24:15 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 20 Jul 2015 07:24:15 +1000
Subject: [Python-Dev] GetFinalPathNameByHandleW - what is the minimum
 windows version python-3.5 will support ?
In-Reply-To: <mogqeu$boq$1@ger.gmane.org>
References: <1437307823.11841681@f409.i.mail.ru>
 <55ABAB7A.7080605@timgolden.me.uk> <mogqeu$boq$1@ger.gmane.org>
Message-ID: <CAPTjJmoWZC3nnU2tDdwT_kYp-EGYUcOZUYXiaJUD3bCYJ3L3NQ@mail.gmail.com>

On Mon, Jul 20, 2015 at 4:31 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> I think this line in the PEP, "Because of this policy, no further Windows
> releases need to be listed in this PEP. " is false economy. Your research on
> server 2003 should be recorded. (The presence of a 3.5 Server 2003 buildbot,
> even though not working, might lead one to the opposite answer.) Even if
> users ignore the PEP, people answering questions (like me) try to use it to
> get definitive answers.

Also, if it comes to that, Server 2003 should probably get mentioned
here, which is where I'd go looking:

https://docs.python.org/dev/whatsnew/3.5.html#unsupported-operating-systems

ChrisA

From ron3200 at gmail.com  Mon Jul 20 00:06:22 2015
From: ron3200 at gmail.com (Ron Adam)
Date: Sun, 19 Jul 2015 18:06:22 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150719183355.GP18503@tonks>
References: <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <20150717014851.2813b7bf@fsol> <mogf1n$341$1@ger.gmane.org>
 <20150719183355.GP18503@tonks>
Message-ID: <moh70v$152$1@ger.gmane.org>



On 07/19/2015 02:33 PM, Florian Bruhin wrote:
> * Ron Adam<ron3200 at gmail.com>  [2015-07-19 11:17:10 -0400]:
>> >I had to look at the source to figure out what this thread was really all
>> >about.

And it seems I don't quite get it still, but I am trying.


>> >Basically it looks to me the purpose of adding "assret" is to add an "alias
>> >check" for "unsafe" methods.  It doesn't actually add an "alias".  It allows
>> >a developer to use a valid alias to avoid conflicting with methods starting
>> >with assert that will still work with the mock module.
>> >
>> >The mock module says that when "unsafe" flag is set to True, it will not
>> >raise AssertionError for methods beginning with "assert" and "assret".  It
>> >doesn't specify what "unsafe" means, and why you would want to do that.
>> >
>> >So first do this...
>> >
>> >     * Document "unsafe" in mock module.

I still think documenting the purpose of "unsafe", rather than just the 
effect it has is important.

 From the confusion in this thread, (including my own), it's clear the 
documentation does need some attention.


There are only two places where it mentions "unsafe" in the docs...

The class signature...

"""
class unittest.mock.Mock(spec=None, side_effect=None, return_value=DEFAULT, 
wraps=None, name=None, spec_set=None, unsafe=False, **kwargs)
"""


And in the section below that.

"""
unsafe: By default if any attribute starts with assert or assret will raise 
an AttributeError. Passing unsafe=True will allow access to these attributes.
"""

But that doesn't explain the purpose or why these are unsafe or why it 
should throw an AttributeError.   Or what to do with that AttributeError.


> But if you do a typo, the test silently doesn't fail (because it's returning a
> new mock instead of checking if it has been called):

Do you mean silently passes?


>      >>> m.assert_called()
>      <Mock name='mock.assert_called()' id='140277467876152'>
>
> With the patch, everything starting with "assert" or "assret" (e.g. my
> example above) raises an AttributeError so these kind of issues can't
> happen.

I get that part.  It's checking for a naming convention for some purpose.

What purpose?

    "To raise an AttributeError"  ... but why?


> The thing people are discussing about is whether this should also
> happen if you do "m.assret_called_with()" (i.e. if this is a common
> enough typo to warrant a special exception), or if*only*  things
> starting with assert_* are checked.
>
> The merged patch also treats "assret_*" as a typo, and some people
> think this is a wart/unnecessary/harmful and only "assert_*" should
> raise an AttributionError, i.e. the patch should be amended/reverted.

I think it would be easy enough to revert, It' just a few line in the 
source and docs.  No big deal there.

It's not clear why getting an AttributeError for methods beginning with 
assert is needed, and how that exception is to be used.   (Should it Bubble 
up, or should it be caught and handled?)

Is it just a way to prevent mocks of mocks?  Maybe there is a better way of 
doing that?



>> >If I've still not quite got the gist of this issue, the please correct me.
> This has nothing to do with the assert*keyword*  or optimization -
> only with the behaviour of mock and its "assert_*" methods.
>
> I hope this clears things up!

It clears up that it's not associated with the assert keyword.


Cheers,
    Ron


From ben+python at benfinney.id.au  Mon Jul 20 08:33:35 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 20 Jul 2015 16:33:35 +1000
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
Message-ID: <854mkzpccg.fsf@benfinney.id.au>

Nick Coghlan <ncoghlan at gmail.com> writes:

> Sorry, I crossed a line there - I know everyone posting to this thread
> is doing so with the best interests of Python at heart.

Thanks for saying so, I was mulling a similar post but yours came first.

> The *problem* with threads like this one is that they end up feeling
> like punishment for being accommodating to the wishes of contributors
> on minor design details.

>From this questioner's perspective, threads like this also end up
feeling like an escalating dismissal (?this is just *not important*, and
no discussion will be entered into?) of salient user concerns regarding
the APIs on the standard library.

Neither of those impressions, I'm sure, was intended by any party to
this thread.

> Potential core developers are also likely to be put off by the
> prospect of "you too can volunteer to be micromanaged by a large
> community mailing list, doesn't that sound like fun?"

Requests for principled justification can be very easily misread as
blame. The mere absence of that intention is not enough to quell
suspicion; neither is the suspicion of it enough to respond as though
that is the intent.

We all need to remember that tendency, and take better care in
expressing ourselves.

For what it's worth: of course I think I speak for everyone here in
saying that I greatly appreciate the work of core contributors in
implementing CPython and the standard library, and continuing effort to
maintain it.

Thank you all.

-- 
 \        ?What if the Hokey Pokey IS what it's all about?? ?anonymous |
  `\                                                                   |
_o__)                                                                  |
Ben Finney


From stephen at xemacs.org  Mon Jul 20 09:15:32 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 20 Jul 2015 16:15:32 +0900
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <mogp8t$ph4$1@ger.gmane.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
 <55ABC7AD.4020109@stoneleaf.us> <mogp8t$ph4$1@ger.gmane.org>
Message-ID: <21932.40980.61647.662357@uwakimon.sk.tsukuba.ac.jp>

Terry Reedy writes:

 > Good (or certainly much better): <I think Nick already tried to fill in 
 > this blank>

I think so too, but IMO Nick and Antoine made a serious mistake by
deprecating this as a "minor design decision" without further
rationale.  That's no excuse at all!  The point of the Zen about
"special cases" is that these minor design decisions are indeed a
slippery slope -- they may be minor individually, but collectively
they lead to real ugliness.  Every one needs to be considered
carefully, and this particular one plays no role in the basic design
of mock -- it's hard to see sufficient "practicality" without context.
Arguing that "special cases aren't" is not like complaining about the
"color of the bikeshed", it's like finding a termite climbing up the
wall and calling for the exterminator.

ISTM that the missing rationale is that the real special case is mock
itself.  Michael referred to this context, but didn't make it
explicit.  Mock effectively "monkeypatches the world".  In that
context, the decision to protect against certain errors whose risk is
greatly increased by mock itself arguably is a *minor* design
decision, and none of the defenders of leaving this feature in 3.5
would consider it a precedent for admitting similar "special cases"
elsewhere in the stdlib.  (Last minute note: I believe this analysis
is confirmed by Florian Bruhin's post, which I don't fully understand.)

I'm not sure I accept that myself<wink/>, but it does convince me that
the feature's defenders continue to firmly believe that special cases
aren't special enough, and that is good enough reason to end the
thread.

Steve


From me at the-compiler.org  Mon Jul 20 09:32:38 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 20 Jul 2015 09:32:38 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <moh70v$152$1@ger.gmane.org>
References: <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <20150717014851.2813b7bf@fsol> <mogf1n$341$1@ger.gmane.org>
 <20150719183355.GP18503@tonks> <moh70v$152$1@ger.gmane.org>
Message-ID: <20150720073238.GQ18503@tonks>

* Ron Adam <ron3200 at gmail.com> [2015-07-19 18:06:22 -0400]:
> 
> 
> On 07/19/2015 02:33 PM, Florian Bruhin wrote:
> >* Ron Adam<ron3200 at gmail.com>  [2015-07-19 11:17:10 -0400]:
> >>>I had to look at the source to figure out what this thread was really all
> >>>about.
> 
> And it seems I don't quite get it still, but I am trying.

No worries - I'll try to clarify until things are clear :)

> >>>Basically it looks to me the purpose of adding "assret" is to add an "alias
> >>>check" for "unsafe" methods.  It doesn't actually add an "alias".  It allows
> >>>a developer to use a valid alias to avoid conflicting with methods starting
> >>>with assert that will still work with the mock module.
> >>>
> >>>The mock module says that when "unsafe" flag is set to True, it will not
> >>>raise AssertionError for methods beginning with "assert" and "assret".  It
> >>>doesn't specify what "unsafe" means, and why you would want to do that.
> >>>
> >>>So first do this...
> >>>
> >>>     * Document "unsafe" in mock module.
> 
> I still think documenting the purpose of "unsafe", rather than just the
> effect it has is important.
> 
> From the confusion in this thread, (including my own), it's clear the
> documentation does need some attention.
> 
> 
> There are only two places where it mentions "unsafe" in the docs...
> 
> The class signature...
> 
> """
> class unittest.mock.Mock(spec=None, side_effect=None, return_value=DEFAULT,
> wraps=None, name=None, spec_set=None, unsafe=False, **kwargs)
> """
> 
> 
> And in the section below that.
> 
> """
> unsafe: By default if any attribute starts with assert or assret will raise
> an AttributeError. Passing unsafe=True will allow access to these
> attributes.
> """
> 
> But that doesn't explain the purpose or why these are unsafe or why it
> should throw an AttributeError.   Or what to do with that AttributeError.

It's "unsafe" because tests which:

1) are using the assert_* methods of a mock, and
2) where the programmer did a typo (assert_called() instead of
   assert_called_with() for example)

do silently pass.

> >But if you do a typo, the test silently doesn't fail (because it's returning a
> >new mock instead of checking if it has been called):
> 
> Do you mean silently passes?

Yes - it passes without checking the thing the test was intended to
check.

> 
> >     >>> m.assert_called()
> >     <Mock name='mock.assert_called()' id='140277467876152'>
> >
> >With the patch, everything starting with "assert" or "assret" (e.g. my
> >example above) raises an AttributeError so these kind of issues can't
> >happen.
> 
> I get that part.  It's checking for a naming convention for some purpose.
> 
> What purpose?
> 
>    "To raise an AttributeError"  ... but why?

So you notice you have done a typo and your test will not actually
verify what you want it to verify.

Compare it with the behavior of a normal object - if you call a method
which doesn't exist, it raises AttributeError.

This isn't possible with Mock objects, as they are designed to support
*any* call, and you can check the calls have happened after the fact.

With the patch, if you call any method starting with "assert" which
does not exist (assert_caled_with, assert_foobar, assert_called, etc.)
this is assumed to be a mistake and you get an AttributeError so you
notice there was a mistake.

If you pass unsafe=True, you can still call mock.assert_foo() methods
as usual and they will return a new Mock, just as calling, say,
mock.spam() would.

> >The thing people are discussing about is whether this should also
> >happen if you do "m.assret_called_with()" (i.e. if this is a common
> >enough typo to warrant a special exception), or if*only*  things
> >starting with assert_* are checked.
> >
> >The merged patch also treats "assret_*" as a typo, and some people
> >think this is a wart/unnecessary/harmful and only "assert_*" should
> >raise an AttributionError, i.e. the patch should be amended/reverted.
> 
> I think it would be easy enough to revert, It' just a few line in the source
> and docs.  No big deal there.
> 
> It's not clear why getting an AttributeError for methods beginning with
> assert is needed, and how that exception is to be used.   (Should it Bubble
> up, or should it be caught and handled?)

Note the discussion *isn't* about the fact that assert-methods should
raise AttributeError! The patch also does the same with "assret".

At least if I understand things correctly, the discussion is whether
*only* "assert*" should be handled as a typo, or "assret*" too.

The exception should bubble up, as the whole point of it is to tell
you you did a typo and your test is broken.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150720/47427170/attachment-0001.sig>

From ncoghlan at gmail.com  Mon Jul 20 10:04:57 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 20 Jul 2015 18:04:57 +1000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <21932.40980.61647.662357@uwakimon.sk.tsukuba.ac.jp>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
 <55ABC7AD.4020109@stoneleaf.us> <mogp8t$ph4$1@ger.gmane.org>
 <21932.40980.61647.662357@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CADiSq7fouOMkeYMTZe6o9H8QTQKJ8_DyOKL7aFKss7QpYWcRFg@mail.gmail.com>

On 20 July 2015 at 17:15, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> ISTM that the missing rationale is that the real special case is mock
> itself.  Michael referred to this context, but didn't make it
> explicit.  Mock effectively "monkeypatches the world".  In that
> context, the decision to protect against certain errors whose risk is
> greatly increased by mock itself arguably is a *minor* design
> decision, and none of the defenders of leaving this feature in 3.5
> would consider it a precedent for admitting similar "special cases"
> elsewhere in the stdlib.

Yes, Mock (especially AutoMock) is *already* quite magical from the
perspective of most Pythonistas, as it relies heavily on Python's
runtime introspection features to emulate other objects based on live
introspection of the relevant type objects. It is however a very
*practical* piece of code, as it lets you readily mock out a remote
service for testing purposes, while later using those same tests
against a *real* instance of the target class as functional
integration tests, even if you couldn't write such API emulation code
yourself.

The need for the "typo detection" is then a consequence of two
different kinds of methods existing in the same namespace (those from
Mock itself, and those from the object being emulated), leading to a
particular category of bug in normal usage of this API. Robert Collins
suggested a possible migration path to better structural separation of
the two kinds of Mock method, but the existing merged API is one a lot
of folks actually like.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From p.f.moore at gmail.com  Mon Jul 20 10:27:57 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 20 Jul 2015 09:27:57 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <21932.40980.61647.662357@uwakimon.sk.tsukuba.ac.jp>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
 <55ABC7AD.4020109@stoneleaf.us> <mogp8t$ph4$1@ger.gmane.org>
 <21932.40980.61647.662357@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CACac1F9pjaTeJbh5TA_VhsjsVGbkQUbp=MAm_=Ysk8aAaa9EKg@mail.gmail.com>

On 20 July 2015 at 08:15, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Every one needs to be considered carefully,

It's very hard to pick out snippets like this out of context,
particularly in a thread that has already caused a lot of turmoil, but
I think this point is worth addressing. And my apologies in advance if
I don't word my point well enough and cause offence. None is intended.

As a new core dev, although one who has been on this list for many
years, I can attest to Nick's point that threads like this are a huge
barrier to new contributors - I personally am pretty reluctant to
commit changes on my own judgement, purely because of the risk that "I
might be wrong" (i.e. I might be called to justify my decision in a
thread like this).

The problem with pointing out that decisions need to be considered
carefully is that there is an implication that either the original
core dev *didn't* consider the issue carefully. But I doubt that's the
case. Extra review may help, certainly, but a thread like this quite
frankly doesn't really feel like "extra review".

Again, I'm sorry to pick on one sentence out of context, but it cut
straight to my biggest fear when doing a commit (on any project) -
what if, after all the worrying and consideration I put into doing
this commit, people disagree with me (or worse still, I made a
mistake)? Will I be able to justify what I decided? Hmm, maybe I'd
better hold off and let someone else make the decision...

Paul

From ben+python at benfinney.id.au  Mon Jul 20 14:34:29 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 20 Jul 2015 22:34:29 +1000
Subject: [Python-Dev] How far to go with user-friendliness
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
 <55ABC7AD.4020109@stoneleaf.us> <mogp8t$ph4$1@ger.gmane.org>
 <21932.40980.61647.662357@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F9pjaTeJbh5TA_VhsjsVGbkQUbp=MAm_=Ysk8aAaa9EKg@mail.gmail.com>
Message-ID: <85zj2rnh2i.fsf@benfinney.id.au>

Paul Moore <p.f.moore at gmail.com> writes:

> Again, I'm sorry to pick on one sentence out of context, but it cut
> straight to my biggest fear when doing a commit (on any project) -
> what if, after all the worrying and consideration I put into doing
> this commit, people disagree with me (or worse still, I made a
> mistake)? Will I be able to justify what I decided?

That seems quite healthy to me. On a collaborative project with effects
far beyond oneself, yes, any change *should* be able to be justified
when challenged.

That isn't a mandate to challenge every change, of course. It does mean
that every change should be considered in light of ?Can I justify
this, if challenged??

So what you describe sounds like a healthy barrier: one which works to
keep out unjustifiable changes.

What is needed is to have both that *and* the support of the community
so it's not a barrier to the *contributors*. The contributors should not
feel excluded merely because some of their changes might need to be.

> Hmm, maybe I'd better hold off and let someone else make the
> decision...

What of the (obvious, to me) option to retain the authority to make the
decision, but take the doubt as a sign that one should consult with
others before making the decision?

That is, there's no need to feel that one shouldn't make the decision.
But perhaps one shouldn't make it solely on one's own experience or
insight. Get others involved, even non-committers, and discuss it, and
understand the issue better. With that improved basis, then make the
decision.

Am I naive to think that's desirable for PYthon core committers?

-- 
 \     ?Ours is a world where people don't know what they want and are |
  `\       willing to go through hell to get it.? ?Donald Robert Perry |
_o__)                                                          Marquis |
Ben Finney


From p.f.moore at gmail.com  Mon Jul 20 15:23:27 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 20 Jul 2015 14:23:27 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <85zj2rnh2i.fsf@benfinney.id.au>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <858uaepadm.fsf@benfinney.id.au>
 <CADiSq7ckYBGBXP_O1VZ-qU7oC=NR0k5LOtoLoGyfqeWT_ZFNtA@mail.gmail.com>
 <CADiSq7cJMG8fivAPpzsnhuebMOkE9V+2nQu=X=LX4ANV-S=K1A@mail.gmail.com>
 <55ABC7AD.4020109@stoneleaf.us> <mogp8t$ph4$1@ger.gmane.org>
 <21932.40980.61647.662357@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F9pjaTeJbh5TA_VhsjsVGbkQUbp=MAm_=Ysk8aAaa9EKg@mail.gmail.com>
 <85zj2rnh2i.fsf@benfinney.id.au>
Message-ID: <CACac1F_-WsBrB30GazVwznZ6o4zLuZHoWyRuTgRrM2hckCUhEw@mail.gmail.com>

On 20 July 2015 at 13:34, Ben Finney <ben+python at benfinney.id.au> wrote:
>> Again, I'm sorry to pick on one sentence out of context, but it cut
>> straight to my biggest fear when doing a commit (on any project) -
>> what if, after all the worrying and consideration I put into doing
>> this commit, people disagree with me (or worse still, I made a
>> mistake)? Will I be able to justify what I decided?

Let me rephrase. What I was trying to say was that justifying the
change *to the level needed for the sort of debate we see here* is too
high a barrier.

Michael is the original developer of mock, is the primary maintainer
of it, and apparently had a specific example of the assret misspelling
causing problems. And yet the debate still goes on. At what point does
that debate stop being a request to justify a change, and turn into
unreasonable browbeating over a decision that others don't like?

Even the constructive suggestions of an alternative, less fragile API,
were responded to (with "it doesn't match the design principles of
mock"). And yet there's a tone of "why didn't you think of this
approach" in the thread (and my immediate thought to that is why is
"because I'm not perfect" not an acceptable response - and so obvious
as to not need stating?)

Again, I'm not saying that people shouldn't be aware of the
responsibility of being a core dev, and wield the authority carefully.
But at some point the mailing list commentary stops being a useful
check and turns into a demotivating and paralysing force. It's hard to
keep that balance correct, but I think that presently there's a shift
towards the negative side, which we should recognise and address.

> That seems quite healthy to me. On a collaborative project with effects
> far beyond oneself, yes, any change *should* be able to be justified
> when challenged.

Fair. But equally, on a project supported on a volunteer basis by a
relatively small group with severe time pressure problems, any
challenge should be able to be justified as worth the drain on
resource and energy.

A quick "is the special-casing of one possible mis-spelling worth it?"
question on the tracker is one thing. A week-long, 100-message mailing
list thread is another. Somewhere in the middle (but a lot closer to
the former) is probably ideal.

Paul

From ron3200 at gmail.com  Mon Jul 20 18:57:08 2015
From: ron3200 at gmail.com (Ron Adam)
Date: Mon, 20 Jul 2015 12:57:08 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150720073238.GQ18503@tonks>
References: <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <CAJ3HoZ2fE6uTZgq6EZZOSrHBAaDVD_NDWtfa5x0Wbrjq3gsUbw@mail.gmail.com>
 <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <20150717014851.2813b7bf@fsol> <mogf1n$341$1@ger.gmane.org>
 <20150719183355.GP18503@tonks> <moh70v$152$1@ger.gmane.org>
 <20150720073238.GQ18503@tonks>
Message-ID: <moj996$t4k$1@ger.gmane.org>



On 07/20/2015 03:32 AM, Florian Bruhin wrote:
> * Ron Adam<ron3200 at gmail.com>  [2015-07-19 18:06:22 -0400]:
>> >
>> >
>> >On 07/19/2015 02:33 PM, Florian Bruhin wrote:
>>> > >* Ron Adam<ron3200 at gmail.com>   [2015-07-19 11:17:10 -0400]:
>>>>> > >>>I had to look at the source to figure out what this thread was really all
>>>>> > >>>about.
>> >
>> >And it seems I don't quite get it still, but I am trying.
> No worries - I'll try to clarify until things are clear :)

Thanks,  :-)

>>>>> > >>>Basically it looks to me the purpose of adding "assret" is to add an "alias
>>>>> > >>>check" for "unsafe" methods.  It doesn't actually add an "alias".  It allows
>>>>> > >>>a developer to use a valid alias to avoid conflicting with methods starting
>>>>> > >>>with assert that will still work with the mock module.
>>>>> > >>>
>>>>> > >>>The mock module says that when "unsafe" flag is set to True, it will not
>>>>> > >>>raise AssertionError for methods beginning with "assert" and "assret".  It
>>>>> > >>>doesn't specify what "unsafe" means, and why you would want to do that.
>>>>> > >>>
>>>>> > >>>So first do this...
>>>>> > >>>
>>>>> > >>>     * Document "unsafe" in mock module.
>> >
>> >I still think documenting the purpose of "unsafe", rather than just the
>> >effect it has is important.
>> >
>> > From the confusion in this thread, (including my own), it's clear the
>> >documentation does need some attention.
>> >
>> >
>> >There are only two places where it mentions "unsafe" in the docs...
>> >
>> >The class signature...
>> >
>> >"""
>> >class unittest.mock.Mock(spec=None, side_effect=None, return_value=DEFAULT,
>> >wraps=None, name=None, spec_set=None, unsafe=False, **kwargs)
>> >"""
>> >
>> >
>> >And in the section below that.
>> >
>> >"""
>> >unsafe: By default if any attribute starts with assert or assret will raise
>> >an AttributeError. Passing unsafe=True will allow access to these
>> >attributes.
>> >"""
>> >
>> >But that doesn't explain the purpose or why these are unsafe or why it
>> >should throw an AttributeError.   Or what to do with that AttributeError.

> It's "unsafe" because tests which:
>
> 1) are using the assert_* methods of a mock, and
> 2) where the programmer did a typo (assert_called() instead of
>     assert_called_with() for example)
>
> do silently pass.

And further down, you say...

> Compare it with the behavior of a normal object - if you call a method
> which doesn't exist, it raises AttributeError.
>
> This isn't possible with Mock objects, as they are designed to support
> *any*  call, and you can check the calls have happened after the fact.


And the docs say...

"""
spec: This can be either a list of strings or an existing object (a class 
or instance) that acts as the specification for the mock object. If you 
pass in an object then a list of strings is formed by calling dir on the 
object (excluding unsupported magic attributes and methods). Accessing any 
attribute not in this list will raise an AttributeError.
"""

So calling a method that doesn't exist on a mocked object will raise an 
AttributeError if it is given a spec.

But if you don't give it a spec, then a mispelling of *any* method will 
pass silently.  So it's not a problem limited to "assert" methods.

It seems the obvious and best solution is to always use a spec.



>> >It's not clear why getting an AttributeError for methods beginning with
>> >assert is needed, and how that exception is to be used.   (Should it Bubble
>> >up, or should it be caught and handled?)

> Note the discussion*isn't*  about the fact that assert-methods should
> raise AttributeError! The patch also does the same with "assret".
>
> At least if I understand things correctly, the discussion is whether
> *only*  "assert*" should be handled as a typo, or "assret*" too.

Both of these are new in 3.5.  And they are related to each other.  So yes, 
they do need to be looked at together in order to understand the problem 
being discussed.

> The exception should bubble up, as the whole point of it is to tell
> you you did a typo and your test is broken.

I think this is too simple of an explanation.  That could be true for any 
method or attribute call.

 >>> m = Mock(spec=["assert_me", "call_me"])
 >>> m.call_me()
<Mock name='mock.call_me()' id='140590283081488'>

 >>> m.all_me()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File 
"/media/hda2/home/ra/Dev/python-dev/python3.5/cpython-master/Lib/unittest/mock.py", 
line 578, in __getattr__
     raise AttributeError("Mock object has no attribute %r" % name)
AttributeError: Mock object has no attribute 'all_me'

It does raise AttributeError's on missing methods if a spec is given.  So 
catching mispelled methods in tests is only a problem if you don't use a 
spec.  (And not limited to assert methods)


 >>> m.assert_me()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File 
"/media/hda2/home/ra/Dev/python-dev/python3.5/cpython-master/Lib/unittest/mock.py", 
line 583, in __getattr__
     raise AttributeError(name)
AttributeError: assert_me


Why is AttributeError raised here?  Why are methods beginning with assert 
special?  (or "unsafe")

Cheers,
    Ron





















From me at the-compiler.org  Mon Jul 20 19:35:47 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 20 Jul 2015 19:35:47 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <moj996$t4k$1@ger.gmane.org>
References: <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <20150717014851.2813b7bf@fsol> <mogf1n$341$1@ger.gmane.org>
 <20150719183355.GP18503@tonks> <moh70v$152$1@ger.gmane.org>
 <20150720073238.GQ18503@tonks> <moj996$t4k$1@ger.gmane.org>
Message-ID: <20150720173547.GS18503@tonks>

* Ron Adam <ron3200 at gmail.com> [2015-07-20 12:57:08 -0400]:
> >It's "unsafe" because tests which:
> >
> >1) are using the assert_* methods of a mock, and
> >2) where the programmer did a typo (assert_called() instead of
> >    assert_called_with() for example)
> >
> >do silently pass.
> 
> And further down, you say...
> 
> >Compare it with the behavior of a normal object - if you call a method
> >which doesn't exist, it raises AttributeError.
> >
> >This isn't possible with Mock objects, as they are designed to support
> >*any*  call, and you can check the calls have happened after the fact.
> 
> 
> And the docs say...
> 
> """
> spec: This can be either a list of strings or an existing object (a class or
> instance) that acts as the specification for the mock object. If you pass in
> an object then a list of strings is formed by calling dir on the object
> (excluding unsupported magic attributes and methods). Accessing any
> attribute not in this list will raise an AttributeError.
> """
> 
> So calling a method that doesn't exist on a mocked object will raise an
> AttributeError if it is given a spec.
> 
> But if you don't give it a spec, then a mispelling of *any* method will pass
> silently.  So it's not a problem limited to "assert" methods.
> 
> It seems the obvious and best solution is to always use a spec.

I agree - I always use mocks with autospec/spec, and I recommend doing
that - I actually plan to write a plugin for pylint to enforce this.

Still mistyping the assert methods seems to be a common issue, since
(according to some other mail) a couple of bugs in OpenStack were
found this way.

But yeah - if your code under test has a typo, and you don't use
spec/autospec, you might not notice as well - though in my experience
you *usually* do, since the returned mock object doesn't behave in the
way you expect it to.

But yeah - always using (auto)spec is probably the best solution.

> >>> m.assert_me()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/media/hda2/home/ra/Dev/python-dev/python3.5/cpython-master/Lib/unittest/mock.py",
> line 583, in __getattr__
>     raise AttributeError(name)
> AttributeError: assert_me
> 
> 
> Why is AttributeError raised here?  Why are methods beginning with assert
> special?  (or "unsafe")

Some things I can think of:

- It's more likely that you use assert_called() instead of
  assert_called_with() accidentally than that you do a typo in your
  code under test.

- If you do a typo in your code under test, a linter is more likely to
  find it than with mocks, because of their nature.

- Other tests (even if they're manual ones) should probably discover
  the typo in your real code. The always-passing assert won't.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150720/d842bd7f/attachment.sig>

From emile at fenx.com  Mon Jul 20 19:53:29 2015
From: emile at fenx.com (Emile van Sebille)
Date: Mon, 20 Jul 2015 10:53:29 -0700
Subject: [Python-Dev] A quick word on top posting
In-Reply-To: <moh446$mcc$1@ger.gmane.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
 <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>
 <87vbdheaxi.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea59a0720.b0c7f043604411.3660687318231351792@bytereef.org>
 <55ABC911.2060003@stoneleaf.us>
 <CAP1=2W6YWvVXEkVQ2hbUeig49vR8cNDMN3PPLamxR=WvfgQezw@mail.gmail.com>
 <moh446$mcc$1@ger.gmane.org>
Message-ID: <mojcj1$qm9$1@ger.gmane.org>

Your +infinity could have easily been top posted -- particularly when 
there's no in-line comments that require context.

just-because-I'm-on-what-feels-like-a-300-baud-connection-ly yr's,

Emile


On 7/19/2015 2:16 PM, Mark Lawrence wrote:
> On 19/07/2015 22:06, Brett Cannon wrote:

<snip>

>> There is absolutely no reason we can't keep discussions cordial,
>> friendly, and on-point on this list and prevent this sort of debacle
>> from occurring again.
>>
>
> +infinity
>



From brian at python.org  Mon Jul 20 20:03:29 2015
From: brian at python.org (Brian Curtin)
Date: Mon, 20 Jul 2015 13:03:29 -0500
Subject: [Python-Dev] A quick word on top posting
In-Reply-To: <mojcj1$qm9$1@ger.gmane.org>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
 <55A8197F.1060500@stoneleaf.us> <85lhefu8d7.fsf@benfinney.id.au>
 <20150716231003.356b91b4@fsol> <85h9p3u44c.fsf@benfinney.id.au>
 <CADiSq7d9ruDe_bmqrqfTELHA=73oP5kW5J7M17831q2YQvcEXw@mail.gmail.com>
 <55A97DAF.1000605@stoneleaf.us> <20150718014021.59200f65@fsol>
 <87380mf5is.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea0c9c660.e4563eea579926.4250737712616484335@bytereef.org>
 <87y4ideio5.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea1599546.10ebf260f573011.3332332588669645127@bytereef.org>
 <87vbdheaxi.fsf@uwakimon.sk.tsukuba.ac.jp>
 <14ea59a0720.b0c7f043604411.3660687318231351792@bytereef.org>
 <55ABC911.2060003@stoneleaf.us>
 <CAP1=2W6YWvVXEkVQ2hbUeig49vR8cNDMN3PPLamxR=WvfgQezw@mail.gmail.com>
 <moh446$mcc$1@ger.gmane.org> <mojcj1$qm9$1@ger.gmane.org>
Message-ID: <CAD+XWwp8haENTd446wR7+y5dXZgH-ue5GpgcpUsx4CqGkraAUA@mail.gmail.com>

On Monday, July 20, 2015, Emile van Sebille <emile at fenx.com> wrote:

> Your +infinity could have easily been top posted -- particularly when
> there's no in-line comments that require context.
>
> just-because-I'm-on-what-feels-like-a-300-baud-connection-ly yr's,
>
> Emile
>
>
> On 7/19/2015 2:16 PM, Mark Lawrence wrote:
>
>> On 19/07/2015 22:06, Brett Cannon wrote:
>>
>
> <snip>
>
>  There is absolutely no reason we can't keep discussions cordial,
>>> friendly, and on-point on this list and prevent this sort of debacle
>>> from occurring again.
>>>
>>>
>> +infinity
>>
>
Empty replies like a fake vote should just not occur in general. That's not
usually an issue on this list, but I see many others plagued by such
responses and hope we never end up on that path (especially people +1'ing a
+1...). Remember that not only do we need to keep emails to the
characteristics Brett mentioned for the sake of having a healthy
discussion list, we should strive to keep the noise as close to zero as
possible as mails sent to this list reach *a lot* of people.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150720/12a8fa43/attachment.html>

From erik.m.bray at gmail.com  Mon Jul 20 20:30:17 2015
From: erik.m.bray at gmail.com (Erik Bray)
Date: Mon, 20 Jul 2015 14:30:17 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
Message-ID: <CAOTD34aGB-vFHcuUfyfQ5jB8mXk7r31DeWtCGm_EgsOtVwA_ag@mail.gmail.com>

On Tue, Jul 14, 2015 at 6:22 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> For clarity, I think we should:
>  - remove the assret check, it is I think spurious.
>  - add a set of functions to the mock module that should be used in
> preference to Mock.assert*
>  - mark the Mock.assert* functions as PendingDeprecation
>  - in 3.6 move the PendingDeprecation to Deprecated
>  - in 3.7 remove the Mock.assert* functions and the check for method
> names beginning with assert entirely.

Hi all,

I'm just an onlooker, and haven't read every word of this thread.  In
fact I worry that it's pointless to reply to rather than starting a
new thread.  I just wanted to make sure that the specific message I'm
replying too wasn't lost in the noise because I think Robert's
suggestion makes vastly more sense than anything else I've seen here
(I came searching through the thread to see if anyone else suggested
this before I started a thread to do so).

I don't think it makes any sense to have magic assert_ methods on the
Mock object.  Not only does the "magic" clearly lead to too many
ambiguities and other problems--I think they make less sense from an
API standpoint in the first place.  Typically asserting something in a
test is not something an object *does*--a method.  More often we as a
test writers assert something *about* an object.  The assertion is an
external tool meant to measure and introspect things about the system
under observation.  In this case, although Mock is itself a testing
tool, we're introspecting something about the Mock object as external
observers.

***Assertions on Mock objects should be implemented as stand-alone
functions (that happen to be used primarily on Mock objects as
input).***

Aside from, in my mind, making more sense philosophically, using
specialized assert functions for this has absolutely none of the
spelling ambiguities or other problems of the magic methods.

I'm -0 on removing the assret_ methods unless no one is using them
yet.  I don't care if they're there as long as they're deprecated
along with the other magic methods of Mock.

Best,
Erik

From ron3200 at gmail.com  Mon Jul 20 23:11:51 2015
From: ron3200 at gmail.com (Ron Adam)
Date: Mon, 20 Jul 2015 17:11:51 -0400
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <20150720173547.GS18503@tonks>
References: <CACac1F-BV=rodxTf9coff6E5-m5ghvQ4cQ+ripg2GC1svJ8TBA@mail.gmail.com>
 <CAJ3HoZ0QoBxO=qLjdrGf-EXZCZpF-UJy4azvah5Bz1abeyvY+g@mail.gmail.com>
 <20150717011818.38176504@fsol>
 <CAGxWq1Xx-G2G9GvGVYDDN_5egXp0t_fQPtHWjBVhqG92TCxO6Q@mail.gmail.com>
 <20150717014851.2813b7bf@fsol> <mogf1n$341$1@ger.gmane.org>
 <20150719183355.GP18503@tonks> <moh70v$152$1@ger.gmane.org>
 <20150720073238.GQ18503@tonks> <moj996$t4k$1@ger.gmane.org>
 <20150720173547.GS18503@tonks>
Message-ID: <mojo6o$s6e$1@ger.gmane.org>



On 07/20/2015 01:35 PM, Florian Bruhin wrote:
>>>>> > >>>m.assert_me()
>> >Traceback (most recent call last):
>> >   File "<stdin>", line 1, in <module>
>> >   File "/media/hda2/home/ra/Dev/python-dev/python3.5/cpython-master/Lib/unittest/mock.py",
>> >line 583, in __getattr__
>> >     raise AttributeError(name)
>> >AttributeError: assert_me
>> >
>> >
>> >Why is AttributeError raised here?  Why are methods beginning with assert
>> >special?  (or "unsafe")
> Some things I can think of:
>
> - It's more likely that you use assert_called() instead of
>    assert_called_with() accidentally than that you do a typo in your
>    code under test.
>
> - If you do a typo in your code under test, a linter is more likely to
>    find it than with mocks, because of their nature.
>
> - Other tests (even if they're manual ones) should probably discover
>    the typo in your real code. The always-passing assert won't.

But it doesn't always pass in the above.  It would fail if there is a typo. 
  You would need to make the same typo in the test and the mock the test uses.

With this, the only way to use methods beginning with assert is to set 
unsafe=True.  Then none of this applies.  And after a few times, it's 
likely a developer will get into the habit of doing that.  I wonder if it's 
going to do what the intent was?

Another reason mentioned by Nick, is to avoid shadowing mocks own methods. 
  But I would think a different exception could be used with an explicit 
error message regarding the exact reason would be better, by actually 
detecting the attribute shadows specific mock methods when the mock object 
is created rather than raising an AttributeError when it's called.

I'm thinking that would have been enough to find most of the errors 
including the use of "assret*" in the motivating case.   Which would of 
been a matter of just correcting the spelling.

"assret*" would have raised an Attribute error if it was spelled that way 
in the test, or "assert*" would have raised an Attribute error if it was 
spelled "assret*" in the object used in the test.

Do these seem accurate to you?


The problems seem to only occur be when no spec is given.

Blocking use of "assert*" when a spec is given is more than needed, but 
detecting shadowing of needed mock methods is needed.  That can be done 
sooner with better a better error message I think.

Using "assret*" in the objects being tested will never shadow a mock 
method.  So it seems it's a case of catching a mispelling in a test calling 
a non-existing method.  (But anyother spelling would not be caught.)


I think I'm starting to get it now,
    Ron
























From Steve.Dower at microsoft.com  Mon Jul 20 20:48:48 2015
From: Steve.Dower at microsoft.com (Steve Dower)
Date: Mon, 20 Jul 2015 18:48:48 +0000
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAOTD34aGB-vFHcuUfyfQ5jB8mXk7r31DeWtCGm_EgsOtVwA_ag@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAOTD34aGB-vFHcuUfyfQ5jB8mXk7r31DeWtCGm_EgsOtVwA_ag@mail.gmail.com>
Message-ID: <BLUPR0301MB1652916F679DB97A74CB176DF5850@BLUPR0301MB1652.namprd03.prod.outlook.com>

Dear Python-dev

Nobody who cares is reading this thread any more - I'm guessing Guido silenced it within the first 10 emails and so has almost everyone else. All you're doing is exposing your own inabilities to understand the issue (there are not now, have never been, and never will be, methods starting with 'assret'!) and upsetting active, potential and former ( :( ) contributors.

Just stop replying. *Especially* if you don't understand the issue and/or are not offering to fix it yourself (and if you do/are, take it to the tracker).

Thanks,
Python-dev


From ncoghlan at gmail.com  Tue Jul 21 09:40:00 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 21 Jul 2015 17:40:00 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the core
 development process? (was Re: How far to go with user-friendliness)
Message-ID: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>

On 20 July 2015 at 22:34, Ben Finney <ben+python at benfinney.id.au> wrote:
> Paul Moore <p.f.moore at gmail.com> writes:
>
>> Again, I'm sorry to pick on one sentence out of context, but it cut
>> straight to my biggest fear when doing a commit (on any project) -
>> what if, after all the worrying and consideration I put into doing
>> this commit, people disagree with me (or worse still, I made a
>> mistake)? Will I be able to justify what I decided?
>
> That seems quite healthy to me. On a collaborative project with effects
> far beyond oneself, yes, any change *should* be able to be justified
> when challenged.

No, that's not how this works: if folks are thinking that being a
Python user, or even a CPython core developer, means that we're
entitled to micromanage core developers by demanding extensive
explanations for any arbitrary commit we choose, they're thoroughly
mistaken. Only Guido has that privilege, and one of the reasons he's
as respected as he is is his willingness to trust the experience and
expertise of others and only rarely exercise his absolute authority.

Folks are granted core committer privileges because we *trust their
instincts*. We trust them to know when they're acting within the
limits of their own expertise and experience, and we trust them to
know when it would be beneficial to seek feedback from a wider
audience before making up their minds.

There are *many* cases where we *don't know* up front what the right
answer is, so we'll actively seek consultation, whether that's through
a review request on the issue tracker, a focused python-dev
discussion, a more speculative discussion on python-ideas, or engaging
in the full Python Enhancement Proposal process.

There are also cases where we'll decide "it seems plausible that this
might be a good idea, so let's try it out and see what happens in
practice rather than continuing to speculate" - only ever doing things
that you're already 100% certain are a good idea is a recipe for
stagnation and decline (hence the "Now is better than never" line in
the Zen). A feedback cycle of a few years is a relatively short time
in programming language development, so if we discover with the
benefit of hindsight that something that seemed plausible really was
in fact a genuinely bad idea, that's why we have a deprecation process
(as well as the abilty to mark new APIs as provisional). If we want a
faster feedback cycle measured in days or weeks or months rather than
years, then we'll find a way to make the idea available for
experimentation via PyPI or at least as a cookbook recipe or in a
public source repo.

But the authority and responsibility to make changes, to decide what
constitutes a reasonable risk, to decide which updates are appropriate
to send out to tens of millions of Python users worldwide remains
*ours*.

Some of those decisions will be akin to deciding to paint a bikeshed
blue instead of yellow (or green, or red, or chartreuse, or ...).
Others will be about mitigating the observed negative consequences of
a previous design decision while retaining the positive aspects.

Those kinds of design decision are still more art than science -
that's why our solution to them is to attempt to recruit people with
the interest, ability and time needed to make them well, and then
largely leave them to it. Explaining design decisions after the fact
isn't about *defending* those decisions, it's about attempting to
convey useful design knowledge, in order to help build new core
contributors (and also because explaining something to someone else is
a good way to understand it better yourself).

All of this is why the chart that I believe should be worrying people
is the topmost one on this page:
http://bugs.python.org/issue?@template=stats

Both the number of open issues and the number of open issues with
patches are steadily trending upwards. That means the bottleneck in
the current process *isn't* getting patches written in the first
place, it's getting them up to the appropriate standards and applied.
Yet the answer to the problem isn't a simple "recruit more core
developers", as the existing core developers are *also* the bottleneck
in the review and mentoring process for *new* core developers.

In my view, those stats are a useful tool we can use to ask ourselves
"Am I actually helping with this contribution, or at the very least,
not causing harm?":

* participating in the core-mentorship list, and actively looking for
ways to improve the effectiveness of the mentorship program (that
don't just queue up more work behind the existing core developer
bottleneck) should help make those stats better

* sponsoring or volunteering to help with the upstream projects our
core workflow tools are based on (Roundup, Buildbot) or with updating
our specific installations of them should help make those stats better
(and also offers faster iteration cycles than core development itself)

* helping core developers that have time to work on "CPython in
general" rather than specific projects of interest to them to focus
their attention more effectively may help make those stats better (and
it would be even better if we could credit such triaging efforts
appropriately)

* exploring ways to extract contribution metrics from Roundup so we
can have a more reliable detection mechanism for active and consistent
contributors than the "Mark 1 core developer memory, aka the
notoriously unreliable human brain" may help make those stats better

* helping out the upstream projects for one or both of the
forge.python.org proposals (Kallithea, Phabricator) that are designed
(at least in part) to remove core developers from the critical path
for management of the support repos like the developer guide and
Python Enhancement Proposals may help make those stats better

* getting more core contributors into a position where at least some
of their work time can be spent on facilitating upstream contributions
may help make those stats better (shifting at least some core
contribution activity to paid roles is also one of the keys to
countering the "free time for volunteer activities is inequitably
distributed" problem)

* alienating veteran core developers and encouraging them to spend
their time elsewhere will contribute to making those stats worse

* discouraging newly minted core developers from exercising their
granted authority will contribute to making those stats worse

* discouraging veteran core developers from recruiting new core
developers by contributing to creating a hostile environment on the
core mailing lists will *definitely* contribute to making those stats
worse

Make no mistake, sustainable open source development is a *genuinely
hard problem*. We're in a much better position than most projects
(being one of the top 5 programming languages in the world has its
benefits), but we're still effectively running a giant multinational
collaborative software development project with close to zero formal
management support. While their are good examples we can (and are)
learning from, improving the support structures for an already wildly
successful open source project without alienating existing
contributors isn't a task that comes with an instruction manual :)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From devel at baptiste-carvello.net  Tue Jul 21 11:27:56 2015
From: devel at baptiste-carvello.net (Baptiste Carvello)
Date: Tue, 21 Jul 2015 11:27:56 +0200
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
Message-ID: <mol3b9$p3q$1@ger.gmane.org>

Hello,

since this thread is restarting in debriefing mode: one thing struck me
as a non-committer following python-dev.

It seems that we (non-committers) have a difficulty making the
distinction between pre-implementation design discussions (PEPs beeing
the typical example), where relevant technical comments are welcome,
even on minor points, and post-commit discussions, where the maintainer
already made the design decisions, and discussing anything except real
bugs is unhelpful.

In this particular thread, the distinction was all the more blurred by
the very generic title. A thread titled something like "Commit-xxx:
should mock try to detect user typos?" would have been much less likely
to attract comments discussing principles in the abstract, without
taking the context into account.

Regards,

Baptiste


From ben+python at benfinney.id.au  Tue Jul 21 12:03:40 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 21 Jul 2015 20:03:40 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
	core development process? (was Re: How far to go with
	user-friendliness)
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
Message-ID: <85twsxomir.fsf@benfinney.id.au>

Nick Coghlan <ncoghlan at gmail.com> writes:

> On 20 July 2015 at 22:34, Ben Finney <ben+python at benfinney.id.au> wrote:
> > Paul Moore <p.f.moore at gmail.com> writes:
> >
> >> [?] my biggest fear when doing a commit (on any project) - what if,
> >> after all the worrying and consideration I put into doing this
> >> commit, people disagree with me (or worse still, I made a mistake)?
> >> Will I be able to justify what I decided?
> >
> > That seems quite healthy to me. On a collaborative project with
> > effects far beyond oneself, yes, any change *should* be able to be
> > justified when challenged.
>
> No, that's not how this works: if folks are thinking that being a
> Python user, or even a CPython core developer, means that we're
> entitled to micromanage core developers by demanding extensive
> explanations for any arbitrary commit we choose, they're thoroughly
> mistaken.

Definitely agreed, and I'm not implying otherwise.

There is a distinction to be drawn:

* If challenged to do so, could one (the contributor) present a
  compelling justification for the change?

  This is what I claim Paul Moore's doubt (fear?) is indicative of. I
  maintain that this doubt is quite healthy: it helps the contributor to
  pause, reflect, seek assistance in making decisions, and thereby also
  tends to exclude poorly-justified changes which would otherwise be
  committed.

* If a participant on this forum feels entitled to challenge a change,
  must the contributor present an arbitrary quantity of justification of
  each decision when challenged?

  This seems to be what many contributors object to, but I don't assert
  this at all. I never meant to imply that mere participation here
  entitles a person to demand justification for changes.

> Folks are granted core committer privileges because we *trust their
> instincts*. We trust them to know when they're acting within the
> limits of their own expertise and experience, and we trust them to
> know when it would be beneficial to seek feedback from a wider
> audience before making up their minds.

That's all good, and it's quite compatible with the healthy doubt I
described above.

> But the authority and responsibility to make changes, to decide what
> constitutes a reasonable risk, to decide which updates are appropriate
> to send out to tens of millions of Python users worldwide remains
> *ours*.

No objection from me.

I am not asking that contributors be at the mercy of limitless demands
for justification from arbitrary participants in this forum.

I am asking that contributors should *have* compelling justification for
any change they commit, if someone with sufficient authority were to ask
for it.

That doesn't make contributors any more answerable to arbitrary
participants here. It does make explicit that contributors, while
trusted of course, are answerable to more than their instincts and what
?feels right?: they are answerable also the community of core
contributors as a condition of that trust. They are also effectively
answerable to their own conscience about what justification that
community may ask in future.

-- 
 \      ?We suffer primarily not from our vices or our weaknesses, but |
  `\    from our illusions.? ?Daniel J. Boorstin, historian, 1914?2004 |
_o__)                                                                  |
Ben Finney


From p.f.moore at gmail.com  Tue Jul 21 13:19:25 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 21 Jul 2015 12:19:25 +0100
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <85twsxomir.fsf@benfinney.id.au>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
Message-ID: <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>

On 21 July 2015 at 11:03, Ben Finney <ben+python at benfinney.id.au> wrote:
> * If challenged to do so, could one (the contributor) present a
>   compelling justification for the change?
>
>   This is what I claim Paul Moore's doubt (fear?) is indicative of. I
>   maintain that this doubt is quite healthy: it helps the contributor to
>   pause, reflect, seek assistance in making decisions, and thereby also
>   tends to exclude poorly-justified changes which would otherwise be
>   committed.

That is *not* what I was trying to express. My fear is that I will be
subjected to the sort of unreasonable level of debate and frankly
criticism that came up in this thread, and I'm not sure if I have the
energy to deal with it. I wouldn't ever commit something unless *in my
judgement* it was OK to go in. Whether my judgement is sufficient is
the whole point here.

And to be honest, there's an implication in your comment that you
think there is a possibility that any of the core devs might commit
something when they had a level of doubt[1] about whether it was right
to do so. I think that implication is unwarranted, and constitutes
exactly the sort of subtle criticism that escalates things like this.
I'm sure that's not what you intended, and I *know* I've reached a
point with this thread where I'm over-sensitive to such implications,
but it's a good illustration of how even a well-meaning comment can be
perceived very differently than it was intended by the recipient.

For something which is a hobby for me, I'd rather feel more joy in
what I achieve, and less burden of responsibility. Changing code that
affects I-don't-even-want-to-know-how-many people and businesses is
quite enough responsibility without also having to put up with only
hearing from people who disagree with what I do, and never from people
who are grateful...

End of unnecessarily emotional outpouring, we now return you to your
regular scheduled flamewars :-)

Paul

[1] That's doubt, not mistakes. People make mistakes. The big problem
here is python-dev is becoming pretty hostile to people who (are
perceived to) make mistakes. That is, ultimately, all of us.

From ncoghlan at gmail.com  Tue Jul 21 14:43:40 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 21 Jul 2015 22:43:40 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
Message-ID: <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>

On 21 July 2015 at 21:19, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21 July 2015 at 11:03, Ben Finney <ben+python at benfinney.id.au> wrote:
>> * If challenged to do so, could one (the contributor) present a
>>   compelling justification for the change?
>>
>>   This is what I claim Paul Moore's doubt (fear?) is indicative of. I
>>   maintain that this doubt is quite healthy: it helps the contributor to
>>   pause, reflect, seek assistance in making decisions, and thereby also
>>   tends to exclude poorly-justified changes which would otherwise be
>>   committed.
>
> That is *not* what I was trying to express. My fear is that I will be
> subjected to the sort of unreasonable level of debate and frankly
> criticism that came up in this thread, and I'm not sure if I have the
> energy to deal with it. I wouldn't ever commit something unless *in my
> judgement* it was OK to go in. Whether my judgement is sufficient is
> the whole point here.

Exactly. Being granted a commit bit means "The folks that got CPython
to where it is today trust you to take appropriate risks in guiding
CPython's future". It can be safely assumed that *everyone* that has
that authority takes it *very* seriously (otherwise they wouldn't have
been granted commit privileges).

If there weren't any risks to be weighed and judgment calls to be
made, we could let a computer decide what commits should go in (and
indeed "make patchcheck" already handles some of those basic tasks,
and we'd like to automate even more of them like "does this patch
apply, and do the tests still pass on x86_64 under at least Windows
and a long term support Linux distro after applying it?"). This
challenge is reflected in the fact that the Zen of Python is
deliberately self-contradictory, as it articulates competing design
principles to take into consideration, rather than being able to
provide ironclad rules that avoid the need for human judgement in
determining *which* of those design guidelines are most salient in any
given situation.

Now, proposing further *enhancements* to a change is perfectly
reasonable, especially if the feedback is based on practical
experience with the original version of the change. The implementation
of PEP 492 (async/await), for example, underwent some fundamental
changes during the beta process, as developers' feedback showed that
some of the design decisions we made in the original version were
quite problematic. The original exception suppression mechanism in PEP
409 (which made clever-but-idiosyncratic use of Ellipsis), was
replaced with the simpler mechanism in PEP 415 (which instead uses a
more conventional setter-with-side-effects-on-other-attributes
approach).

Reverting changes because they broke the buildbots, or because they're
determined to cause bugs worse than the original problem is also not a
problem - in those cases, there's new information introduced into the
situation that changes the original risk assessment. An example of
that was deciding to deprecate and remove contextlib.nested() before
I'd figured out how to replace its legitimate use cases - I'd flat out
missed a fundamental problem with the way it interacted with open()
and similar resource allocation functions.

The draining and demotivating cases are the ones where *no new
information is introduced*, but the design decision is *challenged
anyway*. Those are the ones that feel like folks are saying "We don't
*actually* trust you with that authority and responsibility you've
been granted, so we're going to closely police the way you use it, and
expect to be able to persuade you to change your mind not through
reasoned argument, but through sheer volume".

For new core developers, or folks aspiring to become core developers,
it is *literally* the scenario that inspired Poul-Henning Kamp to
write the post at http://bikeshed.org/ (hit refresh if you get a low
contrast colour scheme, it will change). Don't bother trying to
improve anything, you'll just get grief and opposition for it rather
than community support.

For experienced core developers, it's a "Right, so you trust me to
build the nuclear power plant, but not to choose the colour of the
bike shed behind it" situation. Knowing we're trusted to build power
plants, but will get grief for working on smaller things creates an
even greater incentive to work solely on the big changes, and those
are already inherently more fun to work on anyway - they really don't
need the extra help.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From bobcatfish at gmail.com  Mon Jul 20 20:48:20 2015
From: bobcatfish at gmail.com (Christie Wilson)
Date: Mon, 20 Jul 2015 11:48:20 -0700
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAOTD34aGB-vFHcuUfyfQ5jB8mXk7r31DeWtCGm_EgsOtVwA_ag@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAOTD34aGB-vFHcuUfyfQ5jB8mXk7r31DeWtCGm_EgsOtVwA_ag@mail.gmail.com>
Message-ID: <CAC=pj-31y6cjgkLzyt71_gkVNwC5mwEDS2UaAwhdDtx27oz6qA@mail.gmail.com>

I am terrified of replying to this thread since so many folks on it seem
unhappy that it is continuing, but I want to +1 what Erik said.

Robert's solution is downright inspiring in how it gets to the heart of the
problem that the assret/assert feature is trying to address, and as a
frequent user of mock, I very much would like to see it implemented.

On Mon, Jul 20, 2015 at 11:30 AM, Erik Bray <erik.m.bray at gmail.com> wrote:

> On Tue, Jul 14, 2015 at 6:22 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
> > For clarity, I think we should:
> >  - remove the assret check, it is I think spurious.
> >  - add a set of functions to the mock module that should be used in
> > preference to Mock.assert*
> >  - mark the Mock.assert* functions as PendingDeprecation
> >  - in 3.6 move the PendingDeprecation to Deprecated
> >  - in 3.7 remove the Mock.assert* functions and the check for method
> > names beginning with assert entirely.
>
> Hi all,
>
> I'm just an onlooker, and haven't read every word of this thread.  In
> fact I worry that it's pointless to reply to rather than starting a
> new thread.  I just wanted to make sure that the specific message I'm
> replying too wasn't lost in the noise because I think Robert's
> suggestion makes vastly more sense than anything else I've seen here
> (I came searching through the thread to see if anyone else suggested
> this before I started a thread to do so).
>
> I don't think it makes any sense to have magic assert_ methods on the
> Mock object.  Not only does the "magic" clearly lead to too many
> ambiguities and other problems--I think they make less sense from an
> API standpoint in the first place.  Typically asserting something in a
> test is not something an object *does*--a method.  More often we as a
> test writers assert something *about* an object.  The assertion is an
> external tool meant to measure and introspect things about the system
> under observation.  In this case, although Mock is itself a testing
> tool, we're introspecting something about the Mock object as external
> observers.
>
> ***Assertions on Mock objects should be implemented as stand-alone
> functions (that happen to be used primarily on Mock objects as
> input).***
>
> Aside from, in my mind, making more sense philosophically, using
> specialized assert functions for this has absolutely none of the
> spelling ambiguities or other problems of the magic methods.
>
> I'm -0 on removing the assret_ methods unless no one is using them
> yet.  I don't care if they're there as long as they're deprecated
> along with the other magic methods of Mock.
>
> Best,
> Erik
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com
>



-- 
Christie Wilson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150720/a0d9aefc/attachment.html>

From mail at timgolden.me.uk  Tue Jul 21 17:47:40 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Tue, 21 Jul 2015 16:47:40 +0100
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAC=pj-31y6cjgkLzyt71_gkVNwC5mwEDS2UaAwhdDtx27oz6qA@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info> <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAOTD34aGB-vFHcuUfyfQ5jB8mXk7r31DeWtCGm_EgsOtVwA_ag@mail.gmail.com>
 <CAC=pj-31y6cjgkLzyt71_gkVNwC5mwEDS2UaAwhdDtx27oz6qA@mail.gmail.com>
Message-ID: <55AE699C.8000506@timgolden.me.uk>

On 20/07/2015 19:48, Christie Wilson wrote:
> I am terrified of replying to this thread since so many folks on it seem
> unhappy that it is continuing, but I want to +1 what Erik said.

Don't be terrified :)

But do understand that, in general, and especially for this
already-noisy thread, the right place for arguments supporting a change
or a reversion is usually on the issue tracker:

 https://bugs.python.org/

I don't know whether Robert's opened an issue to propose his solution,
but if not, you could open one and add him as nosy.

TJG

From robertc at robertcollins.net  Tue Jul 21 17:56:34 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 22 Jul 2015 03:56:34 +1200
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
Message-ID: <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>

On 21 July 2015 at 00:34, Ben Finney <ben+python at benfinney.id.au> wrote:
> Paul Moore <p.f.moore at gmail.com> writes:
>
>> Again, I'm sorry to pick on one sentence out of context, but it cut
>> straight to my biggest fear when doing a commit (on any project) -
>> what if, after all the worrying and consideration I put into doing
>> this commit, people disagree with me (or worse still, I made a
>> mistake)? Will I be able to justify what I decided?
>
> That seems quite healthy to me. On a collaborative project with effects
> far beyond oneself, yes, any change *should* be able to be justified
> when challenged.

Depending on what you mean by justification , this leaves no leeway
for hunches, feelings, intuition, or grey area changes.

It's also a terrible way to treat people that are contributing their
own time and effort: assume good faith is a much better starting
point.

I think its reasonable to say that any change should be open to post
hoc discussion. Thats how we learn, but justification and challenging
is an adversarial framing, and one I'm flatly uninterested in. Life is
too short to volunteer on adversarial activies.

> That isn't a mandate to challenge every change, of course. It does mean
> that every change should be considered in light of ?Can I justify
> this, if challenged??
>
> So what you describe sounds like a healthy barrier: one which works to
> keep out unjustifiable changes.

I don't understand why thats healthy or useful.

> What is needed is to have both that *and* the support of the community
> so it's not a barrier to the *contributors*. The contributors should not
> feel excluded merely because some of their changes might need to be.

I don't think that contributors are a problem here. But, I'm going to
dig into that more in reply to Nick.

>> Hmm, maybe I'd better hold off and let someone else make the
>> decision...
>
> What of the (obvious, to me) option to retain the authority to make the
> decision, but take the doubt as a sign that one should consult with
> others before making the decision?
>
> That is, there's no need to feel that one shouldn't make the decision.
> But perhaps one shouldn't make it solely on one's own experience or
> insight. Get others involved, even non-committers, and discuss it, and
> understand the issue better. With that improved basis, then make the
> decision.

As a case study, this discussion where something like 90% of the
kibbitzing demonstrated a clear lack of understanding of the very
behaviour of Mock, *and* the change in question was discussed, *prior*
to it being done, *and* users have welcomed it....I must conclude that
either:
 - this discussion was the exception to prove your general rule (but
why would we derive that general rule from this discussion)
 - the general rule isn't general.

> Am I naive to think that's desirable for PYthon core committers?

What's the goal here: what actual problem are we trying to solve for?

More contributors? A better Python more people can use? Keeping up
with the contributions we've already received but not actioned? [...]

Like: pick one thing. What we /really/ want to achieve, then lets look
at what will let us get there.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From robertc at robertcollins.net  Tue Jul 21 18:11:03 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 22 Jul 2015 04:11:03 +1200
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
Message-ID: <CAJ3HoZ3F9o9Qt90OeEvS_awGiG_Y5Cruz=U45+xsx=XQ8R4RXA@mail.gmail.com>

On 21 July 2015 at 19:40, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 20 July 2015 at 22:34, Ben Finney <ben+python at benfinney.id.au> wrote:
>> Paul Moore <p.f.moore at gmail.com> writes:
>>
>>> Again, I'm sorry to pick on one sentence out of context, but it cut
>>> straight to my biggest fear when doing a commit (on any project) -
>>> what if, after all the worrying and consideration I put into doing
>>> this commit, people disagree with me (or worse still, I made a
>>> mistake)? Will I be able to justify what I decided?
>>
>> That seems quite healthy to me. On a collaborative project with effects
>> far beyond oneself, yes, any change *should* be able to be justified
>> when challenged.
>
> No, that's not how this works: if folks are thinking that being a
> Python user, or even a CPython core developer, means that we're
> entitled to micromanage core developers by demanding extensive
> explanations for any arbitrary commit we choose, they're thoroughly
> mistaken. Only Guido has that privilege, and one of the reasons he's
> as respected as he is is his willingness to trust the experience and
> expertise of others and only rarely exercise his absolute authority.

I wouldn't even agree that Guido is entitled to micromanage us. He is
certainly entitled to demand explanations etc if he feels appropriate
- but if that turned into micromanaging, I think we'd be in a very bad
place.

> All of this is why the chart that I believe should be worrying people
> is the topmost one on this page:
> http://bugs.python.org/issue?@template=stats
>
> Both the number of open issues and the number of open issues with
> patches are steadily trending upwards. That means the bottleneck in
> the current process *isn't* getting patches written in the first
> place, it's getting them up to the appropriate standards and applied.

Perhaps.

> Yet the answer to the problem isn't a simple "recruit more core
> developers", as the existing core developers are *also* the bottleneck
> in the review and mentoring process for *new* core developers.

sidebar: So, anyone here familiar with theory of constraints - e.g.
'The Goal', 'Critical Chain' etc? Might be interesting to do some
brainstorming in that shape if folk are interest.

Having open idle patches is I think generally acknowledged as a poor
thing. I think of them as inventory in a manufacturing plant: they
take up space, they take effort to create, they offer no value [until
they're actually shipped to users], and they have direct negatives
(tracker is harder to work with due to the signal-to-noise ratio,
perception of the project suffers, contributors make the rational
discussion not to contribute further...).

Lets assume that our actual goal is to ship new Python versions,
offering more and better things to users.

AFAIK we're not lacking any infrastructure resources - we have enough
buildbots, we have freely available compilers for all platforms.

> In my view, those stats are a useful tool we can use to ask ourselves
> "Am I actually helping with this contribution, or at the very least,
> not causing harm?":

I like this approach  :). But - can we go further, can we actively
protect core committer time such that they waste less of it? Adding
core committers won't help if the problem isn't the number of
committers, but rather the amount of the time that they can devote to
Python that actually gets spent on committer-activities.

> * helping core developers that have time to work on "CPython in
> general" rather than specific projects of interest to them to focus
> their attention more effectively may help make those stats better (and
> it would be even better if we could credit such triaging efforts
> appropriately)

Iterating on a patch someone else put up can help. Making sure its
passing tests, trying it with ecosystem projects and giving feedback.

> * exploring ways to extract contribution metrics from Roundup so we
> can have a more reliable detection mechanism for active and consistent
> contributors than the "Mark 1 core developer memory, aka the
> notoriously unreliable human brain" may help make those stats better

OTOH, make sure that what we measure provokes things that help our
goal :). Double edged sword this.

> Make no mistake, sustainable open source development is a *genuinely
> hard problem*. We're in a much better position than most projects
> (being one of the top 5 programming languages in the world has its
> benefits), but we're still effectively running a giant multinational
> collaborative software development project with close to zero formal
> management support. While their are good examples we can (and are)
> learning from, improving the support structures for an already wildly
> successful open source project without alienating existing
> contributors isn't a task that comes with an instruction manual :)

+1

-Rob

From robertc at robertcollins.net  Tue Jul 21 18:23:43 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 22 Jul 2015 04:23:43 +1200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <55AE699C.8000506@timgolden.me.uk>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <20150714135142.GW32275@tonks>
 <CACac1F84xrd+KjAmiLGQ3C2Rw7o_gaAM33wwaYBzi-4uxco8Zw@mail.gmail.com>
 <55A53E8D.5090009@stoneleaf.us>
 <20150714214114.GA54001@natl2235llmcal2.cmg.int>
 <CAJ3HoZ09ihziZLAm7npYspgMMvc6u1MV90RvH9dAUzBtwO8pFQ@mail.gmail.com>
 <55A5879F.1050305@stoneleaf.us>
 <CAJ3HoZ2Ln_oLkgPQktixFMP-D+c_WiPc+U_AuFmSbh+o3+nhYg@mail.gmail.com>
 <CAOTD34aGB-vFHcuUfyfQ5jB8mXk7r31DeWtCGm_EgsOtVwA_ag@mail.gmail.com>
 <CAC=pj-31y6cjgkLzyt71_gkVNwC5mwEDS2UaAwhdDtx27oz6qA@mail.gmail.com>
 <55AE699C.8000506@timgolden.me.uk>
Message-ID: <CAJ3HoZ0MDt8q=147dTAAq9kud34gJcGKGPfop-xBtBaWLMmB4Q@mail.gmail.com>

On 22 July 2015 at 03:47, Tim Golden <mail at timgolden.me.uk> wrote:
> On 20/07/2015 19:48, Christie Wilson wrote:
>> I am terrified of replying to this thread since so many folks on it seem
>> unhappy that it is continuing, but I want to +1 what Erik said.
>
> Don't be terrified :)
>
> But do understand that, in general, and especially for this
> already-noisy thread, the right place for arguments supporting a change
> or a reversion is usually on the issue tracker:
>
>  https://bugs.python.org/
>
> I don't know whether Robert's opened an issue to propose his solution,
> but if not, you could open one and add him as nosy.

I did: http://bugs.python.org/issue24651

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From robertc at robertcollins.net  Tue Jul 21 18:35:29 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 22 Jul 2015 04:35:29 +1200
Subject: [Python-Dev] Reminder: Python 3.5 beta 4 is tagged in one week
In-Reply-To: <55AA2955.8030404@hastings.org>
References: <55AA2955.8030404@hastings.org>
Message-ID: <CAJ3HoZ0W8n61XhtCR8jaz=nBmkqLQK7puVdgFLQQtZDY9Kq55g@mail.gmail.com>

Cool. http://bugs.python.org/issue21750 is in a bad state right now.

I landed a patch to fix it, which when exposed to users had some
defects. I'm working on a better patch now, but need to either roll
the prior patch completely back, or get the new one landed before the
next beta. I hope to have that up for review later today {fingers
crossed} - will that be soon enough, or should I look up how to easily
revert stuff out with hg?

-Rob

On 18 July 2015 at 22:24, Larry Hastings <larry at hastings.org> wrote:
>
>
> Approximately a week from when I post this, I'll be tagging Python 3.5 beta
> 4, which is the last beta before we go to release candidates.  Please wind
> up all your bug fixes soon, I'd really like checkins to 3.5 to stop soon.
>
> And a minor reminder: when we hit Release Candidate 1, I'll be switching the
> canonical repo for 3.5 to a public Bitbucket repo.  Any bug fixes that go in
> between RC 1 and final will only be merged using Bitbucket "pull requests".
>
> The new workflow experiment continues,
>
>
> /arry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/robertc%40robertcollins.net
>



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From larry at hastings.org  Tue Jul 21 19:08:41 2015
From: larry at hastings.org (Larry Hastings)
Date: Tue, 21 Jul 2015 19:08:41 +0200
Subject: [Python-Dev] Reminder: Python 3.5 beta 4 is tagged in one week
In-Reply-To: <CAJ3HoZ0W8n61XhtCR8jaz=nBmkqLQK7puVdgFLQQtZDY9Kq55g@mail.gmail.com>
References: <55AA2955.8030404@hastings.org>
 <CAJ3HoZ0W8n61XhtCR8jaz=nBmkqLQK7puVdgFLQQtZDY9Kq55g@mail.gmail.com>
Message-ID: <55AE7C99.6020801@hastings.org>



On 07/21/2015 06:35 PM, Robert Collins wrote:
> Cool. http://bugs.python.org/issue21750 is in a bad state right now.
>
> I landed a patch to fix it, which when exposed to users had some
> defects. I'm working on a better patch now, but need to either roll
> the prior patch completely back, or get the new one landed before the
> next beta. I hope to have that up for review later today {fingers
> crossed} - will that be soon enough, or should I look up how to easily
> revert stuff out with hg?

If you want to undo it, "hg backout" is the command you want.  In 
general it's best to not check in broken stuff.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150721/fbc92ad6/attachment.html>

From willingc at willingconsulting.com  Tue Jul 21 19:06:57 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Tue, 21 Jul 2015 10:06:57 -0700
Subject: [Python-Dev] Devguide - Add Communications Quick Start Section
Message-ID: <55AE7C31.6070600@willingconsulting.com>

I would like to add a "Communications Quick Start" section to the 
beginning of the Python Developer's Guide.

Productive communication between each other will always be critical to 
future development of CPython and maintaining releases, infrastructure, 
documentation, and more.

Unproductive communication saps energy of contributors, reduces 
engagement in the project, and limits creativity and fulfillment in 
contributing. As a contributor who finds great value in the power and 
zen of Python, I want to foster more effective and productive 
communication. I've been thinking about ways to do this since the PyCon 
sprints. New developers would benefit from understanding how to interact 
with the community and its norms. Existing contributors would hopefully 
benefit from less time reexplaining community communication norms.

The Communications Quick Start section would be brief and practical much 
like the Quick Start section for downloading and testing the source 
code. Placing the Communications Quick Start section before the existing 
Quick Start section would emphasize the importance that productive 
communications has on CPython development.

Thanks,
Carol

P.S. Thank you to all that devote time and energy to the development of 
CPython. I have posted this to the python-dev mailing list for feedback 
due to the recent discussions. Nick and Brett, please feel free to move 
this to python-ideas if you feel that would be a better place to discuss 
this addition to the devguide.

From brett at python.org  Tue Jul 21 20:08:20 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 21 Jul 2015 18:08:20 +0000
Subject: [Python-Dev] Devguide - Add Communications Quick Start Section
In-Reply-To: <55AE7C31.6070600@willingconsulting.com>
References: <55AE7C31.6070600@willingconsulting.com>
Message-ID: <CAP1=2W6o7fD5bjAR2i6n=tmPv3y-eA14CHuAumgQP+nbYNZ46Q@mail.gmail.com>

On Tue, Jul 21, 2015 at 11:05 AM Carol Willing <
willingc at willingconsulting.com> wrote:

> I would like to add a "Communications Quick Start" section to the
> beginning of the Python Developer's Guide.
>
> Productive communication between each other will always be critical to
> future development of CPython and maintaining releases, infrastructure,
> documentation, and more.
>
> Unproductive communication saps energy of contributors, reduces
> engagement in the project, and limits creativity and fulfillment in
> contributing. As a contributor who finds great value in the power and
> zen of Python, I want to foster more effective and productive
> communication. I've been thinking about ways to do this since the PyCon
> sprints. New developers would benefit from understanding how to interact
> with the community and its norms. Existing contributors would hopefully
> benefit from less time reexplaining community communication norms.
>
> The Communications Quick Start section would be brief and practical much
> like the Quick Start section for downloading and testing the source
> code. Placing the Communications Quick Start section before the existing
> Quick Start section would emphasize the importance that productive
> communications has on CPython development.
>

Sounds great to me! Social norms are just as important to get to speed on
as technical requirements when contributing to an open source community, so
this seems like a worthy project.


>
> Thanks,
> Carol
>
> P.S. Thank you to all that devote time and energy to the development of
> CPython. I have posted this to the python-dev mailing list for feedback
> due to the recent discussions. Nick and Brett, please feel free to move
> this to python-ideas if you feel that would be a better place to discuss
> this addition to the devguide.
>

Nope, here is fine. This isn't a new idea and it affects people on this
list more directly than the python-ideas folks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150721/c27456c5/attachment.html>

From tjreedy at udel.edu  Tue Jul 21 21:53:37 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 21 Jul 2015 15:53:37 -0400
Subject: [Python-Dev] Devguide - Add Communications Quick Start Section
In-Reply-To: <55AE7C31.6070600@willingconsulting.com>
References: <55AE7C31.6070600@willingconsulting.com>
Message-ID: <mom80o$1kv$1@ger.gmane.org>

On 7/21/2015 1:06 PM, Carol Willing wrote:
> I would like to add a "Communications Quick Start" section to the
> beginning of the Python Developer's Guide.

I would rename 'Quick Start' to 'Quick Start: Code Development' and add 
'Quick Start: Communications' (or maybe 'Q S: Community Interaction'). 
I am not sure about the order.

Unless there is opposition I do not expect, go ahead and open an issue.


-- 
Terry Jan Reedy


From robertc at robertcollins.net  Tue Jul 21 22:07:25 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 22 Jul 2015 08:07:25 +1200
Subject: [Python-Dev] Reminder: Python 3.5 beta 4 is tagged in one week
In-Reply-To: <55AE7C99.6020801@hastings.org>
References: <55AA2955.8030404@hastings.org>
 <CAJ3HoZ0W8n61XhtCR8jaz=nBmkqLQK7puVdgFLQQtZDY9Kq55g@mail.gmail.com>
 <55AE7C99.6020801@hastings.org>
Message-ID: <CAJ3HoZ2euStKc=60br0Yho+4UqauPc7kSDXiiwAdC-fKO=+VNg@mail.gmail.com>

On 22 July 2015 at 05:08, Larry Hastings <larry at hastings.org> wrote:
>
>
> On 07/21/2015 06:35 PM, Robert Collins wrote:
>
> Cool. http://bugs.python.org/issue21750 is in a bad state right now.
>
> I landed a patch to fix it, which when exposed to users had some
> defects. I'm working on a better patch now, but need to either roll
> the prior patch completely back, or get the new one landed before the
> next beta. I hope to have that up for review later today {fingers
> crossed} - will that be soon enough, or should I look up how to easily
> revert stuff out with hg?
>
>
> If you want to undo it, "hg backout" is the command you want.  In general
> it's best to not check in broken stuff.

Thanks. And yes, naturally - we didn't realise it was broken. Passing
tests != fit for purpose.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From joseph.vitale at bnymellon.com  Wed Jul 22 00:20:36 2015
From: joseph.vitale at bnymellon.com (Vitale, Joseph)
Date: Tue, 21 Jul 2015 22:20:36 +0000
Subject: [Python-Dev] Python 3.4.3 on RedHat 6.6 s390x make fails with:
 make: *** [sharedmods] Error 139
Message-ID: <707B1F493DFA6A4DA1EFBBED57369A6D0134F9840A@WTPCPMBMEM09.ams.bnymellon.net>

Hello,

Trying to install Python 3.4.3  on Red Hat  6.6 zLinux(s390x)  but "make" fails and core dumps.  Not using OpenSSL and did not configure for it.

Can you provide direction?


./configure

make

 gcc -pthread -fPIC -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

 -Werror=declaration-after-statement -I/usr/local/ssl/include

 -I./Include -I. -IInclude -I/usr/local/include

 -I/xjp/Python-3.4.3/Include -I/xjp/Python-3.4.3 -c

 /xjp/Python-3.4.3/Modules/_ssl.c -o

 build/temp.linux-s390x-3.4/xjp/Python-3.4.3/Modules/_ssl.o

gcc -pthread -shared

 build/temp.linux-s390x-3.4/xjp/Python-3.4.3/Modules/_ssl.o

 -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o

 build/lib.linux-s390x-3.4/_ssl.cpython-34

m.so



/bin/sh: line 6: 48734 Segmentation fault      (core dumped) CC='gcc -pthread' LDSHARED='gcc -pthread -shared  ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' _TCLTK_I

NCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py $quiet build

make: *** [sharedmods] Error 139

Thanks

Joe

The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures relating to European legal entities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150721/bd43b2fb/attachment.html>

From stephen at xemacs.org  Wed Jul 22 02:38:15 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 22 Jul 2015 09:38:15 +0900
Subject: [Python-Dev] How do we tell if we're helping or hindering
	the	core development process? (was Re: How far to go
	with	user-friendliness)
In-Reply-To: <85twsxomir.fsf@benfinney.id.au>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
Message-ID: <87r3o1do20.fsf@uwakimon.sk.tsukuba.ac.jp>

Ben Finney writes:

 > Definitely agreed, and I'm not implying otherwise.
 > 
 > There is a distinction to be drawn:
 > 
 > * If challenged to do so, could one (the contributor) present a
 >   compelling justification for the change?

Aside from Paul's disclaimer, this is way too high a bar.  Nick tried
to express that in his post, but I doubt it's possible to successfully
communicate what Nick means in a mailing list post because it's a very
subtle distinction that requires a lot of "what could he be thinking"
effort from *each* reader to convey.

 > * If a participant on this forum feels entitled to challenge a
 >   change, must the contributor present an arbitrary quantity of
 >   justification of each decision when challenged?

This expression is improperly restrictive.  Contributors object to it
because it's objectively objectionable, and easy to express.  But they
also don't want to wade through arbitrary amounts of feedback which is
often context-free and/or actually misguided.  They don't want to
explain a point multiple times to casual readers who miss it, or spend
the inordinate amount of effort required to compose a post that covers
all the context needed in terms that all the casual readers can parse.
All that is much harder to explain in terms which will result in
*well-informed, to-the-point* feedback, and without sounding like "I
know what I'm doing so STFU" (the recent "to python-dev from
python-dev" post is an example of the kind of wording that can be
misinterpreted this way).

So people object to "micro-management" as a summary of frustration,
but the actual sematics are complex and subtle.



From stephen at xemacs.org  Wed Jul 22 04:18:42 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 22 Jul 2015 11:18:42 +0900
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
Message-ID: <87pp3ldjel.fsf@uwakimon.sk.tsukuba.ac.jp>

Nick Coghlan writes:

 > The draining and demotivating cases are the ones where *no new
 > information is introduced*, but the design decision is *challenged
 > anyway*.

But this particular thread is an extreme case, that demonstrates why
this kind of thing happens *despite* the good intentions of everyone
involved.  The design decision (to special-case a typo) that was made
is a true "WTF?!"  The "meta" of "special cases aren't special enough
to break the rules" is that no design decision that violates it should
be dismissed as "minor".  In context of a mailing list, doing so is
going to be taken by readers as "I know what I'm doing, and you don't
know what you're talking about, so STFU."

The average poster to Python-Dev surely trusts the core developers to
know what they're doing.  If you (as the developer or developers on
the spot) don't have time to explain, at least indicate that the
process implied in

 > Folks are granted core committer privileges because we *trust their
 > instincts*. We trust them to know when they're acting within the
 > limits of their own expertise and experience, and we trust them to
 > know when it would be beneficial to seek feedback from a wider
 > audience before making up their minds.

was followed.[1]  Something like

    The special case of trapping the typo "assret" was discussed on
    python-committers.  The conclusion was that in the special context
    of mock this is a case where "practicality beats purity".  In any
    case, the decision has been discussed thoroughly and isn't going
    to change in the absence of truly new information, so further
    discussion here is pointless.  Let's move on.

would have stopped the thread in its tracks, I believe.[2]  But
repeated unexplained assertions that the design decision is "minor"
were just a red cape to a bull.  That explanation just *feels*
*wrong*, it causes massive cognitive dissonance -- and makes it very
hard for readers to respond appropriately to perfectly valid
explanations that "this is not the time to make a change anyway".

 > Those are the ones that feel like folks are saying "We don't
 > *actually* trust you with that authority and responsibility you've
 > been granted, so we're going to closely police the way you use it, and
 > expect to be able to persuade you to change your mind not through
 > reasoned argument, but through sheer volume".

This is a fallacy, very human, but still the fallacy of
anthropomorphizing a crowd.  A very few people repeatedly posted with
the content limited to "Special cases aren't", but most expressed
their puzzlement in varied ways over time.  Of course all of them
started with "special cases aren't", which is why the proponents feel
browbeaten.

*Both* roles in this comedy of errors are natural, they are inherent
in human cognition (citations on request), and nobody is to be blamed.
At Python's scale, *some* (not all) of the core developers are going
to need to recognize the "crowd" dynamic and deal with it -- or Python
won't scale any further IMO.  (In theory there may be better channels
than mailing lists which would inhibit this dynamic, but I don't know
of any practical ones.)

 > Don't bother trying to improve anything, you'll just get grief and
 > opposition for it rather than community support.
 > 
 > For experienced core developers, it's a "Right, so you trust me to
 > build the nuclear power plant, but not to choose the colour of the
 > bike shed behind it" situation.

Et tu, Brutus!  This point has been made *so* many times in this
thread.  Surely you don't think anybody missed it!<wink/>

The only *practical* suggestion from "the core" has been self-
restraint on the part of "the crowd".  But that has severe limits
*because* the "crowd" is made up of people who "aren't Dutch yet".
They *are* going to ask questions, and as Python Dev gets bigger, more
of them are going to ask questions, and in particularly controversial
cases they are going to ask more or less simultaneously, resulting in
the "browbeating effect".

I think it's time to either end this "meta" thread, or refocus it from
"why contributors feel sad" and "why we should trust committers"
(AFAICS there is actually consensus on both, although sometimes
expressed as apparent disagreement) to discussion of practical ways to
resolve the conflict.  That is the conflict between the need of actual
contributors to get to-the-point feedback and the need of contributors-
in-embryo to learn what's going on.  Sadly, as long as the proposed
"Communication" section in the devguide concentrates on the
responsibility of commenters to exercise restraint to the exclusion of
the possibility of "somebody" managing threads, it's not going to help
much IMO.  Python Dev is *already* as civil a forum as any I've seen,
considering its scale and its success in recruiting new contributors
at all levels of maturity.

Steve

Footnotes: 
[1]  It occurs to me that pointing to existing discussion actually is
the responsibility of an OP who "promotes" a discussion from the
tracker or python-committers to python-dev.  Or perhaps the proponents
should have promoted to python-dev themselves.  But I haven't got time
to think that through.

[2]  N.B.  Those four sentences were indeed posted several times in
various combinations.  But never all at once and together, and that's
what's needed to have the thread-stopping effect.


From Nikolaus at rath.org  Wed Jul 22 05:23:15 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Tue, 21 Jul 2015 20:23:15 -0700
Subject: [Python-Dev] How do we tell if we're helping or hindering the
	core development process?
In-Reply-To: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 (Nick Coghlan's message of "Tue, 21 Jul 2015 17:40:00 +1000")
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
Message-ID: <87d1zkq3j0.fsf@vostro.rath.org>

On Jul 21 2015, Nick Coghlan <ncoghlan at gmail.com> wrote:
> All of this is why the chart that I believe should be worrying people
> is the topmost one on this page:
> http://bugs.python.org/issue?@template=stats
>
> Both the number of open issues and the number of open issues with
> patches are steadily trending upwards. That means the bottleneck in
> the current process *isn't* getting patches written in the first
> place, it's getting them up to the appropriate standards and applied.
> Yet the answer to the problem isn't a simple "recruit more core
> developers", as the existing core developers are *also* the bottleneck
> in the review and mentoring process for *new* core developers.

As a random datapoint:

Early last year I wanted get involved in CPython development. In the
next months I submitted and reviewed maybe 20 - 25 patches in the bug
tracker. After seeing all of them languish, I stopped submitting and
reviewing and just tried to get someone to look at the issues that I'd
worked on. Eventually, I managed to get almost all of them committed
(the last one sometime this February, after more than a year). However,
it was such an uphill battle just to get someone to look at my
contributions that I haven't touched the bugtracker ever since.

If it were up to me, I'd focus all the resources of the PSF on reducing
this backlog - be that by hiring some core developers to work full-time
on just the open bugtracker issues, or by financing development of
better code review and commit infrastructure. The current situation
looks like a downward spiral to me. New contributors are frustrated and
leave because they feel their contribution is not welcome, and core
developers get burned out by the gigantic backlog and the interaction
with frustrated patch submitters - thus further reducing the available
manpower.

(I am aware of the forge PEPs that you mention below, but as far as I
know even those are stalled because of - guess what - lack of available
core developer time).

Working on Roundup, the CPython infrastructure or Kallithea may be less
frustrating for new contributors (I don't know), but what this boils
down to is that you're contributing to a different project, and not to
CPython. But if you've decided to work on something else, there is (at
least for me) little reason to restrict the choice to projects that are
used *for* CPython development. And compared to the whole range of other
open source projects, I suspect the above options just don't look all
that interesting to many people. In other words: you typically can't
tell volunteers what to work on - you've got to accept the contribution
in the area they're interested in, or you loose the contributor. In case
of CPython the latter may be unavoidable at the moment, but I think it's
illusory to think that this can be solved by "redirecting" the stream of
contributions. Suppose you just found a bug in Python and you want to
upstream the patch so you don't have to carry the workaround
forever. Now you see there are already a lot of open issues with patches
- are you going to forget about your patch and e.g. decide to work on
the buildbots insteads?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From ncoghlan at gmail.com  Wed Jul 22 06:31:41 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 22 Jul 2015 14:31:41 +1000
Subject: [Python-Dev] Devguide - Add Communications Quick Start Section
In-Reply-To: <CAP1=2W6o7fD5bjAR2i6n=tmPv3y-eA14CHuAumgQP+nbYNZ46Q@mail.gmail.com>
References: <55AE7C31.6070600@willingconsulting.com>
 <CAP1=2W6o7fD5bjAR2i6n=tmPv3y-eA14CHuAumgQP+nbYNZ46Q@mail.gmail.com>
Message-ID: <CADiSq7dkqFKwsMHyQr3yWXO7y4V6apzdQgu7sNXzvC+1LhwN1Q@mail.gmail.com>

On 22 July 2015 at 04:08, Brett Cannon <brett at python.org> wrote:
> On Tue, Jul 21, 2015 at 11:05 AM Carol Willing
> <willingc at willingconsulting.com> wrote:
>> The Communications Quick Start section would be brief and practical much
>> like the Quick Start section for downloading and testing the source
>> code. Placing the Communications Quick Start section before the existing
>> Quick Start section would emphasize the importance that productive
>> communications has on CPython development.
>
>
> Sounds great to me! Social norms are just as important to get to speed on as
> technical requirements when contributing to an open source community, so
> this seems like a worthy project.

+1 from me as well. The discussion of a more formal CoC on the
python-committers list also highlighted for me that our main current
problems don't appear to be with any ill-intent on anyone's part, but
rather with well-intentioned messages that nevertheless have the
effect of causing folks to feel unappreciated and resentful. A
practical quick start guide is likely to be more effective in
addressing that aspect than a more explicit CoC (although I still
think the latter would be a good idea in the long run).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Wed Jul 22 06:52:12 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 22 Jul 2015 14:52:12 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <87d1zkq3j0.fsf@vostro.rath.org>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <87d1zkq3j0.fsf@vostro.rath.org>
Message-ID: <CADiSq7e-b_KjxynrVMNPm6PS6=1HVD1JKg+9kOsphBnjRF+7Ag@mail.gmail.com>

On 22 July 2015 at 13:23, Nikolaus Rath <Nikolaus at rath.org> wrote:
> If it were up to me, I'd focus all the resources of the PSF on reducing
> this backlog - be that by hiring some core developers to work full-time
> on just the open bugtracker issues, or by financing development of
> better code review and commit infrastructure.

Ah, but the PSF can't do that without infringing on python-dev's
autonomy - switching to my PSF Director's hat, while we'd certainly be
prepared to help with funding a credible grant proposal for something
like the Twisted technical fellowship, we wouldn't *impose* help that
the core developers haven't asked for. That again bottlenecks on core
developer time, though - figuring out how to reasonably run such a
fellowship programme (especially the recruiting aspects) without
alienating volunteers is yet another "hard community management
problem".

>From the "strange but true" files, it's also the case that growing the
core developer community *isn't* actually the PSF's highest priority -
that honour goes to growing the Python *user* community, and the
reference interpreter itself is only one aspect of that (while
https://wiki.python.org/moin/PythonSoftwareFoundation/Proposals/StrategicPriorities
is only a draft, it still gives a good guide as to the extent of the
PSF's wider activities).

> The current situation
> looks like a downward spiral to me. New contributors are frustrated and
> leave because they feel their contribution is not welcome, and core
> developers get burned out by the gigantic backlog and the interaction
> with frustrated patch submitters - thus further reducing the available
> manpower.

We actually still have a lot of paid core developer (and potential
core developer) time locked up in facilitating the Python 2 -> 3
migration, as we didn't fully appreciate the extent to which Python
had been adopted in the Linux ecosystem and elsewhere until folks
started seeking help upgrading.

Knowing that doesn't help in the near term, of course, but it does
mean we know there's a relatively large pool of paid development time
currently being directed elsewhere that may be brought more directly
to bear upstream in the future.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From willingc at willingconsulting.com  Wed Jul 22 06:49:55 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Tue, 21 Jul 2015 21:49:55 -0700
Subject: [Python-Dev] Devguide - Add Communications Quick Start Section
In-Reply-To: <CADiSq7dkqFKwsMHyQr3yWXO7y4V6apzdQgu7sNXzvC+1LhwN1Q@mail.gmail.com>
References: <55AE7C31.6070600@willingconsulting.com>
 <CAP1=2W6o7fD5bjAR2i6n=tmPv3y-eA14CHuAumgQP+nbYNZ46Q@mail.gmail.com>
 <CADiSq7dkqFKwsMHyQr3yWXO7y4V6apzdQgu7sNXzvC+1LhwN1Q@mail.gmail.com>
Message-ID: <55AF20F3.8020708@willingconsulting.com>

On 7/21/15 9:31 PM, Nick Coghlan wrote:
> On 22 July 2015 at 04:08, Brett Cannon <brett at python.org> wrote:
>> On Tue, Jul 21, 2015 at 11:05 AM Carol Willing
>> <willingc at willingconsulting.com> wrote:
>>> The Communications Quick Start section would be brief and practical much
>>> like the Quick Start section for downloading and testing the source
>>> code. Placing the Communications Quick Start section before the existing
>>> Quick Start section would emphasize the importance that productive
>>> communications has on CPython development.
>>
>> Sounds great to me! Social norms are just as important to get to speed on as
>> technical requirements when contributing to an open source community, so
>> this seems like a worthy project.
> +1 from me as well. The discussion of a more formal CoC on the
> python-committers list also highlighted for me that our main current
> problems don't appear to be with any ill-intent on anyone's part, but
> rather with well-intentioned messages that nevertheless have the
> effect of causing folks to feel unappreciated and resentful. A
> practical quick start guide is likely to be more effective in
> addressing that aspect than a more explicit CoC (although I still
> think the latter would be a good idea in the long run).
>
> Regards,
> Nick.
>
I have created an issue<http://bugs.python.org/issue24682>
  on the Quick Start: Communications section. Please feel free to add further suggestions there.

Thanks for the support. Terry, I like your suggested wording :)


From tjreedy at udel.edu  Wed Jul 22 08:21:48 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 22 Jul 2015 02:21:48 -0400
Subject: [Python-Dev] Python 3.4.3 on RedHat 6.6 s390x make fails with:
 make: *** [sharedmods] Error 139
In-Reply-To: <707B1F493DFA6A4DA1EFBBED57369A6D0134F9840A@WTPCPMBMEM09.ams.bnymellon.net>
References: <707B1F493DFA6A4DA1EFBBED57369A6D0134F9840A@WTPCPMBMEM09.ams.bnymellon.net>
Message-ID: <moncqj$18t$1@ger.gmane.org>

On 7/21/2015 6:20 PM, Vitale, Joseph wrote:
> Hello,
>
> Trying to install Python 3.4.3  on Red Hat  6.6 zLinux(s390x)  but
> ?make? fails and core dumps.  Not using OpenSSL and did not configure
> for it.

Questions about installing current Python should be directed to 
python-list.  pydev is for developing future releases and versions of 
Python.

-- 
Terry Jan Reedy



From gmludo at gmail.com  Wed Jul 22 08:54:52 2015
From: gmludo at gmail.com (Ludovic Gasc)
Date: Wed, 22 Jul 2015 08:54:52 +0200
Subject: [Python-Dev] Python 3.4.3 on RedHat 6.6 s390x make fails with:
 make: *** [sharedmods] Error 139
In-Reply-To: <moncqj$18t$1@ger.gmane.org>
References: <707B1F493DFA6A4DA1EFBBED57369A6D0134F9840A@WTPCPMBMEM09.ams.bnymellon.net>
 <moncqj$18t$1@ger.gmane.org>
Message-ID: <CAON-fpErbkOkwVLwMDqA27SG-ChhBcLCLC6wV6zpMF6ZFe-08Q@mail.gmail.com>

Hi Jo,

Terry has right, however, if you launch this command before the
compilation, it should work:
https://github.com/saghul/pythonz/blob/master/README.rst#rpm-family-centos-rhel

In case of it doesn't work, please contact me privately to avoid to pollute
this mailing list.

Have a nice day.

Ludovic Gasc (GMLudo)
http://www.gmludo.eu/
On 22 Jul 2015 08:23, "Terry Reedy" <tjreedy at udel.edu> wrote:

> On 7/21/2015 6:20 PM, Vitale, Joseph wrote:
>
>> Hello,
>>
>> Trying to install Python 3.4.3  on Red Hat  6.6 zLinux(s390x)  but
>> ?make? fails and core dumps.  Not using OpenSSL and did not configure
>> for it.
>>
>
> Questions about installing current Python should be directed to
> python-list.  pydev is for developing future releases and versions of
> Python.
>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/gmludo%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150722/6594644c/attachment.html>

From ronaldoussoren at mac.com  Wed Jul 22 09:25:02 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 22 Jul 2015 09:25:02 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
Message-ID: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>

Hi,

Another summer with another EuroPython, which means its time again to try to revive PEP 447?

I?ve just pushes a minor update to the PEP and would like to get some feedback on this, arguably fairly esoteric, PEP.

The PEP proposes to to replace direct access to the class __dict__ in object.__getattribute__ and super.__getattribute__ by calls to a new special method to give the metaclass more control over attribute lookup, especially for access using a super() object.  This is needed for classes that cannot store (all) descriptors in the class dict for some reason, see the PEP text for a real-world example of that.

Regards,

  Ronald


The PEP text (with an outdated section with benchmarks removed):

PEP: 447
Title: Add __getdescriptor__ method to metaclass
Version: $Revision$
Last-Modified: $Date$
Author: Ronald Oussoren <ronaldoussoren at mac.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Jun-2013
Post-History: 2-Jul-2013, 15-Jul-2013, 29-Jul-2013, 22-Jul-2015


Abstract
========

Currently ``object.__getattribute__`` and ``super.__getattribute__`` peek
in the ``__dict__`` of classes on the MRO for a class when looking for
an attribute. This PEP adds an optional ``__getdescriptor__`` method to
a metaclass that replaces this behavior and gives more control over attribute
lookup, especially when using a `super`_ object.

That is, the MRO walking loop in ``_PyType_Lookup`` and
``super.__getattribute__`` gets changed from::

     def lookup(mro_list, name):
         for cls in mro_list:
             if name in cls.__dict__:
                 return cls.__dict__

         return NotFound

to::

     def lookup(mro_list, name):
         for cls in mro_list:
             try:
                 return cls.__getdescriptor__(name)
             except AttributeError:
                 pass

         return NotFound

The default implemention of ``__getdescriptor__`` looks in the class
dictionary::

   class type:
      def __getdescriptor__(cls, name):
          try:
	      return cls.__dict__[name]
	  except KeyError:
	      raise AttributeError(name) from None

Rationale
=========

It is currently not possible to influence how the `super class`_ looks
up attributes (that is, ``super.__getattribute__`` unconditionally
peeks in the class ``__dict__``), and that can be problematic for
dynamic classes that can grow new methods on demand.

The ``__getdescriptor__`` method makes it possible to dynamically add
attributes even when looking them up using the `super class`_.

The new method affects ``object.__getattribute__`` (and
`PyObject_GenericGetAttr`_) as well for consistency and to have a single
place to implement dynamic attribute resolution for classes.

Background
----------

The current behavior of ``super.__getattribute__`` causes problems for
classes that are dynamic proxies for other (non-Python) classes or types,
an example of which is `PyObjC`_. PyObjC creates a Python class for every
class in the Objective-C runtime, and looks up methods in the Objective-C
runtime when they are used. This works fine for normal access, but doesn't
work for access with `super`_ objects. Because of this PyObjC currently
includes a custom `super`_ that must be used with its classes, as well as
completely reimplementing `PyObject_GenericGetAttr`_ for normal attribute
access.

The API in this PEP makes it possible to remove the custom `super`_ and
simplifies the implementation because the custom lookup behavior can be
added in a central location.

.. note::

   `PyObjC`_ cannot precalculate the contents of the class ``__dict__``
   because Objective-C classes can grow new methods at runtime. Furthermore
   Objective-C classes tend to contain a lot of methods while most Python
   code will only use a small subset of them, this makes precalculating
   unnecessarily expensive.


The superclass attribute lookup hook
====================================

Both ``super.__getattribute__`` and ``object.__getattribute__`` (or
`PyObject_GenericGetAttr`_ and in particular ``_PyType_Lookup`` in C code)
walk an object's MRO and currently peek in the class' ``__dict__`` to look up
attributes.

With this proposal both lookup methods no longer peek in the class ``__dict__``
but call the special method ``__getdescriptor__``, which is a slot defined
on the metaclass. The default implementation of that method looks
up the name the class ``__dict__``, which means that attribute lookup is
unchanged unless a metatype actually defines the new special method.

Aside: Attribute resolution algorithm in Python
-----------------------------------------------

The attribute resolution proces as implemented by ``object.__getattribute__``
(or PyObject_GenericGetAttr`` in CPython's implementation) is fairly
straightforward, but not entirely so without reading C code.

The current CPython implementation of object.__getattribute__ is basicly
equivalent to the following (pseudo-) Python code (excluding some house keeping and speed tricks)::


    def _PyType_Lookup(tp, name):
        mro = tp.mro()
	assert isinstance(mro, tuple)

	for base in mro:
	   assert isinstance(base, type)

	   # PEP 447 will change these lines:
	   try:
	       return base.__dict__[name]
	   except KeyError:
	       pass

	return None


    class object:
        def __getattribute__(self, name):
	    assert isinstance(name, str)

	    tp = type(self)
	    descr = _PyType_Lookup(tp, name)

	    f = None
	    if descr is not None:
	        f = descr.__get__
		if f is not None and descr.__set__ is not None:
		    # Data descriptor
		    return f(descr, self, type(self))

            dict = self.__dict__
	    if dict is not None:
	        try:
		    return self.__dict__[name]
                except KeyError:
	            pass

            if f is not None:
	        # Non-data descriptor
	        return f(descr, self, type(self))

            if descr is not None:
	        # Regular class attribute
	        return descr

            raise AttributeError(name)


    class super:
        def __getattribute__(self, name):
	   assert isinstance(name, unicode)

	   if name != '__class__':
	       starttype = self.__self_type__
	       mro = startype.mro()

	       try:
	           idx = mro.index(self.__thisclass__)

	       except ValueError:
	           pass

	       else:
	           for base in mro[idx+1:]:
		       # PEP 447 will change these lines:
		       try:
		           descr = base.__dict__[name]
                       except KeyError:
		           continue

		       f = descr.__get__
		       if f is not None:
		           return f(descr,
			       None if (self.__self__ is self.__self_type__) else self.__self__,
			       starttype)

		       else:
		           return descr

	   return object.__getattribute__(self, name)


This PEP should change the dict lookup at the lines starting at "# PEP 447" with
a method call to perform the actual lookup, making is possible to affect that
lookup both for normal attribute access and access through the `super proxy`_.

Note that specific classes can already completely override the default
behaviour by implementing their own ``__getattribute__`` slot (with or without
calling the super class implementation).


In Python code
--------------

A meta type can define a method ``__getdescriptor__`` that is called during
attribute resolution by both ``super.__getattribute__``
and ``object.__getattribute``::

    class MetaType(type):
        def __getdescriptor__(cls, name):
            try:
                return cls.__dict__[name]
            except KeyError:
                raise AttributeError(name) from None

The ``__getdescriptor__`` method has as its arguments a class (which is an
instance of the meta type) and the name of the attribute that is looked up.
It should return the value of the attribute without invoking descriptors,
and should raise `AttributeError`_ when the name cannot be found.

The `type`_ class provides a default implementation for ``__getdescriptor__``,
that looks up the name in the class dictionary.

Example usage
.............

The code below implements a silly metaclass that redirects attribute lookup to
uppercase versions of names::

    class UpperCaseAccess (type):
        def __getdescriptor__(cls, name):
	    try:
                return cls.__dict__[name.upper()]
	    except KeyError:
	        raise AttributeError(name) from None

    class SillyObject (metaclass=UpperCaseAccess):
        def m(self):
            return 42

        def M(self):
            return "fourtytwo"

    obj = SillyObject()
    assert obj.m() == "fortytwo"

As mentioned earlier in this PEP a more realistic use case of this
functionallity is a ``__getdescriptor__`` method that dynamicly populates the
class ``__dict__`` based on attribute access, primarily when it is not
possible to reliably keep the class dict in sync with its source, for example
because the source used to populate ``__dict__`` is dynamic as well and does
not have triggers that can be used to detect changes to that source.

An example of that are the class bridges in PyObjC: the class bridge is a
Python object (class) that represents an Objective-C class and conceptually
has a Python method for every Objective-C method in the Objective-C class.
As with Python it is possible to add new methods to an Objective-C class, or
replace existing ones, and there are no callbacks that can be used to detect
this.

In C code
---------

A new slot ``tp_getdescriptor`` is added to the ``PyTypeObject`` struct, this
slot corresponds to the ``__getdescriptor__`` method on `type`_.

The slot has the following prototype::

    PyObject* (*getdescriptorfunc)(PyTypeObject* cls, PyObject* name);

This method should lookup *name* in the namespace of *cls*, without looking at
superclasses, and should not invoke descriptors. The method returns ``NULL``
without setting an exception when the *name* cannot be found, and returns a
new reference otherwise (not a borrowed reference).

Use of this hook by the interpreter
-----------------------------------

The new method is required for metatypes and as such is defined on `type_`.
Both ``super.__getattribute__`` and
``object.__getattribute__``/`PyObject_GenericGetAttr`_
(through ``_PyType_Lookup``) use the this ``__getdescriptor__`` method when
walking the MRO.

Other changes to the implementation
-----------------------------------

The change for `PyObject_GenericGetAttr`_ will be done by changing the private
function ``_PyType_Lookup``. This currently returns a borrowed reference, but
must return a new reference when the ``__getdescriptor__`` method is present.
Because of this ``_PyType_Lookup`` will be renamed to ``_PyType_LookupName``,
this will cause compile-time errors for all out-of-tree users of this
private API.

The attribute lookup cache in ``Objects/typeobject.c`` is disabled for classes
that have a metaclass that overrides ``__getdescriptor__``, because using the
cache might not be valid for such classes.

Impact of this PEP on introspection
-----------------------------------

Use of the method introduced in this PEP can affect introspection of classes
with a metaclass that uses a custom ``__getdescriptor__`` method. This section
lists those changes.

The items listed below are only affected by custom ``__getdescriptor__``
methods, the default implementation for ``object`` won't cause problems
because that still only uses the class ``__dict__`` and won't cause visible
changes to the visible behaviour of the ``object.__getattribute__``.

* ``dir`` might not show all attributes

  As with a custom ``__getattribute__`` method `dir()`_ might not see all
  (instance) attributes when using the ``__getdescriptor__()`` method to
  dynamicly resolve attributes.

  The solution for that is quite simple: classes using ``__getdescriptor__``
  should also implement `__dir__()`_ if they want full support for the builtin
  `dir()`_ function.

* ``inspect.getattr_static`` might not show all attributes

  The function ``inspect.getattr_static`` intentionally does not invoke
  ``__getattribute__`` and descriptors to avoid invoking user code during
  introspection with this function. The ``__getdescriptor__`` method will also
  be ignored and is another way in which the result of ``inspect.getattr_static``
  can be different from that of ``builtin.getattr``.

* ``inspect.getmembers`` and ``inspect.get_class_attrs``

  Both of these functions directly access the class __dict__ of classes along
  the MRO, and hence can be affected by a custom ``__getdescriptor__`` method.

  **TODO**: I haven't fully worked out what the impact of this is, and if there
  are mitigations for those using either updates to these functions, or
  additional methods that users should implement to be fully compatible with
  these functions.

  One possible mitigation is to have a custom ``__getattribute__`` for these
  classes that fills ``__dict__`` before returning and and defers to the
  default implementation for other attributes.

* Direct introspection of the class ``__dict__``

  Any code that directly access the class ``__dict__`` for introspection
  can be affected by a custom ``__getdescriptor__`` method.


Performance impact
------------------

**WARNING**: The benchmark results in this section are old, and will be updated
when I've ported the patch to the current trunk. I don't expect significant
changes to the results in this section.

[snipped]


Alternative proposals
---------------------

``__getattribute_super__``
..........................

An earlier version of this PEP used the following static method on classes::

    def __getattribute_super__(cls, name, object, owner): pass

This method performed name lookup as well as invoking descriptors and was
necessarily limited to working only with ``super.__getattribute__``.


Reuse ``tp_getattro``
.....................

It would be nice to avoid adding a new slot, thus keeping the API simpler and
easier to understand.  A comment on `Issue 18181`_ asked about reusing the
``tp_getattro`` slot, that is super could call the ``tp_getattro`` slot of all
methods along the MRO.

That won't work because ``tp_getattro`` will look in the instance
``__dict__`` before it tries to resolve attributes using classes in the MRO.
This would mean that using ``tp_getattro`` instead of peeking the class
dictionaries changes the semantics of the `super class`_.

Alternate placement of the new method
.....................................

This PEP proposes to add ``__getdescriptor__`` as a method on the metaclass.
An alternative would be to add it as a class method on the class itself
(simular to how ``__new__`` is a `staticmethod`_ of the class and not a method
of the metaclass).

The two are functionally equivalent, and there's something to be said about
not requiring the use of a meta class.


References
==========

* `Issue 18181`_ contains an out of date prototype implementation

Copyright
=========

This document has been placed in the public domain.

.. _`Issue 18181`: http://bugs.python.org/issue18181

.. _`super class`: http://docs.python.org/3/library/functions.html#super

.. _`super proxy`: http://docs.python.org/3/library/functions.html#super

.. _`super`: http://docs.python.org/3/library/functions.html#super

.. _`dir()`: http://docs.python.org/3/library/functions.html#dir

.. _`staticmethod`: http://docs.python.org/3/library/functions.html#staticmethod

.. _`__dir__()`: https://docs.python.org/3/reference/datamodel.html#object.__dir__

.. _`NotImplemented`: http://docs.python.org/3/library/constants.html#NotImplemented

.. _`PyObject_GenericGetAttr`: http://docs.python.org/3/c-api/object.html#PyObject_GenericGetAttr

.. _`type`: http://docs.python.org/3/library/functions.html#type

.. _`AttributeError`: http://docs.python.org/3/library/exceptions.html#AttributeError

.. _`PyObjC`: http://pyobjc.sourceforge.net/

.. _`classmethod`: http://docs.python.org/3/library/functions.html#classmethod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150722/88c6e90b/attachment-0001.html>

From dimaqq at gmail.com  Wed Jul 22 10:34:03 2015
From: dimaqq at gmail.com (Dima Tisnek)
Date: Wed, 22 Jul 2015 10:34:03 +0200
Subject: [Python-Dev] How far to go with user-friendliness
In-Reply-To: <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
References: <CAGGBzXJ=RCrJUpa=YUrhO=FggVp-hBafwxA7c9epjFiJq0PqQg@mail.gmail.com>
 <20150714134156.GB21874@ando.pearwood.info>
 <mo3cjo$1eg$1@ger.gmane.org>
 <CAC=pj-3-+h+y2GNwG1-Vw5zgydvMBgibsHy1nhR-JfHzOC8Chw@mail.gmail.com>
 <CAKCKLWxh6hqVso_RPwSEJ2UUhV5kjE_bPQ+cGXB26KF-eECKEQ@mail.gmail.com>
Message-ID: <CAGGBzXLngsEoH84C3pDMDS2ZNwkj68PWzbfAzawjoWKijQgrDA@mail.gmail.com>

Since I started this thread:

I like mock's magic
I appreciate plain language extra features (.called, .reset_mock(),
.side_effect, etc) [1]
I even appreciate assert* error magic [2]
assret* is just puzzling, unexpected.

[1]
those who want clear separation like `._assert_called_with()` are
going too far IMO.
Personally I'd rather use pytest style `assert m.call_count` than
`m.assert_called_with()` but that's just me

[2]
that caught another developer's bug in my codebase

On 16 July 2015 at 22:29, Michael Foord <fuzzyman at gmail.com> wrote:
>
>
> On Tuesday, 14 July 2015, Christie Wilson <bobcatfish at gmail.com> wrote:
>>> If people do misspell it, I think they do learn not to in after it
>>> happens a few times.
>>
>> Unless the line silently executes and they don't notice the mistake for
>> years :'(
>
> Indeed. This has been a problem with mock, misspelled (usually
> misremembered) assert methods silently did nothing.
>
> With this fix in place several failing tests were revealed in code bases!
>
> As for assret, it's the common misspelling people have told me about. It
> seems a ridiculous thing for people to get worked up about, but people enjoy
> getting worked up.
>
> Michael
>
>
>
>> On Tue, Jul 14, 2015 at 9:15 AM, Ron Adam <ron3200 at gmail.com> wrote:
>>>
>>>
>>> On 07/14/2015 09:41 AM, Steven D'Aprano wrote:
>>>>
>>>> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
>>>>>
>>>>> >https://bugs.python.org/issue21238  introduces detection of
>>>>> >missing/misspelt mock.assert_xxx() calls on getattr level in Python
>>>>> >3.5
>>>>> >
>>>>> >Michael and Kushal are of the opinion that "assret" is a common typo
>>>>> >of "assert" and should be supported in a sense that it also triggers
>>>>> >AttributeError and is not silently ignored like a mocked user
>>>>> >attribute.
>>>>> >
>>>>> >I disagree
>>>>
>>>> I must admit I don't use mock so don't quite understand what is going on
>>>> in this bug report. But I don't imagine that anything good will come out
>>>> of treating*one*  typo differently from all the other possible typos.
>>>> Why should "assret" be treated differently from other easy-to-make typos
>>>> like "asert", "assrt", "asset"? Or "assort", which is not only a
>>>> standard and common English word, but "e" and "o" are right next to each
>>>> other on Dvorak keyboards, making it an easy typo to make.
>>>>
>>>> Surely this is an obvious case where the Zen should apply. "Special
>>>> cases aren't special enough..." -- either all such typos raise
>>>> AttributeError, or they are all silent.
>>>
>>> I agree with Steven that it doesn't seem correct to not raise
>>> AttributeError here.
>>>
>>> For what it's worth, I have a life long sleep disorder and am a tarrable
>>> (<-- like this)  speller because of it.   I still don't want spell, or
>>> grammar, checkers to not report my mistakes.  And I don't recall ever making
>>> the particular error of using "assret" in place of "assert".  I'd be more
>>> likely to mispell it as "assirt" if I wasn't already so familiar with
>>> "assert".
>>>
>>> If people do misspell it, I think they do learn not to in after it
>>> happens a few times.
>>>
>>> Regards,
>>>    Ron
>>>
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com
>>
>>
>>
>> --
>> Christie Wilson
>
> --
>
> http://www.voidspace.org.uk/
>
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing http://www.sqlite.org/different.html
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/dimaqq%40gmail.com
>

From me at the-compiler.org  Wed Jul 22 11:25:27 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 22 Jul 2015 11:25:27 +0200
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <87d1zkq3j0.fsf@vostro.rath.org>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <87d1zkq3j0.fsf@vostro.rath.org>
Message-ID: <20150722092527.GX18503@tonks>

* Nikolaus Rath <Nikolaus at rath.org> [2015-07-21 20:23:15 -0700]:
> On Jul 21 2015, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > All of this is why the chart that I believe should be worrying people
> > is the topmost one on this page:
> > http://bugs.python.org/issue?@template=stats
> >
> > Both the number of open issues and the number of open issues with
> > patches are steadily trending upwards. That means the bottleneck in
> > the current process *isn't* getting patches written in the first
> > place, it's getting them up to the appropriate standards and applied.
> > Yet the answer to the problem isn't a simple "recruit more core
> > developers", as the existing core developers are *also* the bottleneck
> > in the review and mentoring process for *new* core developers.
> 
> As a random datapoint:
> 
> Early last year I wanted get involved in CPython development. In the
> next months I submitted and reviewed maybe 20 - 25 patches in the bug
> tracker. After seeing all of them languish, I stopped submitting and
> reviewing and just tried to get someone to look at the issues that I'd
> worked on. Eventually, I managed to get almost all of them committed
> (the last one sometime this February, after more than a year). However,
> it was such an uphill battle just to get someone to look at my
> contributions that I haven't touched the bugtracker ever since.
> 
> [...]

As another random datapoint: I have some (minor) things which I'd like
to contribute to Python - and I never did.

Seeing the number of open issues with patches just make me feel like
it'd be a waste of time to contribute. It seems very plausible the
patches will just be ignored without me putting effort in getting them
noticed.

I'm fine with revising things until people are happy, i.e. I don't
just want to post a patch and disappear - but I don't want to fight to
get any kind of response, and it looks to me like I'd have to. :-/

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150722/17c4c10f/attachment.sig>

From p.f.moore at gmail.com  Wed Jul 22 13:09:34 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 22 Jul 2015 12:09:34 +0100
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <87pp3ldjel.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <87pp3ldjel.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CACac1F93wdhfVQrDtAkVVFxSC4S=0oRdRqNMt8kp3-+14u0FGA@mail.gmail.com>

On 22 July 2015 at 03:18, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> The only *practical* suggestion from "the core" has been self-
> restraint on the part of "the crowd"

I would have said the following has been covered, but maybe not. At
the risk of repeating something that's already been said, here are
some guidelines for people asking for comments on a commit.

1. Post *once*. Don't post again until there is some feedback from the
core dev addressed - the reason threads become self-sustaining is that
people respond to each other without any new input from the "other
side" (i.e. the core dev who made the commit/decision).

2. Do your research - read the issue tracker comments before posting.
Look at dates, times, and history. The commit that triggered this
thread was made over a year ago - we're discussing ancient history
here - and the original issue was raised by the lead developer on
mock. There's not a lot of explanation in there, so *maybe* asking for
more detail is acceptable, but what's wrong with a comment on the
issue along the lines of "I know this is history, but are there links
to any discussion on including the assret mis-spelling that I could
read up on?")

3. Prefer comments on the tracker over mailing list discussions.
Consider hard why you feel it's necessary to take the discussion to a
forum with a wider readership. Honestly assess whether or not you're
simply hoping to muster numbers in support of your view. If your
arguments are no better than "look, lots of people agree with me",
then leave it to someone with more compelling arguments (if there are
any) to speak up.

4. Seriously consider, if you don't use the functionality in question,
why do you feel entitled to an opinion? Bystanders' views are not
disallowed, but you should start from the assumption that the opinions
of people directly affected by the change have *far* more weight than
yours.

5. Assume that the decision was well-considered and made with good
reasons. If you don't understand the reasons, and feel you need to,
ask for them, but refrain from judgement until you have the reasons.
The original mail in this thread ("is this a joke?" is a particularly
bad violation of this rule - does anyone seriously think a core dev
commits code as a joke???).

Yes, these constitute a very high bar for commenters. So what? The
bars being set by commenters on core developers are also very high.

Paul

From p.f.moore at gmail.com  Wed Jul 22 13:12:32 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 22 Jul 2015 12:12:32 +0100
Subject: [Python-Dev] Devguide - Add Communications Quick Start Section
In-Reply-To: <55AE7C31.6070600@willingconsulting.com>
References: <55AE7C31.6070600@willingconsulting.com>
Message-ID: <CACac1F86-r9q2Lq_Ys6RBrJEa8Sfw4+0M_aYt2deE+x6ZzZi9w@mail.gmail.com>

On 21 July 2015 at 18:06, Carol Willing <willingc at willingconsulting.com> wrote:
> The Communications Quick Start section would be brief and practical much
> like the Quick Start section for downloading and testing the source code.
> Placing the Communications Quick Start section before the existing Quick
> Start section would emphasize the importance that productive communications
> has on CPython development.

Sounds good. +1 from me.

Paul

From p.f.moore at gmail.com  Wed Jul 22 13:19:36 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 22 Jul 2015 12:19:36 +0100
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <CACac1F93wdhfVQrDtAkVVFxSC4S=0oRdRqNMt8kp3-+14u0FGA@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <87pp3ldjel.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F93wdhfVQrDtAkVVFxSC4S=0oRdRqNMt8kp3-+14u0FGA@mail.gmail.com>
Message-ID: <CACac1F8jjk1v3KrPMRiaA+g9aRy7L1aov_V4akOEq8ngranfEQ@mail.gmail.com>

On 22 July 2015 at 12:09, Paul Moore <p.f.moore at gmail.com> wrote:
> 5. Assume that the decision was well-considered and made with good
> reasons. If you don't understand the reasons, and feel you need to,
> ask for them, but refrain from judgement until you have the reasons.
> The original mail in this thread ("is this a joke?" is a particularly
> bad violation of this rule - does anyone seriously think a core dev
> commits code as a joke???).

My apologies - the original thread was *not* the source of the "is
this a joke?" comment. That appeared somewhere else, and I can't
recall exactly where. The original post was well-explained and a
sensible question, which pretty much followed all of the rules I
covered above (although it was still about something a year old, which
might have been nice to note in the post). My apologies to Dima for
misrepresenting what he said.

Just goes to show, that even when going on about "do your research", I
failed to do so myself :-( I suppose that emphasises the point that we
all make mistakes, so let's try to remember that when discussing rules
of conduct...

Paul

From Nikolaus at rath.org  Wed Jul 22 17:34:44 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Wed, 22 Jul 2015 08:34:44 -0700
Subject: [Python-Dev] How do we tell if we're helping or hindering the
	core development process?
In-Reply-To: <CADiSq7e-b_KjxynrVMNPm6PS6=1HVD1JKg+9kOsphBnjRF+7Ag@mail.gmail.com>
 (Nick Coghlan's message of "Wed, 22 Jul 2015 14:52:12 +1000")
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <87d1zkq3j0.fsf@vostro.rath.org>
 <CADiSq7e-b_KjxynrVMNPm6PS6=1HVD1JKg+9kOsphBnjRF+7Ag@mail.gmail.com>
Message-ID: <87r3o0cijv.fsf@thinkpad.rath.org>

On Jul 22 2015, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 22 July 2015 at 13:23, Nikolaus Rath <Nikolaus at rath.org> wrote:
>> If it were up to me, I'd focus all the resources of the PSF on reducing
>> this backlog - be that by hiring some core developers to work full-time
>> on just the open bugtracker issues, or by financing development of
>> better code review and commit infrastructure.
>
> Ah, but the PSF can't do that without infringing on python-dev's
> autonomy - switching to my PSF Director's hat, while we'd certainly be
> prepared to help with funding a credible grant proposal for something
> like the Twisted technical fellowship, we wouldn't *impose* help that
> the core developers haven't asked for.

I don't understand. If I would hire a core developer myself to work on
this (theoretically, I have no plans to do that), would that also be
infringing python-dev's authority? If so, how is that different from me
doing the work? If not, why is it different if the PSF decides to hire
someone?

>> The current situation looks like a downward spiral to me. New
>> contributors are frustrated and leave because they feel their
>> contribution is not welcome, and core developers get burned out by
>> the gigantic backlog and the interaction with frustrated patch
>> submitters - thus further reducing the available manpower.
>
> We actually still have a lot of paid core developer (and potential
> core developer) time locked up in facilitating the Python 2 -> 3
> migration, as we didn't fully appreciate the extent to which Python
> had been adopted in the Linux ecosystem and elsewhere until folks
> started seeking help upgrading.

Interesting. Is this information available publically somewhere? I'm
curious what exactly is being worked on.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From tjreedy at udel.edu  Wed Jul 22 18:02:39 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 22 Jul 2015 12:02:39 -0400
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
Message-ID: <mooero$hds$1@ger.gmane.org>

On 7/22/2015 3:25 AM, Ronald Oussoren wrote:
> Hi,
>
> Another summer with another EuroPython, which means its time again to
> try to revive PEP 447?
>
> I?ve just pushes a minor update to the PEP and would like to get some
> feedback on this, arguably fairly esoteric, PEP.

Yeh, a bit too esoteric for most of us to review.  For instance, it is 
not obvious to me, not familiar with internal details, after reading the 
intro, why a custom __getattribute__ is not enough and why 
__getdescriptor__ would be needed. If Guido does not want to review 
this, you need to find a PEP BDFL for this.

There are two fairly obvious non-esoteric questions:

1. How does this impact speed (updated section needed)?

2. Is this useful, that you can think of, for anything other than 
connecting to Objective C?

-- 
Terry Jan Reedy



From Steve.Dower at microsoft.com  Wed Jul 22 19:12:44 2015
From: Steve.Dower at microsoft.com (Steve Dower)
Date: Wed, 22 Jul 2015 17:12:44 +0000
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <mooero$hds$1@ger.gmane.org>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
Message-ID: <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>

Terry Reedy wrote:
> On 7/22/2015 3:25 AM, Ronald Oussoren wrote:
>> Hi,
>>
>> Another summer with another EuroPython, which means its time again to
>> try to revive PEP 447?
>>
>> I?ve just pushes a minor update to the PEP and would like to get some
>> feedback on this, arguably fairly esoteric, PEP.
> 
> Yeh, a bit too esoteric for most of us to review. For instance, it is not
> obvious to me, not familiar with internal details, after reading the intro, why
> a custom __getattribute__ is not enough and why __getdescriptor__ would be
> needed. If Guido does not want to review this, you need to find a PEP BDFL for
> this.
> 
> There are two fairly obvious non-esoteric questions:
> 
> 1. How does this impact speed (updated section needed)?

Agreed, this is important. But hopefully it's just a C indirection (or better yet, a null check) for objects that don't override __getdescriptor__.

> 2. Is this useful, that you can think of, for anything other than connecting to
> Objective C?

There are other object models that would benefit from this, but I don't recall that we came up with uses other than "helps proxy to objects where listing all members eagerly is expensive and/or potentially incorrect". Maybe once you list all the operating systems that are now using dynamic object-oriented APIs rather than flat APIs (Windows, iOS, Android, ... others?) this is good enough?

FWIW, I'm still +1 on this, pending performance testing.

Cheers,
Steve

> --
> Terry Jan Reedy


From ronaldoussoren at mac.com  Wed Jul 22 19:21:06 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 22 Jul 2015 19:21:06 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <mooero$hds$1@ger.gmane.org>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
Message-ID: <9796C183-C2EE-4415-8E5C-653E22E5304F@mac.com>


> On 22 Jul 2015, at 18:02, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> On 7/22/2015 3:25 AM, Ronald Oussoren wrote:
>> Hi,
>> 
>> Another summer with another EuroPython, which means its time again to
>> try to revive PEP 447?
>> 
>> I?ve just pushes a minor update to the PEP and would like to get some
>> feedback on this, arguably fairly esoteric, PEP.
> 
> Yeh, a bit too esoteric for most of us to review.  

I noticed that in my previous attempts as well. There is only a limited number of people the really grok how Python?s attribute lookup works, and a smaller subset of those understand how that?s implemented in CPython.

> For instance, it is not obvious to me, not familiar with internal details, after reading the intro, why a custom __getattribute__ is not enough and why __getdescriptor__ would be needed.

That means the PEP text needs some more work. Using __getattribute__ works for normal attribute access, but not when you look for a superclass implementation using super() because super currently *only* looks in the __dict__ of classes further along the MRO and offers no way to influence the search. That?s a problem when classes can grow methods dynamically.

> If Guido does not want to review this, you need to find a PEP BDFL for this.

I?ll see if I can corner him at EP :-).  Its surprisingly hard to find people at conferences.

> 
> There are two fairly obvious non-esoteric questions:
> 
> 1. How does this impact speed (updated section needed)?

The speed impact should be minimal, the initial version of the patch (which needs some updating which I?ll try to do during the EP sprints) uses shortcuts to avoid actually calling the __getdescriptor__ method in the usual case.

> 
> 2. Is this useful, that you can think of, for anything other than connecting to Objective C?

Not immediately.  But then again, I initially thought that decorators would have limited appeal as well :-).  I guess this could be useful for other proxy-like objects as well, especially when preloading the __dict__ is relatively expensive.

Apart from direct usefulness this closes a hole in the way you can influence attribute lookup.

Ronald


> 
> -- 
> Terry Jan Reedy
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com


From ronaldoussoren at mac.com  Wed Jul 22 19:24:27 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 22 Jul 2015 19:24:27 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
 <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
Message-ID: <13A2C97A-958E-40FC-B647-E6268750300B@mac.com>


> On 22 Jul 2015, at 19:12, Steve Dower <Steve.Dower at microsoft.com> wrote:
> 
> Terry Reedy wrote:
>> On 7/22/2015 3:25 AM, Ronald Oussoren wrote:
>>> Hi,
>>> 
>>> Another summer with another EuroPython, which means its time again to
>>> try to revive PEP 447?
>>> 
>>> I?ve just pushes a minor update to the PEP and would like to get some
>>> feedback on this, arguably fairly esoteric, PEP.
>> 
>> Yeh, a bit too esoteric for most of us to review. For instance, it is not
>> obvious to me, not familiar with internal details, after reading the intro, why
>> a custom __getattribute__ is not enough and why __getdescriptor__ would be
>> needed. If Guido does not want to review this, you need to find a PEP BDFL for
>> this.
>> 
>> There are two fairly obvious non-esoteric questions:
>> 
>> 1. How does this impact speed (updated section needed)?
> 
> Agreed, this is important. But hopefully it's just a C indirection (or better yet, a null check) for objects that don't override __getdescriptor__.

Not a null check, but a check for a specific function pointer. That way you can be sure that super classes always have the slot which IMHO gives a nicer user experience.

> 
>> 2. Is this useful, that you can think of, for anything other than connecting to
>> Objective C?
> 
> There are other object models that would benefit from this, but I don't recall that we came up with uses other than "helps proxy to objects where listing all members eagerly is expensive and/or potentially incorrect". Maybe once you list all the operating systems that are now using dynamic object-oriented APIs rather than flat APIs (Windows, iOS, Android, ... others?) this is good enough?
> 
> FWIW, I'm still +1 on this, pending performance testing.

The PEP on the website contains performance test data, but that?s out of data. I don?t think the implementation of attribute lookup has changed enough to really invalidate those test results, but I will rerun the tests once I?ve updated the patch because hunches don?t count when evaluating performance.

Ronald

> 
> Cheers,
> Steve
> 
>> --
>> Terry Jan Reedy
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org <mailto:Python-Dev at python.org>
> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com <https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150722/179a8eed/attachment-0001.html>

From ben+python at benfinney.id.au  Thu Jul 23 01:06:56 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Thu, 23 Jul 2015 09:06:56 +1000
Subject: [Python-Dev] Devguide - Add Communications Quick Start Section
References: <55AE7C31.6070600@willingconsulting.com>
Message-ID: <85bnf3okq7.fsf@benfinney.id.au>

Carol Willing <willingc at willingconsulting.com> writes:

> The Communications Quick Start section would be brief and practical
> much like the Quick Start section for downloading and testing the
> source code.

+1, thanks for the practical contribution!

-- 
 \       ?Anyone who puts a small gloss on [a] fundamental technology, |
  `\          calls it proprietary, and then tries to keep others from |
_o__)           building on it, is a thief.? ?Tim O'Reilly, 2000-01-25 |
Ben Finney


From alexander.belopolsky at gmail.com  Thu Jul 23 04:01:11 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 22 Jul 2015 22:01:11 -0400
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <CACac1F93wdhfVQrDtAkVVFxSC4S=0oRdRqNMt8kp3-+14u0FGA@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <87pp3ldjel.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F93wdhfVQrDtAkVVFxSC4S=0oRdRqNMt8kp3-+14u0FGA@mail.gmail.com>
Message-ID: <CAP7h-xYnAdhcE_bAWhFS6x2hoAAGa77UgtJ7Opt5-ZNBUSCX6g@mail.gmail.com>

On Wed, Jul 22, 2015 at 7:09 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> does anyone seriously think a core dev
> commits code as a joke???
>

Yes, <https://hg.python.org/cpython/rev/0530aadff696>. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150722/52de6312/attachment.html>

From dimaqq at gmail.com  Thu Jul 23 11:29:03 2015
From: dimaqq at gmail.com (Dima Tisnek)
Date: Thu, 23 Jul 2015 11:29:03 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
Message-ID: <CAGGBzXKKEfj_ZBTTP1aTmF0U8_yWgQPxzXODkz_2tMSup1UHLg@mail.gmail.com>

Hey I've taken time to read the PEP, my 2c... actually 1c:

Most important is to explain how this changes behaviour of Python programs.

A comprehensive set of Python examples where behaviour is changed (for
better or worse) please.

While I understand the concern of "superclasses of objects that gain
or lose attributes at runtime" on the theoretical level, please
translate that into actual Python examples.

d.

On 22 July 2015 at 09:25, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> Hi,
>
> Another summer with another EuroPython, which means its time again to try to
> revive PEP 447?
>
> I?ve just pushes a minor update to the PEP and would like to get some
> feedback on this, arguably fairly esoteric, PEP.
>
> The PEP proposes to to replace direct access to the class __dict__ in
> object.__getattribute__ and super.__getattribute__ by calls to a new special
> method to give the metaclass more control over attribute lookup, especially
> for access using a super() object.  This is needed for classes that cannot
> store (all) descriptors in the class dict for some reason, see the PEP text
> for a real-world example of that.
>
> Regards,
>
>   Ronald
>
>
> The PEP text (with an outdated section with benchmarks removed):
>
> PEP: 447
> Title: Add __getdescriptor__ method to metaclass
> Version: $Revision$
> Last-Modified: $Date$
> Author: Ronald Oussoren <ronaldoussoren at mac.com>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 12-Jun-2013
> Post-History: 2-Jul-2013, 15-Jul-2013, 29-Jul-2013, 22-Jul-2015
>
>
> Abstract
> ========
>
> Currently ``object.__getattribute__`` and ``super.__getattribute__`` peek
> in the ``__dict__`` of classes on the MRO for a class when looking for
> an attribute. This PEP adds an optional ``__getdescriptor__`` method to
> a metaclass that replaces this behavior and gives more control over
> attribute
> lookup, especially when using a `super`_ object.
>
> That is, the MRO walking loop in ``_PyType_Lookup`` and
> ``super.__getattribute__`` gets changed from::
>
>      def lookup(mro_list, name):
>          for cls in mro_list:
>              if name in cls.__dict__:
>                  return cls.__dict__
>
>          return NotFound
>
> to::
>
>      def lookup(mro_list, name):
>          for cls in mro_list:
>              try:
>                  return cls.__getdescriptor__(name)
>              except AttributeError:
>                  pass
>
>          return NotFound
>
> The default implemention of ``__getdescriptor__`` looks in the class
> dictionary::
>
>    class type:
>       def __getdescriptor__(cls, name):
>           try:
>       return cls.__dict__[name]
>   except KeyError:
>       raise AttributeError(name) from None
>
> Rationale
> =========
>
> It is currently not possible to influence how the `super class`_ looks
> up attributes (that is, ``super.__getattribute__`` unconditionally
> peeks in the class ``__dict__``), and that can be problematic for
> dynamic classes that can grow new methods on demand.
>
> The ``__getdescriptor__`` method makes it possible to dynamically add
> attributes even when looking them up using the `super class`_.
>
> The new method affects ``object.__getattribute__`` (and
> `PyObject_GenericGetAttr`_) as well for consistency and to have a single
> place to implement dynamic attribute resolution for classes.
>
> Background
> ----------
>
> The current behavior of ``super.__getattribute__`` causes problems for
> classes that are dynamic proxies for other (non-Python) classes or types,
> an example of which is `PyObjC`_. PyObjC creates a Python class for every
> class in the Objective-C runtime, and looks up methods in the Objective-C
> runtime when they are used. This works fine for normal access, but doesn't
> work for access with `super`_ objects. Because of this PyObjC currently
> includes a custom `super`_ that must be used with its classes, as well as
> completely reimplementing `PyObject_GenericGetAttr`_ for normal attribute
> access.
>
> The API in this PEP makes it possible to remove the custom `super`_ and
> simplifies the implementation because the custom lookup behavior can be
> added in a central location.
>
> .. note::
>
>    `PyObjC`_ cannot precalculate the contents of the class ``__dict__``
>    because Objective-C classes can grow new methods at runtime. Furthermore
>    Objective-C classes tend to contain a lot of methods while most Python
>    code will only use a small subset of them, this makes precalculating
>    unnecessarily expensive.
>
>
> The superclass attribute lookup hook
> ====================================
>
> Both ``super.__getattribute__`` and ``object.__getattribute__`` (or
> `PyObject_GenericGetAttr`_ and in particular ``_PyType_Lookup`` in C code)
> walk an object's MRO and currently peek in the class' ``__dict__`` to look
> up
> attributes.
>
> With this proposal both lookup methods no longer peek in the class
> ``__dict__``
> but call the special method ``__getdescriptor__``, which is a slot defined
> on the metaclass. The default implementation of that method looks
> up the name the class ``__dict__``, which means that attribute lookup is
> unchanged unless a metatype actually defines the new special method.
>
> Aside: Attribute resolution algorithm in Python
> -----------------------------------------------
>
> The attribute resolution proces as implemented by
> ``object.__getattribute__``
> (or PyObject_GenericGetAttr`` in CPython's implementation) is fairly
> straightforward, but not entirely so without reading C code.
>
> The current CPython implementation of object.__getattribute__ is basicly
> equivalent to the following (pseudo-) Python code (excluding some house
> keeping and speed tricks)::
>
>
>     def _PyType_Lookup(tp, name):
>         mro = tp.mro()
> assert isinstance(mro, tuple)
>
> for base in mro:
>   assert isinstance(base, type)
>
>   # PEP 447 will change these lines:
>   try:
>       return base.__dict__[name]
>   except KeyError:
>       pass
>
> return None
>
>
>     class object:
>         def __getattribute__(self, name):
>     assert isinstance(name, str)
>
>     tp = type(self)
>     descr = _PyType_Lookup(tp, name)
>
>     f = None
>     if descr is not None:
>         f = descr.__get__
> if f is not None and descr.__set__ is not None:
>     # Data descriptor
>     return f(descr, self, type(self))
>
>             dict = self.__dict__
>     if dict is not None:
>         try:
>     return self.__dict__[name]
>                 except KeyError:
>             pass
>
>             if f is not None:
>         # Non-data descriptor
>         return f(descr, self, type(self))
>
>             if descr is not None:
>         # Regular class attribute
>         return descr
>
>             raise AttributeError(name)
>
>
>     class super:
>         def __getattribute__(self, name):
>   assert isinstance(name, unicode)
>
>   if name != '__class__':
>       starttype = self.__self_type__
>       mro = startype.mro()
>
>       try:
>           idx = mro.index(self.__thisclass__)
>
>       except ValueError:
>           pass
>
>       else:
>           for base in mro[idx+1:]:
>       # PEP 447 will change these lines:
>       try:
>           descr = base.__dict__[name]
>                        except KeyError:
>           continue
>
>       f = descr.__get__
>       if f is not None:
>           return f(descr,
>       None if (self.__self__ is self.__self_type__) else self.__self__,
>       starttype)
>
>       else:
>           return descr
>
>   return object.__getattribute__(self, name)
>
>
> This PEP should change the dict lookup at the lines starting at "# PEP 447"
> with
> a method call to perform the actual lookup, making is possible to affect
> that
> lookup both for normal attribute access and access through the `super
> proxy`_.
>
> Note that specific classes can already completely override the default
> behaviour by implementing their own ``__getattribute__`` slot (with or
> without
> calling the super class implementation).
>
>
> In Python code
> --------------
>
> A meta type can define a method ``__getdescriptor__`` that is called during
> attribute resolution by both ``super.__getattribute__``
> and ``object.__getattribute``::
>
>     class MetaType(type):
>         def __getdescriptor__(cls, name):
>             try:
>                 return cls.__dict__[name]
>             except KeyError:
>                 raise AttributeError(name) from None
>
> The ``__getdescriptor__`` method has as its arguments a class (which is an
> instance of the meta type) and the name of the attribute that is looked up.
> It should return the value of the attribute without invoking descriptors,
> and should raise `AttributeError`_ when the name cannot be found.
>
> The `type`_ class provides a default implementation for
> ``__getdescriptor__``,
> that looks up the name in the class dictionary.
>
> Example usage
> .............
>
> The code below implements a silly metaclass that redirects attribute lookup
> to
> uppercase versions of names::
>
>     class UpperCaseAccess (type):
>         def __getdescriptor__(cls, name):
>     try:
>                 return cls.__dict__[name.upper()]
>     except KeyError:
>         raise AttributeError(name) from None
>
>     class SillyObject (metaclass=UpperCaseAccess):
>         def m(self):
>             return 42
>
>         def M(self):
>             return "fourtytwo"
>
>     obj = SillyObject()
>     assert obj.m() == "fortytwo"
>
> As mentioned earlier in this PEP a more realistic use case of this
> functionallity is a ``__getdescriptor__`` method that dynamicly populates
> the
> class ``__dict__`` based on attribute access, primarily when it is not
> possible to reliably keep the class dict in sync with its source, for
> example
> because the source used to populate ``__dict__`` is dynamic as well and does
> not have triggers that can be used to detect changes to that source.
>
> An example of that are the class bridges in PyObjC: the class bridge is a
> Python object (class) that represents an Objective-C class and conceptually
> has a Python method for every Objective-C method in the Objective-C class.
> As with Python it is possible to add new methods to an Objective-C class, or
> replace existing ones, and there are no callbacks that can be used to detect
> this.
>
> In C code
> ---------
>
> A new slot ``tp_getdescriptor`` is added to the ``PyTypeObject`` struct,
> this
> slot corresponds to the ``__getdescriptor__`` method on `type`_.
>
> The slot has the following prototype::
>
>     PyObject* (*getdescriptorfunc)(PyTypeObject* cls, PyObject* name);
>
> This method should lookup *name* in the namespace of *cls*, without looking
> at
> superclasses, and should not invoke descriptors. The method returns ``NULL``
> without setting an exception when the *name* cannot be found, and returns a
> new reference otherwise (not a borrowed reference).
>
> Use of this hook by the interpreter
> -----------------------------------
>
> The new method is required for metatypes and as such is defined on `type_`.
> Both ``super.__getattribute__`` and
> ``object.__getattribute__``/`PyObject_GenericGetAttr`_
> (through ``_PyType_Lookup``) use the this ``__getdescriptor__`` method when
> walking the MRO.
>
> Other changes to the implementation
> -----------------------------------
>
> The change for `PyObject_GenericGetAttr`_ will be done by changing the
> private
> function ``_PyType_Lookup``. This currently returns a borrowed reference,
> but
> must return a new reference when the ``__getdescriptor__`` method is
> present.
> Because of this ``_PyType_Lookup`` will be renamed to
> ``_PyType_LookupName``,
> this will cause compile-time errors for all out-of-tree users of this
> private API.
>
> The attribute lookup cache in ``Objects/typeobject.c`` is disabled for
> classes
> that have a metaclass that overrides ``__getdescriptor__``, because using
> the
> cache might not be valid for such classes.
>
> Impact of this PEP on introspection
> -----------------------------------
>
> Use of the method introduced in this PEP can affect introspection of classes
> with a metaclass that uses a custom ``__getdescriptor__`` method. This
> section
> lists those changes.
>
> The items listed below are only affected by custom ``__getdescriptor__``
> methods, the default implementation for ``object`` won't cause problems
> because that still only uses the class ``__dict__`` and won't cause visible
> changes to the visible behaviour of the ``object.__getattribute__``.
>
> * ``dir`` might not show all attributes
>
>   As with a custom ``__getattribute__`` method `dir()`_ might not see all
>   (instance) attributes when using the ``__getdescriptor__()`` method to
>   dynamicly resolve attributes.
>
>   The solution for that is quite simple: classes using ``__getdescriptor__``
>   should also implement `__dir__()`_ if they want full support for the
> builtin
>   `dir()`_ function.
>
> * ``inspect.getattr_static`` might not show all attributes
>
>   The function ``inspect.getattr_static`` intentionally does not invoke
>   ``__getattribute__`` and descriptors to avoid invoking user code during
>   introspection with this function. The ``__getdescriptor__`` method will
> also
>   be ignored and is another way in which the result of
> ``inspect.getattr_static``
>   can be different from that of ``builtin.getattr``.
>
> * ``inspect.getmembers`` and ``inspect.get_class_attrs``
>
>   Both of these functions directly access the class __dict__ of classes
> along
>   the MRO, and hence can be affected by a custom ``__getdescriptor__``
> method.
>
>   **TODO**: I haven't fully worked out what the impact of this is, and if
> there
>   are mitigations for those using either updates to these functions, or
>   additional methods that users should implement to be fully compatible with
>   these functions.
>
>   One possible mitigation is to have a custom ``__getattribute__`` for these
>   classes that fills ``__dict__`` before returning and and defers to the
>   default implementation for other attributes.
>
> * Direct introspection of the class ``__dict__``
>
>   Any code that directly access the class ``__dict__`` for introspection
>   can be affected by a custom ``__getdescriptor__`` method.
>
>
> Performance impact
> ------------------
>
> **WARNING**: The benchmark results in this section are old, and will be
> updated
> when I've ported the patch to the current trunk. I don't expect significant
> changes to the results in this section.
>
> [snipped]
>
>
> Alternative proposals
> ---------------------
>
> ``__getattribute_super__``
> ..........................
>
> An earlier version of this PEP used the following static method on classes::
>
>     def __getattribute_super__(cls, name, object, owner): pass
>
> This method performed name lookup as well as invoking descriptors and was
> necessarily limited to working only with ``super.__getattribute__``.
>
>
> Reuse ``tp_getattro``
> .....................
>
> It would be nice to avoid adding a new slot, thus keeping the API simpler
> and
> easier to understand.  A comment on `Issue 18181`_ asked about reusing the
> ``tp_getattro`` slot, that is super could call the ``tp_getattro`` slot of
> all
> methods along the MRO.
>
> That won't work because ``tp_getattro`` will look in the instance
> ``__dict__`` before it tries to resolve attributes using classes in the MRO.
> This would mean that using ``tp_getattro`` instead of peeking the class
> dictionaries changes the semantics of the `super class`_.
>
> Alternate placement of the new method
> .....................................
>
> This PEP proposes to add ``__getdescriptor__`` as a method on the metaclass.
> An alternative would be to add it as a class method on the class itself
> (simular to how ``__new__`` is a `staticmethod`_ of the class and not a
> method
> of the metaclass).
>
> The two are functionally equivalent, and there's something to be said about
> not requiring the use of a meta class.
>
>
> References
> ==========
>
> * `Issue 18181`_ contains an out of date prototype implementation
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
> .. _`Issue 18181`: http://bugs.python.org/issue18181
>
> .. _`super class`: http://docs.python.org/3/library/functions.html#super
>
> .. _`super proxy`: http://docs.python.org/3/library/functions.html#super
>
> .. _`super`: http://docs.python.org/3/library/functions.html#super
>
> .. _`dir()`: http://docs.python.org/3/library/functions.html#dir
>
> .. _`staticmethod`:
> http://docs.python.org/3/library/functions.html#staticmethod
>
> .. _`__dir__()`:
> https://docs.python.org/3/reference/datamodel.html#object.__dir__
>
> .. _`NotImplemented`:
> http://docs.python.org/3/library/constants.html#NotImplemented
>
> .. _`PyObject_GenericGetAttr`:
> http://docs.python.org/3/c-api/object.html#PyObject_GenericGetAttr
>
> .. _`type`: http://docs.python.org/3/library/functions.html#type
>
> .. _`AttributeError`:
> http://docs.python.org/3/library/exceptions.html#AttributeError
>
> .. _`PyObjC`: http://pyobjc.sourceforge.net/
>
> .. _`classmethod`:
> http://docs.python.org/3/library/functions.html#classmethod
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/dimaqq%40gmail.com
>

From ronaldoussoren at mac.com  Thu Jul 23 12:05:51 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 23 Jul 2015 12:05:51 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <CAGGBzXKKEfj_ZBTTP1aTmF0U8_yWgQPxzXODkz_2tMSup1UHLg@mail.gmail.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <CAGGBzXKKEfj_ZBTTP1aTmF0U8_yWgQPxzXODkz_2tMSup1UHLg@mail.gmail.com>
Message-ID: <DA476F1F-10CA-487C-BAD2-7939BCA751CD@mac.com>


> On 23 Jul 2015, at 11:29, Dima Tisnek <dimaqq at gmail.com> wrote:
> 
> Hey I've taken time to read the PEP, my 2c... actually 1c:
> 
> Most important is to explain how this changes behaviour of Python programs.
> 
> A comprehensive set of Python examples where behaviour is changed (for
> better or worse) please.

The behaviour of existing python code is not changed at all.  Code that directly looks in the class __dict__ might be impacted, but only when running into classes with a custom __getdescriptor__ method. I?ve listed the code in the stdlib that could be affected, but have to do a new pass of the stdlib to check if anything relevant changed since I wrote the section.   I general you run into the same issues when adding a custom __getattribute__ or __getattr__ method, both of which will confuse introspection tools that assume regular attribute lookup semantics.

> 
> While I understand the concern of "superclasses of objects that gain
> or lose attributes at runtime" on the theoretical level, please
> translate that into actual Python examples.

The primary use case I have for this are classes that are proxies for external systems. There may be other uses as well, but I don?t have examples of that (other than the contrived example in the PEP).

The reason I wrote the PEP in the first place is PyObjC: this project defines a proxy later between Python and Objective-C, with the goal to making it possible to write programs for Mac OS X in Python while being able to make full use of Apple?s high-level APIs.  The proxy layer is mostly completely dynamic: proxies for Objective-C classes and their methods are created at runtime by inspecting the Objective-C runtime with optionally extra annotations (provided by the project) for stuff that cannot be extracted from the runtime. 

That is, at runtime PyObjC creates a Python class ?NSObject? that corresponds to the Objective-C class ?NSObject? as defined by Apple. Every method of the Objective-C class is make available as a method on the Python proxy class as well.

It is not possible to 100% reliably set up the Python proxy class for ?NSObject? with all methods because Objective-C classes can grow new methods at runtime, and the introspection API that Apple provides does not have a way to detect this other than by polling.  Older versions of PyObjC did poll, but even that was not relialble enough and left a race condition:

     def someAction_(self, sender):
           self.someMethod()
           self.button.setTitle_(?click me?)
           super().someOtherMethod()

The call to ?someMethod? used to poll the Objective-C runtime for changes.  The call through super() of someOtherMethod() does not do so because of the current semantics of super (which PEP 447 tries to change). That?s a problem because ?self.button.setTitle_? might load a bundle that adds ?someOtherMethod? to one of our super classes. That sadly enough is not a theoretical concern, I?ve seen something like this in the past.

Because of this PyObjC contains its own version of builtins.super which must be used with it (and is fully compatible with builtin.super for other classes).

Recent versions of PyObjC no longer poll, primarily because polling is costly and because Objective-C classes tend to have fat APIs most of which is never used by any one program.

What bothers me with PyObjC?s current approach is one the one hand that a custom super is inherently incompatible with any other library that might have a simular need, and on there other hand that I have to reimplement all logic in both object.__getattribute__ and super.__getattribute__ to be able to have a customisation of one small aspect of attribute lookup.

Ronald

> 
> d.
> 
> On 22 July 2015 at 09:25, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> Hi,
>> 
>> Another summer with another EuroPython, which means its time again to try to
>> revive PEP 447?
>> 
>> I?ve just pushes a minor update to the PEP and would like to get some
>> feedback on this, arguably fairly esoteric, PEP.
>> 
>> The PEP proposes to to replace direct access to the class __dict__ in
>> object.__getattribute__ and super.__getattribute__ by calls to a new special
>> method to give the metaclass more control over attribute lookup, especially
>> for access using a super() object.  This is needed for classes that cannot
>> store (all) descriptors in the class dict for some reason, see the PEP text
>> for a real-world example of that.
>> 
>> Regards,
>> 
>>  Ronald
>> 
>> 
>> The PEP text (with an outdated section with benchmarks removed):
>> 
>> PEP: 447
>> Title: Add __getdescriptor__ method to metaclass
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Ronald Oussoren <ronaldoussoren at mac.com>
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 12-Jun-2013
>> Post-History: 2-Jul-2013, 15-Jul-2013, 29-Jul-2013, 22-Jul-2015
>> 
>> 
>> Abstract
>> ========
>> 
>> Currently ``object.__getattribute__`` and ``super.__getattribute__`` peek
>> in the ``__dict__`` of classes on the MRO for a class when looking for
>> an attribute. This PEP adds an optional ``__getdescriptor__`` method to
>> a metaclass that replaces this behavior and gives more control over
>> attribute
>> lookup, especially when using a `super`_ object.
>> 
>> That is, the MRO walking loop in ``_PyType_Lookup`` and
>> ``super.__getattribute__`` gets changed from::
>> 
>>     def lookup(mro_list, name):
>>         for cls in mro_list:
>>             if name in cls.__dict__:
>>                 return cls.__dict__
>> 
>>         return NotFound
>> 
>> to::
>> 
>>     def lookup(mro_list, name):
>>         for cls in mro_list:
>>             try:
>>                 return cls.__getdescriptor__(name)
>>             except AttributeError:
>>                 pass
>> 
>>         return NotFound
>> 
>> The default implemention of ``__getdescriptor__`` looks in the class
>> dictionary::
>> 
>>   class type:
>>      def __getdescriptor__(cls, name):
>>          try:
>>      return cls.__dict__[name]
>>  except KeyError:
>>      raise AttributeError(name) from None
>> 
>> Rationale
>> =========
>> 
>> It is currently not possible to influence how the `super class`_ looks
>> up attributes (that is, ``super.__getattribute__`` unconditionally
>> peeks in the class ``__dict__``), and that can be problematic for
>> dynamic classes that can grow new methods on demand.
>> 
>> The ``__getdescriptor__`` method makes it possible to dynamically add
>> attributes even when looking them up using the `super class`_.
>> 
>> The new method affects ``object.__getattribute__`` (and
>> `PyObject_GenericGetAttr`_) as well for consistency and to have a single
>> place to implement dynamic attribute resolution for classes.
>> 
>> Background
>> ----------
>> 
>> The current behavior of ``super.__getattribute__`` causes problems for
>> classes that are dynamic proxies for other (non-Python) classes or types,
>> an example of which is `PyObjC`_. PyObjC creates a Python class for every
>> class in the Objective-C runtime, and looks up methods in the Objective-C
>> runtime when they are used. This works fine for normal access, but doesn't
>> work for access with `super`_ objects. Because of this PyObjC currently
>> includes a custom `super`_ that must be used with its classes, as well as
>> completely reimplementing `PyObject_GenericGetAttr`_ for normal attribute
>> access.
>> 
>> The API in this PEP makes it possible to remove the custom `super`_ and
>> simplifies the implementation because the custom lookup behavior can be
>> added in a central location.
>> 
>> .. note::
>> 
>>   `PyObjC`_ cannot precalculate the contents of the class ``__dict__``
>>   because Objective-C classes can grow new methods at runtime. Furthermore
>>   Objective-C classes tend to contain a lot of methods while most Python
>>   code will only use a small subset of them, this makes precalculating
>>   unnecessarily expensive.
>> 
>> 
>> The superclass attribute lookup hook
>> ====================================
>> 
>> Both ``super.__getattribute__`` and ``object.__getattribute__`` (or
>> `PyObject_GenericGetAttr`_ and in particular ``_PyType_Lookup`` in C code)
>> walk an object's MRO and currently peek in the class' ``__dict__`` to look
>> up
>> attributes.
>> 
>> With this proposal both lookup methods no longer peek in the class
>> ``__dict__``
>> but call the special method ``__getdescriptor__``, which is a slot defined
>> on the metaclass. The default implementation of that method looks
>> up the name the class ``__dict__``, which means that attribute lookup is
>> unchanged unless a metatype actually defines the new special method.
>> 
>> Aside: Attribute resolution algorithm in Python
>> -----------------------------------------------
>> 
>> The attribute resolution proces as implemented by
>> ``object.__getattribute__``
>> (or PyObject_GenericGetAttr`` in CPython's implementation) is fairly
>> straightforward, but not entirely so without reading C code.
>> 
>> The current CPython implementation of object.__getattribute__ is basicly
>> equivalent to the following (pseudo-) Python code (excluding some house
>> keeping and speed tricks)::
>> 
>> 
>>    def _PyType_Lookup(tp, name):
>>        mro = tp.mro()
>> assert isinstance(mro, tuple)
>> 
>> for base in mro:
>>  assert isinstance(base, type)
>> 
>>  # PEP 447 will change these lines:
>>  try:
>>      return base.__dict__[name]
>>  except KeyError:
>>      pass
>> 
>> return None
>> 
>> 
>>    class object:
>>        def __getattribute__(self, name):
>>    assert isinstance(name, str)
>> 
>>    tp = type(self)
>>    descr = _PyType_Lookup(tp, name)
>> 
>>    f = None
>>    if descr is not None:
>>        f = descr.__get__
>> if f is not None and descr.__set__ is not None:
>>    # Data descriptor
>>    return f(descr, self, type(self))
>> 
>>            dict = self.__dict__
>>    if dict is not None:
>>        try:
>>    return self.__dict__[name]
>>                except KeyError:
>>            pass
>> 
>>            if f is not None:
>>        # Non-data descriptor
>>        return f(descr, self, type(self))
>> 
>>            if descr is not None:
>>        # Regular class attribute
>>        return descr
>> 
>>            raise AttributeError(name)
>> 
>> 
>>    class super:
>>        def __getattribute__(self, name):
>>  assert isinstance(name, unicode)
>> 
>>  if name != '__class__':
>>      starttype = self.__self_type__
>>      mro = startype.mro()
>> 
>>      try:
>>          idx = mro.index(self.__thisclass__)
>> 
>>      except ValueError:
>>          pass
>> 
>>      else:
>>          for base in mro[idx+1:]:
>>      # PEP 447 will change these lines:
>>      try:
>>          descr = base.__dict__[name]
>>                       except KeyError:
>>          continue
>> 
>>      f = descr.__get__
>>      if f is not None:
>>          return f(descr,
>>      None if (self.__self__ is self.__self_type__) else self.__self__,
>>      starttype)
>> 
>>      else:
>>          return descr
>> 
>>  return object.__getattribute__(self, name)
>> 
>> 
>> This PEP should change the dict lookup at the lines starting at "# PEP 447"
>> with
>> a method call to perform the actual lookup, making is possible to affect
>> that
>> lookup both for normal attribute access and access through the `super
>> proxy`_.
>> 
>> Note that specific classes can already completely override the default
>> behaviour by implementing their own ``__getattribute__`` slot (with or
>> without
>> calling the super class implementation).
>> 
>> 
>> In Python code
>> --------------
>> 
>> A meta type can define a method ``__getdescriptor__`` that is called during
>> attribute resolution by both ``super.__getattribute__``
>> and ``object.__getattribute``::
>> 
>>    class MetaType(type):
>>        def __getdescriptor__(cls, name):
>>            try:
>>                return cls.__dict__[name]
>>            except KeyError:
>>                raise AttributeError(name) from None
>> 
>> The ``__getdescriptor__`` method has as its arguments a class (which is an
>> instance of the meta type) and the name of the attribute that is looked up.
>> It should return the value of the attribute without invoking descriptors,
>> and should raise `AttributeError`_ when the name cannot be found.
>> 
>> The `type`_ class provides a default implementation for
>> ``__getdescriptor__``,
>> that looks up the name in the class dictionary.
>> 
>> Example usage
>> .............
>> 
>> The code below implements a silly metaclass that redirects attribute lookup
>> to
>> uppercase versions of names::
>> 
>>    class UpperCaseAccess (type):
>>        def __getdescriptor__(cls, name):
>>    try:
>>                return cls.__dict__[name.upper()]
>>    except KeyError:
>>        raise AttributeError(name) from None
>> 
>>    class SillyObject (metaclass=UpperCaseAccess):
>>        def m(self):
>>            return 42
>> 
>>        def M(self):
>>            return "fourtytwo"
>> 
>>    obj = SillyObject()
>>    assert obj.m() == "fortytwo"
>> 
>> As mentioned earlier in this PEP a more realistic use case of this
>> functionallity is a ``__getdescriptor__`` method that dynamicly populates
>> the
>> class ``__dict__`` based on attribute access, primarily when it is not
>> possible to reliably keep the class dict in sync with its source, for
>> example
>> because the source used to populate ``__dict__`` is dynamic as well and does
>> not have triggers that can be used to detect changes to that source.
>> 
>> An example of that are the class bridges in PyObjC: the class bridge is a
>> Python object (class) that represents an Objective-C class and conceptually
>> has a Python method for every Objective-C method in the Objective-C class.
>> As with Python it is possible to add new methods to an Objective-C class, or
>> replace existing ones, and there are no callbacks that can be used to detect
>> this.
>> 
>> In C code
>> ---------
>> 
>> A new slot ``tp_getdescriptor`` is added to the ``PyTypeObject`` struct,
>> this
>> slot corresponds to the ``__getdescriptor__`` method on `type`_.
>> 
>> The slot has the following prototype::
>> 
>>    PyObject* (*getdescriptorfunc)(PyTypeObject* cls, PyObject* name);
>> 
>> This method should lookup *name* in the namespace of *cls*, without looking
>> at
>> superclasses, and should not invoke descriptors. The method returns ``NULL``
>> without setting an exception when the *name* cannot be found, and returns a
>> new reference otherwise (not a borrowed reference).
>> 
>> Use of this hook by the interpreter
>> -----------------------------------
>> 
>> The new method is required for metatypes and as such is defined on `type_`.
>> Both ``super.__getattribute__`` and
>> ``object.__getattribute__``/`PyObject_GenericGetAttr`_
>> (through ``_PyType_Lookup``) use the this ``__getdescriptor__`` method when
>> walking the MRO.
>> 
>> Other changes to the implementation
>> -----------------------------------
>> 
>> The change for `PyObject_GenericGetAttr`_ will be done by changing the
>> private
>> function ``_PyType_Lookup``. This currently returns a borrowed reference,
>> but
>> must return a new reference when the ``__getdescriptor__`` method is
>> present.
>> Because of this ``_PyType_Lookup`` will be renamed to
>> ``_PyType_LookupName``,
>> this will cause compile-time errors for all out-of-tree users of this
>> private API.
>> 
>> The attribute lookup cache in ``Objects/typeobject.c`` is disabled for
>> classes
>> that have a metaclass that overrides ``__getdescriptor__``, because using
>> the
>> cache might not be valid for such classes.
>> 
>> Impact of this PEP on introspection
>> -----------------------------------
>> 
>> Use of the method introduced in this PEP can affect introspection of classes
>> with a metaclass that uses a custom ``__getdescriptor__`` method. This
>> section
>> lists those changes.
>> 
>> The items listed below are only affected by custom ``__getdescriptor__``
>> methods, the default implementation for ``object`` won't cause problems
>> because that still only uses the class ``__dict__`` and won't cause visible
>> changes to the visible behaviour of the ``object.__getattribute__``.
>> 
>> * ``dir`` might not show all attributes
>> 
>>  As with a custom ``__getattribute__`` method `dir()`_ might not see all
>>  (instance) attributes when using the ``__getdescriptor__()`` method to
>>  dynamicly resolve attributes.
>> 
>>  The solution for that is quite simple: classes using ``__getdescriptor__``
>>  should also implement `__dir__()`_ if they want full support for the
>> builtin
>>  `dir()`_ function.
>> 
>> * ``inspect.getattr_static`` might not show all attributes
>> 
>>  The function ``inspect.getattr_static`` intentionally does not invoke
>>  ``__getattribute__`` and descriptors to avoid invoking user code during
>>  introspection with this function. The ``__getdescriptor__`` method will
>> also
>>  be ignored and is another way in which the result of
>> ``inspect.getattr_static``
>>  can be different from that of ``builtin.getattr``.
>> 
>> * ``inspect.getmembers`` and ``inspect.get_class_attrs``
>> 
>>  Both of these functions directly access the class __dict__ of classes
>> along
>>  the MRO, and hence can be affected by a custom ``__getdescriptor__``
>> method.
>> 
>>  **TODO**: I haven't fully worked out what the impact of this is, and if
>> there
>>  are mitigations for those using either updates to these functions, or
>>  additional methods that users should implement to be fully compatible with
>>  these functions.
>> 
>>  One possible mitigation is to have a custom ``__getattribute__`` for these
>>  classes that fills ``__dict__`` before returning and and defers to the
>>  default implementation for other attributes.
>> 
>> * Direct introspection of the class ``__dict__``
>> 
>>  Any code that directly access the class ``__dict__`` for introspection
>>  can be affected by a custom ``__getdescriptor__`` method.
>> 
>> 
>> Performance impact
>> ------------------
>> 
>> **WARNING**: The benchmark results in this section are old, and will be
>> updated
>> when I've ported the patch to the current trunk. I don't expect significant
>> changes to the results in this section.
>> 
>> [snipped]
>> 
>> 
>> Alternative proposals
>> ---------------------
>> 
>> ``__getattribute_super__``
>> ..........................
>> 
>> An earlier version of this PEP used the following static method on classes::
>> 
>>    def __getattribute_super__(cls, name, object, owner): pass
>> 
>> This method performed name lookup as well as invoking descriptors and was
>> necessarily limited to working only with ``super.__getattribute__``.
>> 
>> 
>> Reuse ``tp_getattro``
>> .....................
>> 
>> It would be nice to avoid adding a new slot, thus keeping the API simpler
>> and
>> easier to understand.  A comment on `Issue 18181`_ asked about reusing the
>> ``tp_getattro`` slot, that is super could call the ``tp_getattro`` slot of
>> all
>> methods along the MRO.
>> 
>> That won't work because ``tp_getattro`` will look in the instance
>> ``__dict__`` before it tries to resolve attributes using classes in the MRO.
>> This would mean that using ``tp_getattro`` instead of peeking the class
>> dictionaries changes the semantics of the `super class`_.
>> 
>> Alternate placement of the new method
>> .....................................
>> 
>> This PEP proposes to add ``__getdescriptor__`` as a method on the metaclass.
>> An alternative would be to add it as a class method on the class itself
>> (simular to how ``__new__`` is a `staticmethod`_ of the class and not a
>> method
>> of the metaclass).
>> 
>> The two are functionally equivalent, and there's something to be said about
>> not requiring the use of a meta class.
>> 
>> 
>> References
>> ==========
>> 
>> * `Issue 18181`_ contains an out of date prototype implementation
>> 
>> Copyright
>> =========
>> 
>> This document has been placed in the public domain.
>> 
>> .. _`Issue 18181`: http://bugs.python.org/issue18181
>> 
>> .. _`super class`: http://docs.python.org/3/library/functions.html#super
>> 
>> .. _`super proxy`: http://docs.python.org/3/library/functions.html#super
>> 
>> .. _`super`: http://docs.python.org/3/library/functions.html#super
>> 
>> .. _`dir()`: http://docs.python.org/3/library/functions.html#dir
>> 
>> .. _`staticmethod`:
>> http://docs.python.org/3/library/functions.html#staticmethod
>> 
>> .. _`__dir__()`:
>> https://docs.python.org/3/reference/datamodel.html#object.__dir__
>> 
>> .. _`NotImplemented`:
>> http://docs.python.org/3/library/constants.html#NotImplemented
>> 
>> .. _`PyObject_GenericGetAttr`:
>> http://docs.python.org/3/c-api/object.html#PyObject_GenericGetAttr
>> 
>> .. _`type`: http://docs.python.org/3/library/functions.html#type
>> 
>> .. _`AttributeError`:
>> http://docs.python.org/3/library/exceptions.html#AttributeError
>> 
>> .. _`PyObjC`: http://pyobjc.sourceforge.net/
>> 
>> .. _`classmethod`:
>> http://docs.python.org/3/library/functions.html#classmethod
>> 
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/dimaqq%40gmail.com
>> 


From p.f.moore at gmail.com  Thu Jul 23 12:06:52 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 23 Jul 2015 11:06:52 +0100
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process? (was Re: How far to go with user-friendliness)
In-Reply-To: <CAP7h-xYnAdhcE_bAWhFS6x2hoAAGa77UgtJ7Opt5-ZNBUSCX6g@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <87pp3ldjel.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACac1F93wdhfVQrDtAkVVFxSC4S=0oRdRqNMt8kp3-+14u0FGA@mail.gmail.com>
 <CAP7h-xYnAdhcE_bAWhFS6x2hoAAGa77UgtJ7Opt5-ZNBUSCX6g@mail.gmail.com>
Message-ID: <CACac1F_Pts80VqCRvZe0hofN=y_eiFLT7XOAFw2Na3B47BDQyA@mail.gmail.com>

On 23 July 2015 at 03:01, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Wed, Jul 22, 2015 at 7:09 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> does anyone seriously think a core dev
>> commits code as a joke???
>
>
> Yes, <https://hg.python.org/cpython/rev/0530aadff696>. :-)

Second person to pick me up on that :-)

Paul

From jsbueno at python.org.br  Thu Jul 23 15:52:54 2015
From: jsbueno at python.org.br (Joao S. O. Bueno)
Date: Thu, 23 Jul 2015 10:52:54 -0300
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <9796C183-C2EE-4415-8E5C-653E22E5304F@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
 <9796C183-C2EE-4415-8E5C-653E22E5304F@mac.com>
Message-ID: <CAH0mxTSD6zwGMFNRJHDxVCVH5dJibA0b6+FuAT0Bb=HcQorsVA@mail.gmail.com>

On 22 July 2015 at 14:21, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>
>> 2. Is this useful, that you can think of, for anything other than connecting to Objective C?
>
> Not immediately.  But then again, I initially thought that decorators would have limited appeal as well :-).  I guess this could be useful for other proxy-like objects as well, especially when preloading the __dict__ is relatively expensive.
>

I think one place this could be immediately useful is in code using
remote method invocation/remote attribute access. This allows one to
subclass proxy types for remote objects, and call methods that resolve
remotely in a seamless way.
(And without having to download and pre-populate an entire API into
the proxy-class __dict__)

+1
I found the solution rather concise for the flexibility it adds as well.
> Apart from direct usefulness this closes a hole in the way you can influence attribute lookup.
>
> Ronald

From guido at python.org  Thu Jul 23 17:07:59 2015
From: guido at python.org (Guido van Rossum)
Date: Thu, 23 Jul 2015 17:07:59 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
Message-ID: <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>

Sorry for reviving this thread, but I was cornered at EuroPython with a
question about the status of this PEP. It seems the proposal ran out of
steam and has now missed the Python 3.5 train. What happened? Is the
problem unsolvable? Or could we get this into 3.6???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150723/5a93db6a/attachment.html>

From Steve.Dower at microsoft.com  Thu Jul 23 14:43:03 2015
From: Steve.Dower at microsoft.com (Steve Dower)
Date: Thu, 23 Jul 2015 12:43:03 +0000
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <DA476F1F-10CA-487C-BAD2-7939BCA751CD@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <CAGGBzXKKEfj_ZBTTP1aTmF0U8_yWgQPxzXODkz_2tMSup1UHLg@mail.gmail.com>,
 <DA476F1F-10CA-487C-BAD2-7939BCA751CD@mac.com>
Message-ID: <BLUPR0301MB16522566973381F3E170F650F5820@BLUPR0301MB1652.namprd03.prod.outlook.com>

I wonder whether XML RPC might be a good example? After all, it's already in the stdlib and presumably suffers from the same issue.

Cheers,
Steve

Top-posted from my Windows Phone
________________________________
From: Ronald Oussoren<mailto:ronaldoussoren at mac.com>
Sent: ?7/?23/?2015 3:07
To: Dima Tisnek<mailto:dimaqq at gmail.com>
Cc: Python Dev<mailto:python-dev at python.org>
Subject: Re: [Python-Dev] PEP 447 (type.__getdescriptor__)


> On 23 Jul 2015, at 11:29, Dima Tisnek <dimaqq at gmail.com> wrote:
>
> Hey I've taken time to read the PEP, my 2c... actually 1c:
>
> Most important is to explain how this changes behaviour of Python programs.
>
> A comprehensive set of Python examples where behaviour is changed (for
> better or worse) please.

The behaviour of existing python code is not changed at all.  Code that directly looks in the class __dict__ might be impacted, but only when running into classes with a custom __getdescriptor__ method. I?ve listed the code in the stdlib that could be affected, but have to do a new pass of the stdlib to check if anything relevant changed since I wrote the section.   I general you run into the same issues when adding a custom __getattribute__ or __getattr__ method, both of which will confuse introspection tools that assume regular attribute lookup semantics.

>
> While I understand the concern of "superclasses of objects that gain
> or lose attributes at runtime" on the theoretical level, please
> translate that into actual Python examples.

The primary use case I have for this are classes that are proxies for external systems. There may be other uses as well, but I don?t have examples of that (other than the contrived example in the PEP).

The reason I wrote the PEP in the first place is PyObjC: this project defines a proxy later between Python and Objective-C, with the goal to making it possible to write programs for Mac OS X in Python while being able to make full use of Apple?s high-level APIs.  The proxy layer is mostly completely dynamic: proxies for Objective-C classes and their methods are created at runtime by inspecting the Objective-C runtime with optionally extra annotations (provided by the project) for stuff that cannot be extracted from the runtime.

That is, at runtime PyObjC creates a Python class ?NSObject? that corresponds to the Objective-C class ?NSObject? as defined by Apple. Every method of the Objective-C class is make available as a method on the Python proxy class as well.

It is not possible to 100% reliably set up the Python proxy class for ?NSObject? with all methods because Objective-C classes can grow new methods at runtime, and the introspection API that Apple provides does not have a way to detect this other than by polling.  Older versions of PyObjC did poll, but even that was not relialble enough and left a race condition:

     def someAction_(self, sender):
           self.someMethod()
           self.button.setTitle_(?click me?)
           super().someOtherMethod()

The call to ?someMethod? used to poll the Objective-C runtime for changes.  The call through super() of someOtherMethod() does not do so because of the current semantics of super (which PEP 447 tries to change). That?s a problem because ?self.button.setTitle_? might load a bundle that adds ?someOtherMethod? to one of our super classes. That sadly enough is not a theoretical concern, I?ve seen something like this in the past.

Because of this PyObjC contains its own version of builtins.super which must be used with it (and is fully compatible with builtin.super for other classes).

Recent versions of PyObjC no longer poll, primarily because polling is costly and because Objective-C classes tend to have fat APIs most of which is never used by any one program.

What bothers me with PyObjC?s current approach is one the one hand that a custom super is inherently incompatible with any other library that might have a simular need, and on there other hand that I have to reimplement all logic in both object.__getattribute__ and super.__getattribute__ to be able to have a customisation of one small aspect of attribute lookup.

Ronald

>
> d.
>
> On 22 July 2015 at 09:25, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> Hi,
>>
>> Another summer with another EuroPython, which means its time again to try to
>> revive PEP 447?
>>
>> I?ve just pushes a minor update to the PEP and would like to get some
>> feedback on this, arguably fairly esoteric, PEP.
>>
>> The PEP proposes to to replace direct access to the class __dict__ in
>> object.__getattribute__ and super.__getattribute__ by calls to a new special
>> method to give the metaclass more control over attribute lookup, especially
>> for access using a super() object.  This is needed for classes that cannot
>> store (all) descriptors in the class dict for some reason, see the PEP text
>> for a real-world example of that.
>>
>> Regards,
>>
>>  Ronald
>>
>>
>> The PEP text (with an outdated section with benchmarks removed):
>>
>> PEP: 447
>> Title: Add __getdescriptor__ method to metaclass
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Ronald Oussoren <ronaldoussoren at mac.com>
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 12-Jun-2013
>> Post-History: 2-Jul-2013, 15-Jul-2013, 29-Jul-2013, 22-Jul-2015
>>
>>
>> Abstract
>> ========
>>
>> Currently ``object.__getattribute__`` and ``super.__getattribute__`` peek
>> in the ``__dict__`` of classes on the MRO for a class when looking for
>> an attribute. This PEP adds an optional ``__getdescriptor__`` method to
>> a metaclass that replaces this behavior and gives more control over
>> attribute
>> lookup, especially when using a `super`_ object.
>>
>> That is, the MRO walking loop in ``_PyType_Lookup`` and
>> ``super.__getattribute__`` gets changed from::
>>
>>     def lookup(mro_list, name):
>>         for cls in mro_list:
>>             if name in cls.__dict__:
>>                 return cls.__dict__
>>
>>         return NotFound
>>
>> to::
>>
>>     def lookup(mro_list, name):
>>         for cls in mro_list:
>>             try:
>>                 return cls.__getdescriptor__(name)
>>             except AttributeError:
>>                 pass
>>
>>         return NotFound
>>
>> The default implemention of ``__getdescriptor__`` looks in the class
>> dictionary::
>>
>>   class type:
>>      def __getdescriptor__(cls, name):
>>          try:
>>      return cls.__dict__[name]
>>  except KeyError:
>>      raise AttributeError(name) from None
>>
>> Rationale
>> =========
>>
>> It is currently not possible to influence how the `super class`_ looks
>> up attributes (that is, ``super.__getattribute__`` unconditionally
>> peeks in the class ``__dict__``), and that can be problematic for
>> dynamic classes that can grow new methods on demand.
>>
>> The ``__getdescriptor__`` method makes it possible to dynamically add
>> attributes even when looking them up using the `super class`_.
>>
>> The new method affects ``object.__getattribute__`` (and
>> `PyObject_GenericGetAttr`_) as well for consistency and to have a single
>> place to implement dynamic attribute resolution for classes.
>>
>> Background
>> ----------
>>
>> The current behavior of ``super.__getattribute__`` causes problems for
>> classes that are dynamic proxies for other (non-Python) classes or types,
>> an example of which is `PyObjC`_. PyObjC creates a Python class for every
>> class in the Objective-C runtime, and looks up methods in the Objective-C
>> runtime when they are used. This works fine for normal access, but doesn't
>> work for access with `super`_ objects. Because of this PyObjC currently
>> includes a custom `super`_ that must be used with its classes, as well as
>> completely reimplementing `PyObject_GenericGetAttr`_ for normal attribute
>> access.
>>
>> The API in this PEP makes it possible to remove the custom `super`_ and
>> simplifies the implementation because the custom lookup behavior can be
>> added in a central location.
>>
>> .. note::
>>
>>   `PyObjC`_ cannot precalculate the contents of the class ``__dict__``
>>   because Objective-C classes can grow new methods at runtime. Furthermore
>>   Objective-C classes tend to contain a lot of methods while most Python
>>   code will only use a small subset of them, this makes precalculating
>>   unnecessarily expensive.
>>
>>
>> The superclass attribute lookup hook
>> ====================================
>>
>> Both ``super.__getattribute__`` and ``object.__getattribute__`` (or
>> `PyObject_GenericGetAttr`_ and in particular ``_PyType_Lookup`` in C code)
>> walk an object's MRO and currently peek in the class' ``__dict__`` to look
>> up
>> attributes.
>>
>> With this proposal both lookup methods no longer peek in the class
>> ``__dict__``
>> but call the special method ``__getdescriptor__``, which is a slot defined
>> on the metaclass. The default implementation of that method looks
>> up the name the class ``__dict__``, which means that attribute lookup is
>> unchanged unless a metatype actually defines the new special method.
>>
>> Aside: Attribute resolution algorithm in Python
>> -----------------------------------------------
>>
>> The attribute resolution proces as implemented by
>> ``object.__getattribute__``
>> (or PyObject_GenericGetAttr`` in CPython's implementation) is fairly
>> straightforward, but not entirely so without reading C code.
>>
>> The current CPython implementation of object.__getattribute__ is basicly
>> equivalent to the following (pseudo-) Python code (excluding some house
>> keeping and speed tricks)::
>>
>>
>>    def _PyType_Lookup(tp, name):
>>        mro = tp.mro()
>> assert isinstance(mro, tuple)
>>
>> for base in mro:
>>  assert isinstance(base, type)
>>
>>  # PEP 447 will change these lines:
>>  try:
>>      return base.__dict__[name]
>>  except KeyError:
>>      pass
>>
>> return None
>>
>>
>>    class object:
>>        def __getattribute__(self, name):
>>    assert isinstance(name, str)
>>
>>    tp = type(self)
>>    descr = _PyType_Lookup(tp, name)
>>
>>    f = None
>>    if descr is not None:
>>        f = descr.__get__
>> if f is not None and descr.__set__ is not None:
>>    # Data descriptor
>>    return f(descr, self, type(self))
>>
>>            dict = self.__dict__
>>    if dict is not None:
>>        try:
>>    return self.__dict__[name]
>>                except KeyError:
>>            pass
>>
>>            if f is not None:
>>        # Non-data descriptor
>>        return f(descr, self, type(self))
>>
>>            if descr is not None:
>>        # Regular class attribute
>>        return descr
>>
>>            raise AttributeError(name)
>>
>>
>>    class super:
>>        def __getattribute__(self, name):
>>  assert isinstance(name, unicode)
>>
>>  if name != '__class__':
>>      starttype = self.__self_type__
>>      mro = startype.mro()
>>
>>      try:
>>          idx = mro.index(self.__thisclass__)
>>
>>      except ValueError:
>>          pass
>>
>>      else:
>>          for base in mro[idx+1:]:
>>      # PEP 447 will change these lines:
>>      try:
>>          descr = base.__dict__[name]
>>                       except KeyError:
>>          continue
>>
>>      f = descr.__get__
>>      if f is not None:
>>          return f(descr,
>>      None if (self.__self__ is self.__self_type__) else self.__self__,
>>      starttype)
>>
>>      else:
>>          return descr
>>
>>  return object.__getattribute__(self, name)
>>
>>
>> This PEP should change the dict lookup at the lines starting at "# PEP 447"
>> with
>> a method call to perform the actual lookup, making is possible to affect
>> that
>> lookup both for normal attribute access and access through the `super
>> proxy`_.
>>
>> Note that specific classes can already completely override the default
>> behaviour by implementing their own ``__getattribute__`` slot (with or
>> without
>> calling the super class implementation).
>>
>>
>> In Python code
>> --------------
>>
>> A meta type can define a method ``__getdescriptor__`` that is called during
>> attribute resolution by both ``super.__getattribute__``
>> and ``object.__getattribute``::
>>
>>    class MetaType(type):
>>        def __getdescriptor__(cls, name):
>>            try:
>>                return cls.__dict__[name]
>>            except KeyError:
>>                raise AttributeError(name) from None
>>
>> The ``__getdescriptor__`` method has as its arguments a class (which is an
>> instance of the meta type) and the name of the attribute that is looked up.
>> It should return the value of the attribute without invoking descriptors,
>> and should raise `AttributeError`_ when the name cannot be found.
>>
>> The `type`_ class provides a default implementation for
>> ``__getdescriptor__``,
>> that looks up the name in the class dictionary.
>>
>> Example usage
>> .............
>>
>> The code below implements a silly metaclass that redirects attribute lookup
>> to
>> uppercase versions of names::
>>
>>    class UpperCaseAccess (type):
>>        def __getdescriptor__(cls, name):
>>    try:
>>                return cls.__dict__[name.upper()]
>>    except KeyError:
>>        raise AttributeError(name) from None
>>
>>    class SillyObject (metaclass=UpperCaseAccess):
>>        def m(self):
>>            return 42
>>
>>        def M(self):
>>            return "fourtytwo"
>>
>>    obj = SillyObject()
>>    assert obj.m() == "fortytwo"
>>
>> As mentioned earlier in this PEP a more realistic use case of this
>> functionallity is a ``__getdescriptor__`` method that dynamicly populates
>> the
>> class ``__dict__`` based on attribute access, primarily when it is not
>> possible to reliably keep the class dict in sync with its source, for
>> example
>> because the source used to populate ``__dict__`` is dynamic as well and does
>> not have triggers that can be used to detect changes to that source.
>>
>> An example of that are the class bridges in PyObjC: the class bridge is a
>> Python object (class) that represents an Objective-C class and conceptually
>> has a Python method for every Objective-C method in the Objective-C class.
>> As with Python it is possible to add new methods to an Objective-C class, or
>> replace existing ones, and there are no callbacks that can be used to detect
>> this.
>>
>> In C code
>> ---------
>>
>> A new slot ``tp_getdescriptor`` is added to the ``PyTypeObject`` struct,
>> this
>> slot corresponds to the ``__getdescriptor__`` method on `type`_.
>>
>> The slot has the following prototype::
>>
>>    PyObject* (*getdescriptorfunc)(PyTypeObject* cls, PyObject* name);
>>
>> This method should lookup *name* in the namespace of *cls*, without looking
>> at
>> superclasses, and should not invoke descriptors. The method returns ``NULL``
>> without setting an exception when the *name* cannot be found, and returns a
>> new reference otherwise (not a borrowed reference).
>>
>> Use of this hook by the interpreter
>> -----------------------------------
>>
>> The new method is required for metatypes and as such is defined on `type_`.
>> Both ``super.__getattribute__`` and
>> ``object.__getattribute__``/`PyObject_GenericGetAttr`_
>> (through ``_PyType_Lookup``) use the this ``__getdescriptor__`` method when
>> walking the MRO.
>>
>> Other changes to the implementation
>> -----------------------------------
>>
>> The change for `PyObject_GenericGetAttr`_ will be done by changing the
>> private
>> function ``_PyType_Lookup``. This currently returns a borrowed reference,
>> but
>> must return a new reference when the ``__getdescriptor__`` method is
>> present.
>> Because of this ``_PyType_Lookup`` will be renamed to
>> ``_PyType_LookupName``,
>> this will cause compile-time errors for all out-of-tree users of this
>> private API.
>>
>> The attribute lookup cache in ``Objects/typeobject.c`` is disabled for
>> classes
>> that have a metaclass that overrides ``__getdescriptor__``, because using
>> the
>> cache might not be valid for such classes.
>>
>> Impact of this PEP on introspection
>> -----------------------------------
>>
>> Use of the method introduced in this PEP can affect introspection of classes
>> with a metaclass that uses a custom ``__getdescriptor__`` method. This
>> section
>> lists those changes.
>>
>> The items listed below are only affected by custom ``__getdescriptor__``
>> methods, the default implementation for ``object`` won't cause problems
>> because that still only uses the class ``__dict__`` and won't cause visible
>> changes to the visible behaviour of the ``object.__getattribute__``.
>>
>> * ``dir`` might not show all attributes
>>
>>  As with a custom ``__getattribute__`` method `dir()`_ might not see all
>>  (instance) attributes when using the ``__getdescriptor__()`` method to
>>  dynamicly resolve attributes.
>>
>>  The solution for that is quite simple: classes using ``__getdescriptor__``
>>  should also implement `__dir__()`_ if they want full support for the
>> builtin
>>  `dir()`_ function.
>>
>> * ``inspect.getattr_static`` might not show all attributes
>>
>>  The function ``inspect.getattr_static`` intentionally does not invoke
>>  ``__getattribute__`` and descriptors to avoid invoking user code during
>>  introspection with this function. The ``__getdescriptor__`` method will
>> also
>>  be ignored and is another way in which the result of
>> ``inspect.getattr_static``
>>  can be different from that of ``builtin.getattr``.
>>
>> * ``inspect.getmembers`` and ``inspect.get_class_attrs``
>>
>>  Both of these functions directly access the class __dict__ of classes
>> along
>>  the MRO, and hence can be affected by a custom ``__getdescriptor__``
>> method.
>>
>>  **TODO**: I haven't fully worked out what the impact of this is, and if
>> there
>>  are mitigations for those using either updates to these functions, or
>>  additional methods that users should implement to be fully compatible with
>>  these functions.
>>
>>  One possible mitigation is to have a custom ``__getattribute__`` for these
>>  classes that fills ``__dict__`` before returning and and defers to the
>>  default implementation for other attributes.
>>
>> * Direct introspection of the class ``__dict__``
>>
>>  Any code that directly access the class ``__dict__`` for introspection
>>  can be affected by a custom ``__getdescriptor__`` method.
>>
>>
>> Performance impact
>> ------------------
>>
>> **WARNING**: The benchmark results in this section are old, and will be
>> updated
>> when I've ported the patch to the current trunk. I don't expect significant
>> changes to the results in this section.
>>
>> [snipped]
>>
>>
>> Alternative proposals
>> ---------------------
>>
>> ``__getattribute_super__``
>> ..........................
>>
>> An earlier version of this PEP used the following static method on classes::
>>
>>    def __getattribute_super__(cls, name, object, owner): pass
>>
>> This method performed name lookup as well as invoking descriptors and was
>> necessarily limited to working only with ``super.__getattribute__``.
>>
>>
>> Reuse ``tp_getattro``
>> .....................
>>
>> It would be nice to avoid adding a new slot, thus keeping the API simpler
>> and
>> easier to understand.  A comment on `Issue 18181`_ asked about reusing the
>> ``tp_getattro`` slot, that is super could call the ``tp_getattro`` slot of
>> all
>> methods along the MRO.
>>
>> That won't work because ``tp_getattro`` will look in the instance
>> ``__dict__`` before it tries to resolve attributes using classes in the MRO.
>> This would mean that using ``tp_getattro`` instead of peeking the class
>> dictionaries changes the semantics of the `super class`_.
>>
>> Alternate placement of the new method
>> .....................................
>>
>> This PEP proposes to add ``__getdescriptor__`` as a method on the metaclass.
>> An alternative would be to add it as a class method on the class itself
>> (simular to how ``__new__`` is a `staticmethod`_ of the class and not a
>> method
>> of the metaclass).
>>
>> The two are functionally equivalent, and there's something to be said about
>> not requiring the use of a meta class.
>>
>>
>> References
>> ==========
>>
>> * `Issue 18181`_ contains an out of date prototype implementation
>>
>> Copyright
>> =========
>>
>> This document has been placed in the public domain.
>>
>> .. _`Issue 18181`: http://bugs.python.org/issue18181
>>
>> .. _`super class`: http://docs.python.org/3/library/functions.html#super
>>
>> .. _`super proxy`: http://docs.python.org/3/library/functions.html#super
>>
>> .. _`super`: http://docs.python.org/3/library/functions.html#super
>>
>> .. _`dir()`: http://docs.python.org/3/library/functions.html#dir
>>
>> .. _`staticmethod`:
>> http://docs.python.org/3/library/functions.html#staticmethod
>>
>> .. _`__dir__()`:
>> https://docs.python.org/3/reference/datamodel.html#object.__dir__
>>
>> .. _`NotImplemented`:
>> http://docs.python.org/3/library/constants.html#NotImplemented
>>
>> .. _`PyObject_GenericGetAttr`:
>> http://docs.python.org/3/c-api/object.html#PyObject_GenericGetAttr
>>
>> .. _`type`: http://docs.python.org/3/library/functions.html#type
>>
>> .. _`AttributeError`:
>> http://docs.python.org/3/library/exceptions.html#AttributeError
>>
>> .. _`PyObjC`: http://pyobjc.sourceforge.net/
>>
>> .. _`classmethod`:
>> http://docs.python.org/3/library/functions.html#classmethod
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/dimaqq%40gmail.com
>>

_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150723/beee9ac2/attachment-0001.html>

From regebro at gmail.com  Thu Jul 23 18:22:35 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2015 18:22:35 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
Message-ID: <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>

On Thu, Jul 23, 2015 at 5:07 PM, Guido van Rossum <guido at python.org> wrote:
> Sorry for reviving this thread, but I was cornered at EuroPython with a
> question about the status of this PEP. It seems the proposal ran out of
> steam and has now missed the Python 3.5 train. What happened? Is the problem
> unsolvable? Or could we get this into 3.6???

It turns out it's very complex to solve this when internally storing
the time as the local time. Basically you have to normalize the time
(ie check if daylight savings have changed) when doing arithmetic, but
normalize is doing arithmetic, and you get infinite recursion. I've
tried various ways to solve this but ran out of steam/brainpower.

I think we should look into storing as UTC internally instead. It's a
big change (and also needs handling pickles in a backwards compatible
way) but I think that's the way forward.

//Lennart

From robertc at robertcollins.net  Thu Jul 23 18:30:45 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Fri, 24 Jul 2015 04:30:45 +1200
Subject: [Python-Dev] Reminder: Python 3.5 beta 4 is tagged in one week
In-Reply-To: <CAJ3HoZ2euStKc=60br0Yho+4UqauPc7kSDXiiwAdC-fKO=+VNg@mail.gmail.com>
References: <55AA2955.8030404@hastings.org>
 <CAJ3HoZ0W8n61XhtCR8jaz=nBmkqLQK7puVdgFLQQtZDY9Kq55g@mail.gmail.com>
 <55AE7C99.6020801@hastings.org>
 <CAJ3HoZ2euStKc=60br0Yho+4UqauPc7kSDXiiwAdC-fKO=+VNg@mail.gmail.com>
Message-ID: <CAJ3HoZ3_TXiHBuSK5J8XYK_ZAL0np9nZ0aSQjtReVnt=dBvWdg@mail.gmail.com>

On 22 July 2015 at 08:07, Robert Collins <robertc at robertcollins.net> wrote:
> On 22 July 2015 at 05:08, Larry Hastings <larry at hastings.org> wrote:
>>
>>
>> On 07/21/2015 06:35 PM, Robert Collins wrote:
>>
>> Cool. http://bugs.python.org/issue21750 is in a bad state right now.
>>
>> I landed a patch to fix it, which when exposed to users had some
>> defects. I'm working on a better patch now, but need to either roll
>> the prior patch completely back, or get the new one landed before the
>> next beta. I hope to have that up for review later today {fingers
>> crossed} - will that be soon enough, or should I look up how to easily
>> revert stuff out with hg?
>>
>>
>> If you want to undo it, "hg backout" is the command you want.  In general
>> it's best to not check in broken stuff.
>
> Thanks. And yes, naturally - we didn't realise it was broken. Passing
> tests != fit for purpose.

21750 is now sorted out in the cpython repo.

I have a separate question for you - issue2091 has a good patch on it,
but would you like it added to 3.5?

It makes a broken combination of file modes - rU+ - a clean error, and
tweaks the existing exception text for U + writing modes.

-Rob




-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From guido at python.org  Thu Jul 23 18:26:26 2015
From: guido at python.org (Guido van Rossum)
Date: Thu, 23 Jul 2015 18:26:26 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
Message-ID: <CAP7+vJ+dZRsWvXOHJ=DykXNK1uV1G_HJXVOjENB-tWa=2cK37g@mail.gmail.com>

Can you update the PEP with a small note about this and update the status
to Postponed? Switching to UTC is a big change indeed.

Or could you leave this issue unsolved and still make progress with the tz
database?

In any case, new discussion should then go back to python-ideas.

On Thu, Jul 23, 2015 at 6:22 PM, Lennart Regebro <regebro at gmail.com> wrote:

> On Thu, Jul 23, 2015 at 5:07 PM, Guido van Rossum <guido at python.org>
> wrote:
> > Sorry for reviving this thread, but I was cornered at EuroPython with a
> > question about the status of this PEP. It seems the proposal ran out of
> > steam and has now missed the Python 3.5 train. What happened? Is the
> problem
> > unsolvable? Or could we get this into 3.6???
>
> It turns out it's very complex to solve this when internally storing
> the time as the local time. Basically you have to normalize the time
> (ie check if daylight savings have changed) when doing arithmetic, but
> normalize is doing arithmetic, and you get infinite recursion. I've
> tried various ways to solve this but ran out of steam/brainpower.
>
> I think we should look into storing as UTC internally instead. It's a
> big change (and also needs handling pickles in a backwards compatible
> way) but I think that's the way forward.
>
> //Lennart
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150723/3a09305f/attachment.html>

From andrew.steinberg98 at yahoo.com  Thu Jul 23 21:04:33 2015
From: andrew.steinberg98 at yahoo.com (Andrew Steinberg)
Date: Thu, 23 Jul 2015 19:04:33 +0000 (UTC)
Subject: [Python-Dev] Python automatic optimization
Message-ID: <1108108683.1435566.1437678273014.JavaMail.yahoo@mail.yahoo.com>

Hello everybody,
I am using Python 2.7 as a backbone for some mathematical simulations. I recently discovered a tool called AutoFDO and I tried compiling my own Python version, but I did not manage to get it working. My question is, will sometime in the future Python include this tool?
Thank you,Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150723/d6d14196/attachment.html>

From fijall at gmail.com  Thu Jul 23 21:14:28 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 23 Jul 2015 21:14:28 +0200
Subject: [Python-Dev] Python automatic optimization
In-Reply-To: <1108108683.1435566.1437678273014.JavaMail.yahoo@mail.yahoo.com>
References: <1108108683.1435566.1437678273014.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAK5idxSAhF_pg0j9xvk8U88-VOLpK812G1xmqcUPv8uq-yyFKQ@mail.gmail.com>

As far as I can tell, the feedback directed optimizations don't give
much speedup on Python. There is a variety of tools for help: cython,
numba, pypy, numpy etc. if you care about performance of mathematical
operations.

On Thu, Jul 23, 2015 at 9:04 PM, Andrew Steinberg via Python-Dev
<python-dev at python.org> wrote:
> Hello everybody,
>
> I am using Python 2.7 as a backbone for some mathematical simulations. I
> recently discovered a tool called AutoFDO and I tried compiling my own
> Python version, but I did not manage to get it working. My question is, will
> sometime in the future Python include this tool?
>
> Thank you,
> Andrew
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

From stefan_ml at behnel.de  Thu Jul 23 22:20:49 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 23 Jul 2015 22:20:49 +0200
Subject: [Python-Dev] Python automatic optimization
In-Reply-To: <1108108683.1435566.1437678273014.JavaMail.yahoo@mail.yahoo.com>
References: <1108108683.1435566.1437678273014.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <morib2$6po$1@ger.gmane.org>

Andrew Steinberg via Python-Dev schrieb am 23.07.2015 um 21:04:
> Hello everybody, I am using Python 2.7 as a backbone for some
> mathematical simulations. I recently discovered a tool called AutoFDO
> and I tried compiling my own Python version, but I did not manage to get
> it working. My question is, will sometime in the future Python include
> this tool? Thank you,Andrew

Some Python distributions already use PGO/FDO to build the interpreter.
Ubuntu does it, for example, and potentially also other Linux distributions.

Also see this issue:

https://bugs.python.org/issue17781

Apart from that, I concur with Maciej that FDO is most likely not the
solution to your problem at hand. But that belongs on the general Python
mailing list then, not the core developers mailing list.

Stefan



From alexander.belopolsky at gmail.com  Fri Jul 24 03:28:52 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Thu, 23 Jul 2015 21:28:52 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
Message-ID: <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>

On Thu, Jul 23, 2015 at 12:22 PM, Lennart Regebro <regebro at gmail.com> wrote:

> It turns out it's very complex to solve this when internally storing
> the time as the local time. Basically you have to normalize the time
> (ie check if daylight savings have changed) when doing arithmetic, but
> normalize is doing arithmetic, and you get infinite recursion.
>

This is not true.  Tim's analysis immortalized [1] at the end of the
datetime.py file,
shows that UTC to local mapping can be unambiguously recovered from the
local to UTC rules using a simple finite algorithm.  Tim assumes [2] that
standard (non-DST)
time offset is constant throughout the history, but this requirement can be
relaxed to offset
changing no more than once in any 48 hour period (if you generously allow
timezones
from -24 to 24 hours).

Actually, it looks like I am repeating what I wrote back in April, so I'll
stop with a
reference [3] to that post.

[1]: https://hg.python.org/cpython/file/v3.5.0b1/Lib/datetime.py#l1935
[2]: https://hg.python.org/cpython/file/v3.5.0b1/Lib/datetime.py#l1948
[3]: https://mail.python.org/pipermail/python-dev/2015-April/139171.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150723/aa9e6dce/attachment.html>

From ncoghlan at gmail.com  Fri Jul 24 11:41:20 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 24 Jul 2015 19:41:20 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <87r3o0cijv.fsf@thinkpad.rath.org>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <87d1zkq3j0.fsf@vostro.rath.org>
 <CADiSq7e-b_KjxynrVMNPm6PS6=1HVD1JKg+9kOsphBnjRF+7Ag@mail.gmail.com>
 <87r3o0cijv.fsf@thinkpad.rath.org>
Message-ID: <CADiSq7cCghDmbQUVRrjZ9Dhf0+-e9uuFDFP2xKoD0kizzHfb5g@mail.gmail.com>

On 23 Jul 2015 01:36, "Nikolaus Rath" <Nikolaus at rath.org> wrote:
>
> On Jul 22 2015, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 22 July 2015 at 13:23, Nikolaus Rath <Nikolaus at rath.org> wrote:
> >> If it were up to me, I'd focus all the resources of the PSF on reducing
> >> this backlog - be that by hiring some core developers to work full-time
> >> on just the open bugtracker issues, or by financing development of
> >> better code review and commit infrastructure.
> >
> > Ah, but the PSF can't do that without infringing on python-dev's
> > autonomy - switching to my PSF Director's hat, while we'd certainly be
> > prepared to help with funding a credible grant proposal for something
> > like the Twisted technical fellowship, we wouldn't *impose* help that
> > the core developers haven't asked for.
>
> I don't understand. If I would hire a core developer myself to work on
> this (theoretically, I have no plans to do that), would that also be
> infringing python-dev's authority? If so, how is that different from me
> doing the work? If not, why is it different if the PSF decides to hire
> someone?

When somebody else pays someone to work on core development, it's quite
clear that that's a private employment matter between that developer and
whoever hires them.

By contrast, the PSF also has to consider the potential impact on
motivation levels for all the current volunteers we *don't* hire, as well
as ensuring that expectations are appropriately aligned between everyone
involved in the process. I think that's more likely to work out well for
all concerned if the process of requesting paid help in keeping the issue
tracker backlog under control is initiated *from* the core development
community, rather than being externally initiated by the PSF Board.

> >> The current situation looks like a downward spiral to me. New
> >> contributors are frustrated and leave because they feel their
> >> contribution is not welcome, and core developers get burned out by
> >> the gigantic backlog and the interaction with frustrated patch
> >> submitters - thus further reducing the available manpower.
> >
> > We actually still have a lot of paid core developer (and potential
> > core developer) time locked up in facilitating the Python 2 -> 3
> > migration, as we didn't fully appreciate the extent to which Python
> > had been adopted in the Linux ecosystem and elsewhere until folks
> > started seeking help upgrading.
>
> Interesting. Is this information available publically somewhere? I'm
> curious what exactly is being worked on.

There are a couple of links for Ubuntu & Fedora porting status at
https://wiki.python.org/moin/Python3LinuxDistroPortingStatus

Canonical & Red Hat between them have several people working on that, and
upgrades for a large proportion of the enterprise Linux world are gated
behind that effort.

The PyCon US sponsor list then provides a decent hint as to the scale of
what's needing to be ported behind corporate firewalls:
https://us.pycon.org/2015/sponsors/

It definitely qualifies as interesting times :)

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/458a6015/attachment.html>

From keeely3 at gmail.com  Fri Jul 24 12:50:08 2015
From: keeely3 at gmail.com (Mark Kelley)
Date: Fri, 24 Jul 2015 11:50:08 +0100
Subject: [Python-Dev] Building python 2.7.10 for Windows from source
Message-ID: <CAGZwN724kDq5KVaRFhiE2HUZbmqPz2b8oYrc24C2wVrjAKHFSg@mail.gmail.com>

I have been using Python for some time but it's been a decade since
I've tried to build it from source, back in the 2.4 days.  Things seem
to have gotten a little more complicated now.

I've read through the PCBuild/README file and got most stuff
compiling.  I find it a little odd that there are special instructions
for the building the release version of tcl/tk.  Is that what the
developers actually do when they cut a release, or is there some
other, top-level script that does this automatically? It just seems
odd.

Anyhow, my specific question is around the distutils wininst stubs,
provided as binaries in the release tarball.  Where can I find the
source files that those binaries are built from?

Many thanks,
Mark.

From lp_benchmark_robot at intel.com  Fri Jul 24 13:29:45 2015
From: lp_benchmark_robot at intel.com (lp_benchmark_robot)
Date: Fri, 24 Jul 2015 11:29:45 +0000
Subject: [Python-Dev] [python_default-nightly] Benchmark Results for
 3bbd0cbfe836511dd3e05fcc30ffb5bdbfe686ea
Message-ID: <C76A91C7CA77874297AEA8FB0BA10F891757E749@IRSMSX101.ger.corp.intel.com>

Hi Internals, 

This is the first message from Intel's language optimization team.
We would like to provide the Python internals developer community
with a daily service which will monitor latest committed patches
performance regressions against well known workloads.
Our aim is to run a multitude of workloads as well as real-life scenarios
which the community considers relevant. The service will send daily bulletins
containing latest measurements for daily variations and variations against
latest stable release run on our Intel-enabled servers.

The community's feedback is very important for us. For any questions,
comments or suggestions you can also contact us on our mailing list
lp at lists.01.org. You can also check our website: https://www.01.org/lp


Results for project python_default-nightly, build date 2015-07-24 09:02:02 
commit:		3bbd0cbfe836511dd3e05fcc30ffb5bdbfe686ea
revision date:	2015-07-24 07:43:44 
environment:	Haswell-EP
	cpu:	Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB
	mem:	128 GB
	os:	CentOS 7.1
	kernel:	Linux 3.10.0-229.4.2.el7.x86_64

Note: Baseline results were generated using release v3.4.3, with hash
b4cbecbc0781e89a309d03b60a1f75f8499250e6 from 2015-02-25 12:15:33+00:00

--------------------------------------------------------------------------------
               benchmark    unit            change since            change since
                                                last run                  v3.4.3
--------------------------------------------------------------------------------
:-)            django_v2     sec                1.12735%                7.47953%
:-(              pybench     sec               -0.53822%               -2.40216%
:-(             regex_v8     sec                0.61774%               -2.32010%
:-|                nbody     sec                1.75860%               -0.76206%
:-)         json_dump_v2     sec                2.13422%               -0.56930%


Our lab does a nightly source pull and build of the Python project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.  No license (express or implied, by estoppel
or otherwise) to any intellectual property rights is granted by this document.
Intel disclaims all express and implied warranties, including without
limitation, the implied warranties of merchantability, fitness for a particular
purpose, and non-infringement, as well as any warranty arising from course of
performance, course of dealing, or usage in trade.  This document may contain
information on products, services and/or processes in development. Contact your
Intel representative to obtain the latest forecast, schedule, specifications and
roadmaps.  The products and services described may contain defects or errors
known as errata which may cause deviations from published specifications.
Current characterized errata are available on request.

(C) 2015 Intel Corporation.

From lp_benchmark_robot at intel.com  Fri Jul 24 14:34:44 2015
From: lp_benchmark_robot at intel.com (lp_benchmark_robot)
Date: Fri, 24 Jul 2015 12:34:44 +0000
Subject: [Python-Dev] Benchmark Results for Python Default 2015-07-24
Message-ID: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>

Hi Internals, 

This is the first message from Intel's language optimization team.
We would like to provide the Python internals developer community
with a daily service which will monitor latest committed patches
performance regressions against well known workloads.
Our aim is to run a multitude of workloads as well as real-life scenarios
which the community considers relevant. The service will send daily bulletins
containing latest measurements for daily variations and variations against
latest stable release run on our Intel-enabled servers.

The community's feedback is very important for us. For any questions,
comments or suggestions you can also contact us on our mailing list
lp at lists.01.org. You can also check our website: https://www.01.org/lp


Results for project python_default-nightly, build date 2015-07-24 09:02:02 
commit:		3bbd0cbfe836511dd3e05fcc30ffb5bdbfe686ea
revision date:	2015-07-24 07:43:44 
environment:	Haswell-EP
	cpu:	Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB
	mem:	128 GB
	os:	CentOS 7.1
	kernel:	Linux 3.10.0-229.4.2.el7.x86_64

Note: Baseline results were generated using release v3.4.3, with hash
b4cbecbc0781e89a309d03b60a1f75f8499250e6 from 2015-02-25 12:15:33+00:00

--------------------------------------------------------------------------------
               benchmark    unit            change since            change since
                                                last run                  v3.4.3
--------------------------------------------------------------------------------
:-)            django_v2     sec                1.12735%                7.47953%
:-(              pybench     sec               -0.53822%               -2.40216%
:-(             regex_v8     sec                0.61774%               -2.32010%
:-|                nbody     sec                1.75860%               -0.76206%
:-)         json_dump_v2     sec                2.13422%               -0.56930%


Our lab does a nightly source pull and build of the Python project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.  No license (express or implied, by estoppel
or otherwise) to any intellectual property rights is granted by this document.
Intel disclaims all express and implied warranties, including without
limitation, the implied warranties of merchantability, fitness for a particular
purpose, and non-infringement, as well as any warranty arising from course of
performance, course of dealing, or usage in trade.  This document may contain
information on products, services and/or processes in development. Contact your
Intel representative to obtain the latest forecast, schedule, specifications and
roadmaps.  The products and services described may contain defects or errors
known as errata which may cause deviations from published specifications.
Current characterized errata are available on request.

(C) 2015 Intel Corporation.

From zachary.ware+pydev at gmail.com  Fri Jul 24 15:46:45 2015
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Fri, 24 Jul 2015 08:46:45 -0500
Subject: [Python-Dev] Building python 2.7.10 for Windows from source
In-Reply-To: <CAGZwN724kDq5KVaRFhiE2HUZbmqPz2b8oYrc24C2wVrjAKHFSg@mail.gmail.com>
References: <CAGZwN724kDq5KVaRFhiE2HUZbmqPz2b8oYrc24C2wVrjAKHFSg@mail.gmail.com>
Message-ID: <CAKJDb-PAHFRXqTsV-KpJrYLThjmmyQwEGz4jPdRXQispOKAcWQ@mail.gmail.com>

On Jul 24, 2015 8:30 AM, "Mark Kelley" <keeely3 at gmail.com> wrote:
>
> I have been using Python for some time but it's been a decade since
> I've tried to build it from source, back in the 2.4 days.  Things seem
> to have gotten a little more complicated now.
>
> I've read through the PCBuild/README file and got most stuff
> compiling.  I find it a little odd that there are special instructions
> for the building the release version of tcl/tk.  Is that what the
> developers actually do when they cut a release, or is there some
> other, top-level script that does this automatically? It just seems
> odd.

That used to be standard procedure, yes. However, I just recently
backported the project files from 3.5, which include project files for
building Tcl/Tk and Tix, in both Debug and Release configurations, so I may
have missed some stuff that could be removed from PCbuild/readme.txt. You
do need some extra stuff to build 2.7 with its new project files, though
(which i know is now covered in readme.txt). There hasn't been a release
with those project files yet though, they're just in the hg repo.

> Anyhow, my specific question is around the distutils wininst stubs,
> provided as binaries in the release tarball.  Where can I find the
> source files that those binaries are built from?

I believe the source for those is in PC/bdist_wininst/, or some very
similar path.

Hope this helps,
--
Zach
(On a phone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/7d52367f/attachment.html>

From storchaka at gmail.com  Fri Jul 24 15:55:25 2015
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 16:55:25 +0300
Subject: [Python-Dev] Benchmark Results for Python Default 2015-07-24
In-Reply-To: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>
References: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>
Message-ID: <55B243CD.50501@gmail.com>

On 24.07.15 15:34, lp_benchmark_robot wrote:
> Hi Internals,
>
> This is the first message from Intel's language optimization team.
> We would like to provide the Python internals developer community
> with a daily service which will monitor latest committed patches
> performance regressions against well known workloads.
> Our aim is to run a multitude of workloads as well as real-life scenarios
> which the community considers relevant. The service will send daily bulletins
> containing latest measurements for daily variations and variations against
> latest stable release run on our Intel-enabled servers.
>
> The community's feedback is very important for us. For any questions,
> comments or suggestions you can also contact us on our mailing list
> lp at lists.01.org. You can also check our website: https://www.01.org/lp

It is cool! Thank you, it whats we need.

But perhaps it would be better to post these reports on
python-checkins at python.org instead of Python-Dev list, with Reply-To set 
to python-dev at python.org.


From ncoghlan at gmail.com  Fri Jul 24 16:17:37 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 25 Jul 2015 00:17:37 +1000
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
 <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
Message-ID: <CADiSq7dD6xnXEayoJUmpDb8OJVQo2t2-H9uQAUmqPdNZbXmL1Q@mail.gmail.com>

On 23 July 2015 at 03:12, Steve Dower <Steve.Dower at microsoft.com> wrote:
> Terry Reedy wrote:
>> On 7/22/2015 3:25 AM, Ronald Oussoren wrote:
>>> Hi,
>>>
>>> Another summer with another EuroPython, which means its time again to
>>> try to revive PEP 447?
>>>
>>> I?ve just pushes a minor update to the PEP and would like to get some
>>> feedback on this, arguably fairly esoteric, PEP.
>>
>> Yeh, a bit too esoteric for most of us to review. For instance, it is not
>> obvious to me, not familiar with internal details, after reading the intro, why
>> a custom __getattribute__ is not enough and why __getdescriptor__ would be
>> needed. If Guido does not want to review this, you need to find a PEP BDFL for
>> this.
>>
>> There are two fairly obvious non-esoteric questions:
>>
>> 1. How does this impact speed (updated section needed)?
>
> Agreed, this is important. But hopefully it's just a C indirection (or better yet, a null check) for objects that don't override __getdescriptor__.
>
>> 2. Is this useful, that you can think of, for anything other than connecting to
>> Objective C?
>
> There are other object models that would benefit from this, but I don't recall that we came up with uses other than "helps proxy to objects where listing all members eagerly is expensive and/or potentially incorrect". Maybe once you list all the operating systems that are now using dynamic object-oriented APIs rather than flat APIs (Windows, iOS, Android, ... others?) this is good enough?

"better bridging to other languages and runtimes" is a good enough
rationale for me, although I also wonder if it might be useful for
making some interesting COM and dbus based API wrappers.

Ronald, could you dig up a reference to the last thread (or threads)
on this? My recollection is that we were actually pretty happy with
it, and it was just set aside through lack of time to push it through
to completion.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Fri Jul 24 16:23:13 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 25 Jul 2015 00:23:13 +1000
Subject: [Python-Dev] Benchmark Results for Python Default 2015-07-24
In-Reply-To: <55B243CD.50501@gmail.com>
References: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>
 <55B243CD.50501@gmail.com>
Message-ID: <CADiSq7dU_aL=vpshkxYv8DY0FRyyTN+rf3SsWc2PX_WPWbgGCQ@mail.gmail.com>

On 24 July 2015 at 23:55, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 24.07.15 15:34, lp_benchmark_robot wrote:
>> The community's feedback is very important for us. For any questions,
>> comments or suggestions you can also contact us on our mailing list
>> lp at lists.01.org. You can also check our website: https://www.01.org/lp
>
> It is cool! Thank you, it whats we need.

Indeed!

> But perhaps it would be better to post these reports on
> python-checkins at python.org instead of Python-Dev list, with Reply-To set to
> python-dev at python.org.

Aye, python-checkins is a better option for automated daily posts.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ronaldoussoren at mac.com  Fri Jul 24 16:43:06 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 24 Jul 2015 16:43:06 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <CADiSq7dD6xnXEayoJUmpDb8OJVQo2t2-H9uQAUmqPdNZbXmL1Q@mail.gmail.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
 <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7dD6xnXEayoJUmpDb8OJVQo2t2-H9uQAUmqPdNZbXmL1Q@mail.gmail.com>
Message-ID: <5DEAA3E4-38E8-41FE-B7D7-F49B9CD4EFC5@mac.com>


> On 24 Jul 2015, at 16:17, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 23 July 2015 at 03:12, Steve Dower <Steve.Dower at microsoft.com <mailto:Steve.Dower at microsoft.com>> wrote:
>> Terry Reedy wrote:
>>> On 7/22/2015 3:25 AM, Ronald Oussoren wrote:
>>>> Hi,
>>>> 
>>>> Another summer with another EuroPython, which means its time again to
>>>> try to revive PEP 447?
>>>> 
>>>> I?ve just pushes a minor update to the PEP and would like to get some
>>>> feedback on this, arguably fairly esoteric, PEP.
>>> 
>>> Yeh, a bit too esoteric for most of us to review. For instance, it is not
>>> obvious to me, not familiar with internal details, after reading the intro, why
>>> a custom __getattribute__ is not enough and why __getdescriptor__ would be
>>> needed. If Guido does not want to review this, you need to find a PEP BDFL for
>>> this.
>>> 
>>> There are two fairly obvious non-esoteric questions:
>>> 
>>> 1. How does this impact speed (updated section needed)?
>> 
>> Agreed, this is important. But hopefully it's just a C indirection (or better yet, a null check) for objects that don't override __getdescriptor__.
>> 
>>> 2. Is this useful, that you can think of, for anything other than connecting to
>>> Objective C?
>> 
>> There are other object models that would benefit from this, but I don't recall that we came up with uses other than "helps proxy to objects where listing all members eagerly is expensive and/or potentially incorrect". Maybe once you list all the operating systems that are now using dynamic object-oriented APIs rather than flat APIs (Windows, iOS, Android, ... others?) this is good enough?
> 
> "better bridging to other languages and runtimes" is a good enough
> rationale for me, although I also wonder if it might be useful for
> making some interesting COM and dbus based API wrappers.
> 
> Ronald, could you dig up a reference to the last thread (or threads)
> on this? My recollection is that we were actually pretty happy with
> it, and it was just set aside through lack of time to push it through
> to completion.

I?ll do some digging in my archives. From what I recall you and Steve were positive the last time around and others didn?t have much to add at the time.

FWIW Guido was positive about the idea, but would really like to see up to date benchmark results and some specific micro benchmarking to see if the change has negative performance impact.

I do have a API design question now that I?m working on this again: the PEP proposed to add a __getdescriptor__ method to the meta type, that is you?d define it as:

   class MyMeta (type):
        def __getdescriptor__(self, name): ?

   class MyType (object, metaclass=MyMeta):
       pass

This doesn?t match how other special slots are done, in particular __new__. I?d like to switch the definition to:


   class MyType:

       @classmethod
       def __getdescriptor__(cls, name): ?

I have two questions about that: (1) is this indeed a better interface and (2) should users explicitly use the classmethod decorator or would it be better to match the behaviour for __new__ by leaving that out?     Personally I do think that this is a better interface, but am not sure about requiring the decorator.

Ronald

P.S. Fighting with refcounting between sessions, forward porting of the patch for this PEP seems to have introduced a refcount problem. Nothing that cannot be fixed during the sprints though.


> 
> Regards,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org <mailto:Python-Dev at python.org>
> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com <https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/70024a31/attachment-0001.html>

From brett at python.org  Fri Jul 24 16:48:17 2015
From: brett at python.org (Brett Cannon)
Date: Fri, 24 Jul 2015 14:48:17 +0000
Subject: [Python-Dev] Benchmark Results for Python Default 2015-07-24
In-Reply-To: <CADiSq7dU_aL=vpshkxYv8DY0FRyyTN+rf3SsWc2PX_WPWbgGCQ@mail.gmail.com>
References: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>
 <55B243CD.50501@gmail.com>
 <CADiSq7dU_aL=vpshkxYv8DY0FRyyTN+rf3SsWc2PX_WPWbgGCQ@mail.gmail.com>
Message-ID: <CAP1=2W4qC8yAJ+s23sV3GCyoFDj+uwnypbk6G-q6ZPPOmv2M+A@mail.gmail.com>

Should we discuss of these are the benchmarks we want daily reports on (you
can see what the benchmark suite has at
https://hg.python.org/benchmarks/file/2979f5ce6a0c/perf.py#l2243 )? I
personally would prefer dropping pybench and replacing it with a startup
measurement.

On Fri, Jul 24, 2015, 07:23 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 24 July 2015 at 23:55, Serhiy Storchaka <storchaka at gmail.com> wrote:
> > On 24.07.15 15:34, lp_benchmark_robot wrote:
> >> The community's feedback is very important for us. For any questions,
> >> comments or suggestions you can also contact us on our mailing list
> >> lp at lists.01.org. You can also check our website: https://www.01.org/lp
> >
> > It is cool! Thank you, it whats we need.
>
> Indeed!
>
> > But perhaps it would be better to post these reports on
> > python-checkins at python.org instead of Python-Dev list, with Reply-To
> set to
> > python-dev at python.org.
>
> Aye, python-checkins is a better option for automated daily posts.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/9b6d8396/attachment.html>

From brett at python.org  Fri Jul 24 16:50:44 2015
From: brett at python.org (Brett Cannon)
Date: Fri, 24 Jul 2015 14:50:44 +0000
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <5DEAA3E4-38E8-41FE-B7D7-F49B9CD4EFC5@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
 <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7dD6xnXEayoJUmpDb8OJVQo2t2-H9uQAUmqPdNZbXmL1Q@mail.gmail.com>
 <5DEAA3E4-38E8-41FE-B7D7-F49B9CD4EFC5@mac.com>
Message-ID: <CAP1=2W5jEf3zQYgBh5HadNsk-fX4RF5tQpKEZf2GtF4yqjh34g@mail.gmail.com>

 On Fri, Jul 24, 2015, 07:43 Ronald Oussoren <ronaldoussoren at mac.com> wrote:

On 24 Jul 2015, at 16:17, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 23 July 2015 at 03:12, Steve Dower <Steve.Dower at microsoft.com> wrote:

 Terry Reedy wrote:

 On 7/22/2015 3:25 AM, Ronald Oussoren wrote:

  Hi,

Another summer with another EuroPython, which means its time again to
try to revive PEP 447?

I?ve just pushes a minor update to the PEP and would like to get some
feedback on this, arguably fairly esoteric, PEP.

   Yeh, a bit too esoteric for most of us to review. For instance, it is not
obvious to me, not familiar with internal details, after reading the intro,
why
a custom __getattribute__ is not enough and why __getdescriptor__ would be
needed. If Guido does not want to review this, you need to find a PEP BDFL
for
this.

There are two fairly obvious non-esoteric questions:

1. How does this impact speed (updated section needed)?

  Agreed, this is important. But hopefully it's just a C indirection (or
better yet, a null check) for objects that don't override __getdescriptor__.

 2. Is this useful, that you can think of, for anything other than
connecting to
Objective C?

  There are other object models that would benefit from this, but I don't
recall that we came up with uses other than "helps proxy to objects where
listing all members eagerly is expensive and/or potentially incorrect".
Maybe once you list all the operating systems that are now using dynamic
object-oriented APIs rather than flat APIs (Windows, iOS, Android, ...
others?) this is good enough?

  "better bridging to other languages and runtimes" is a good enough
rationale for me, although I also wonder if it might be useful for
making some interesting COM and dbus based API wrappers.

Ronald, could you dig up a reference to the last thread (or threads)
on this? My recollection is that we were actually pretty happy with
it, and it was just set aside through lack of time to push it through
to completion.

 I?ll do some digging in my archives. From what I recall you and Steve were
positive the last time around and others didn?t have much to add at the
time.

FWIW Guido was positive about the idea, but would really like to see up to
date benchmark results and some specific micro benchmarking to see if the
change has negative performance impact.

I do have a API design question now that I?m working on this again: the PEP
proposed to add a __getdescriptor__ method to the meta type, that is you?d
define it as:

   class MyMeta (type):

        def __getdescriptor__(self, name): ?

   class MyType (object, metaclass=MyMeta):

       pass

This doesn?t match how other special slots are done, in particular __new__.
I?d like to switch the definition to:

   class MyType:

       @classmethod

       def __getdescriptor__(cls, name): ?

I have two questions about that: (1) is this indeed a better interface and
(2) should users explicitly use the classmethod decorator or would it be
better to match the behaviour for __new__ by leaving that out?
Personally I do think that this is a better interface, but am not sure
about requiring the decorator.


Leave the decorator out like __new__, otherwise people are bound to forget
it and have a hard time debugging why their code doesn't work.

-Brett


Ronald

P.S. Fighting with refcounting between sessions, forward porting of the
patch for this PEP seems to have introduced a refcount problem. Nothing
that cannot be fixed during the sprints though.


Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev


 Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

 _______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/brett%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/4dccb8bc/attachment.html>

From Steve.Dower at microsoft.com  Fri Jul 24 15:47:36 2015
From: Steve.Dower at microsoft.com (Steve Dower)
Date: Fri, 24 Jul 2015 13:47:36 +0000
Subject: [Python-Dev] Building python 2.7.10 for Windows from source
In-Reply-To: <CAGZwN724kDq5KVaRFhiE2HUZbmqPz2b8oYrc24C2wVrjAKHFSg@mail.gmail.com>
References: <CAGZwN724kDq5KVaRFhiE2HUZbmqPz2b8oYrc24C2wVrjAKHFSg@mail.gmail.com>
Message-ID: <BLUPR0301MB16522BF00EB42BC2CA983A50F5810@BLUPR0301MB1652.namprd03.prod.outlook.com>

Those files should be under PC folder.

Building 3.5 and onwards is a much more pleasant experience, and many of those improvements have been backported for 2.7.11.

Cheers,
Steve

Top-posted from my Windows Phone
________________________________
From: Mark Kelley<mailto:keeely3 at gmail.com>
Sent: ?7/?24/?2015 6:30
To: Python-Dev at python.org<mailto:Python-Dev at python.org>
Subject: [Python-Dev] Building python 2.7.10 for Windows from source

I have been using Python for some time but it's been a decade since
I've tried to build it from source, back in the 2.4 days.  Things seem
to have gotten a little more complicated now.

I've read through the PCBuild/README file and got most stuff
compiling.  I find it a little odd that there are special instructions
for the building the release version of tcl/tk.  Is that what the
developers actually do when they cut a release, or is there some
other, top-level script that does this automatically? It just seems
odd.

Anyhow, my specific question is around the distutils wininst stubs,
provided as binaries in the release tarball.  Where can I find the
source files that those binaries are built from?

Many thanks,
Mark.
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/8d11664e/attachment.html>

From ncoghlan at gmail.com  Fri Jul 24 17:29:15 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 25 Jul 2015 01:29:15 +1000
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <CAP1=2W5jEf3zQYgBh5HadNsk-fX4RF5tQpKEZf2GtF4yqjh34g@mail.gmail.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
 <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7dD6xnXEayoJUmpDb8OJVQo2t2-H9uQAUmqPdNZbXmL1Q@mail.gmail.com>
 <5DEAA3E4-38E8-41FE-B7D7-F49B9CD4EFC5@mac.com>
 <CAP1=2W5jEf3zQYgBh5HadNsk-fX4RF5tQpKEZf2GtF4yqjh34g@mail.gmail.com>
Message-ID: <CADiSq7f+bTyeAo-dOPkqPB0Rbk4OOUmWCq1yr+UESyg60O=xWw@mail.gmail.com>

On 25 July 2015 at 00:50, Brett Cannon <brett at python.org> wrote:
> Leave the decorator out like __new__, otherwise people are bound to forget
> it and have a hard time debugging why their code doesn't work.

I'd actually advocate for keeping this as a metaclass method, rather
than making it available to any type instance. The key thing to
consider for me is "What additional power does making it a method on
the class itself grant to mixin types?"

With PEP 487, the __init_subclass__ proposal only grants mixins the
power to implicitly run additional code when new subclasses are
defined. They have no additional ability to influence the behaviour of
the specific class adding the mixin into the inheritance hierarchy.

With PEP 447, as currently written, a mixin that wants to alter how
descriptors are looked up will be able to do so implicitly as long as
there are no other custom metaclasses in the picture. As soon as there
are *two* custom metaclasses involved, you'll get an error at
definition time and have to sort out how you want the metaclass
inheritance to work and have a chance to notice if there are two
competing __getdescriptor__ implementations.

However, if __getdescriptor__ moves to being a class method on object
rather than an instance method on type, then you'll lose that
assistance from the metaclass checker - if you have two classes in
your MRO with mutually incompatible __getdescriptor__ implementations,
you're likely to be in for a world of pain as you try to figure out
the source of any related bugs.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From status at bugs.python.org  Fri Jul 24 18:08:29 2015
From: status at bugs.python.org (Python tracker)
Date: Fri, 24 Jul 2015 18:08:29 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150724160829.8400E568D5@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-07-17 - 2015-07-24)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4957 (+10)
  closed 31511 (+43)
  total  36468 (+53)

Open issues with patches: 2254 


Issues opened (34)
==================

#23591: Add IntFlags
http://bugs.python.org/issue23591  reopened by r.david.murray

#24619: async/await parser issues
http://bugs.python.org/issue24619  reopened by yselivanov

#24653: Mock.assert_has_calls([]) is surprising for users
http://bugs.python.org/issue24653  reopened by rbcollins

#24657: CGIHTTPServer module discard continuous '/' letters from param
http://bugs.python.org/issue24657  opened by takayuki

#24658: open().write() fails on 2 GB+ data (OS X)
http://bugs.python.org/issue24658  opened by lebigot

#24659: dict() built-in fails on iterators with a "keys" attribute
http://bugs.python.org/issue24659  opened by christian.barcenas

#24661: CGIHTTPServer: premature unescaping of query string
http://bugs.python.org/issue24661  opened by johnseman

#24665: CJK support for textwrap
http://bugs.python.org/issue24665  opened by fgallaire

#24666: Buffered I/O does not take file position into account when rea
http://bugs.python.org/issue24666  opened by ericpruitt

#24667: OrderedDict.popitem()/__str__() raises KeyError
http://bugs.python.org/issue24667  opened by xZise

#24668: Deprecate 00000 as a synonym for 0
http://bugs.python.org/issue24668  opened by steven.daprano

#24670: os.chdir breaks result of os.path.abspath(__file__) and os.pat
http://bugs.python.org/issue24670  opened by LordBlick

#24671: idlelib 2.7: finish converting print statements
http://bugs.python.org/issue24671  opened by terry.reedy

#24672: shutil.rmtree failes on non ascii filenames
http://bugs.python.org/issue24672  opened by Steffen Kampmann

#24673: distutils/_msvccompiler does not remove /DLL during link(CComp
http://bugs.python.org/issue24673  opened by James Salter

#24674: pyclbr not recursively showing classes in packages
http://bugs.python.org/issue24674  opened by worenklein

#24681: Put most likely test first in set_add_entry()
http://bugs.python.org/issue24681  opened by rhettinger

#24682: Add Quick Start: Communications section to devguide
http://bugs.python.org/issue24682  opened by willingc

#24683: Type confusion in json encoding
http://bugs.python.org/issue24683  opened by pkt

#24684: socket.getaddrinfo(host) doesn't ensure that host.encode() ret
http://bugs.python.org/issue24684  opened by pkt

#24685: collections.OrderedDict collaborative subclassing
http://bugs.python.org/issue24685  opened by eric.frederich

#24686: zipfile is intolerant of extra bytes
http://bugs.python.org/issue24686  opened by Devin Fisher

#24689: Add tips for effective online communication to devguide
http://bugs.python.org/issue24689  opened by willingc

#24691: out of memory in distutils.upload with large files
http://bugs.python.org/issue24691  opened by Jan.St??rtz

#24692: types.coroutines() idempotence documentation
http://bugs.python.org/issue24692  opened by seirl

#24693: zipfile: change RuntimeError to more appropriate exception typ
http://bugs.python.org/issue24693  opened by serhiy.storchaka

#24696: Don't use None as sentinel for traceback
http://bugs.python.org/issue24696  opened by Drekin

#24697: Add CoroutineReturn and CoroutineExit builtin exceptions for c
http://bugs.python.org/issue24697  opened by yselivanov

#24698: get_externals.bat script fails
http://bugs.python.org/issue24698  opened by Alex Budovski

#24699: TemporaryDirectory is cleaned up twice
http://bugs.python.org/issue24699  opened by Ilya.Kulakov

#24700: array compare is hideously slow
http://bugs.python.org/issue24700  opened by swanson

#24705: sysconfig._parse_makefile doesn't expand ${} vars appearing be
http://bugs.python.org/issue24705  opened by doko

#24706: poplib: Line too long error causes knock-on failure to retriev
http://bugs.python.org/issue24706  opened by Chris Smowton

#24707: Assertion failed in pymonotonic_new
http://bugs.python.org/issue24707  opened by berker.peksag



Most recent 15 issues with no replies (15)
==========================================

#24707: Assertion failed in pymonotonic_new
http://bugs.python.org/issue24707

#24706: poplib: Line too long error causes knock-on failure to retriev
http://bugs.python.org/issue24706

#24696: Don't use None as sentinel for traceback
http://bugs.python.org/issue24696

#24693: zipfile: change RuntimeError to more appropriate exception typ
http://bugs.python.org/issue24693

#24691: out of memory in distutils.upload with large files
http://bugs.python.org/issue24691

#24673: distutils/_msvccompiler does not remove /DLL during link(CComp
http://bugs.python.org/issue24673

#24666: Buffered I/O does not take file position into account when rea
http://bugs.python.org/issue24666

#24657: CGIHTTPServer module discard continuous '/' letters from param
http://bugs.python.org/issue24657

#24652: C-API Pure Embedding enhancement
http://bugs.python.org/issue24652

#24647: Document argparse.REMAINDER as being equal to "..."
http://bugs.python.org/issue24647

#24637: locals dictionary in PyRun_String
http://bugs.python.org/issue24637

#24626: please sync cgi.parse document
http://bugs.python.org/issue24626

#24623: Parser: broken line numbers for triple-quoted strings
http://bugs.python.org/issue24623

#24618: Invalid read in PyCode_New
http://bugs.python.org/issue24618

#24591: offer option to suppress "clean --all" output relating to none
http://bugs.python.org/issue24591



Most recent 15 issues waiting for review (15)
=============================================

#24698: get_externals.bat script fails
http://bugs.python.org/issue24698

#24693: zipfile: change RuntimeError to more appropriate exception typ
http://bugs.python.org/issue24693

#24682: Add Quick Start: Communications section to devguide
http://bugs.python.org/issue24682

#24681: Put most likely test first in set_add_entry()
http://bugs.python.org/issue24681

#24674: pyclbr not recursively showing classes in packages
http://bugs.python.org/issue24674

#24673: distutils/_msvccompiler does not remove /DLL during link(CComp
http://bugs.python.org/issue24673

#24665: CJK support for textwrap
http://bugs.python.org/issue24665

#24658: open().write() fails on 2 GB+ data (OS X)
http://bugs.python.org/issue24658

#24645: logging.handlers.QueueHandler should not lock when handling a 
http://bugs.python.org/issue24645

#24637: locals dictionary in PyRun_String
http://bugs.python.org/issue24637

#24634: Importing uuid should not try to load libc on Windows
http://bugs.python.org/issue24634

#24633: README file installed into site-packages conflicts with packag
http://bugs.python.org/issue24633

#24622: tokenize.py: missing EXACT_TOKEN_TYPES
http://bugs.python.org/issue24622

#24619: async/await parser issues
http://bugs.python.org/issue24619

#24613: array.fromstring Use After Free
http://bugs.python.org/issue24613



Top 10 most discussed issues (10)
=================================

#24681: Put most likely test first in set_add_entry()
http://bugs.python.org/issue24681  16 msgs

#21750: mock_open data is visible only once for the life of the class
http://bugs.python.org/issue21750  14 msgs

#24667: OrderedDict.popitem()/__str__() raises KeyError
http://bugs.python.org/issue24667  13 msgs

#24619: async/await parser issues
http://bugs.python.org/issue24619  12 msgs

#24658: open().write() fails on 2 GB+ data (OS X)
http://bugs.python.org/issue24658  10 msgs

#24646: Python accepts SSL certificate that should be rejected on OSX
http://bugs.python.org/issue24646   9 msgs

#24665: CJK support for textwrap
http://bugs.python.org/issue24665   8 msgs

#23883: __all__ lists are incomplete
http://bugs.python.org/issue23883   6 msgs

#24651: Mock.assert* API is in user namespace
http://bugs.python.org/issue24651   6 msgs

#24682: Add Quick Start: Communications section to devguide
http://bugs.python.org/issue24682   6 msgs



Issues closed (41)
==================

#1615: PyObject_GenericGetAttr suppresses AttributeErrors in descript
http://bugs.python.org/issue1615  closed by ethan.furman

#6549: ttk.Style -- minor issues with element_names and configure
http://bugs.python.org/issue6549  closed by python-dev

#8585: zipimporter.find_module is untested
http://bugs.python.org/issue8585  closed by rbcollins

#13124: Add "Running a Build Slave" page to the devguide
http://bugs.python.org/issue13124  closed by willingc

#13938: 2to3 fails to convert types.StringTypes appropriately
http://bugs.python.org/issue13938  closed by rbcollins

#19624: Switch constants in the errno module to IntEnum
http://bugs.python.org/issue19624  closed by ethan.furman

#19663: Not so correct error message when initializing defaultdict
http://bugs.python.org/issue19663  closed by rhettinger

#21406: Some socket constants are not enums
http://bugs.python.org/issue21406  closed by ethan.furman

#22153: Documentation of TestCase.runTest is incorrect and confusing
http://bugs.python.org/issue22153  closed by rbcollins

#23054: ConnectionError: ('Connection aborted.', BadStatusLine(""''''"
http://bugs.python.org/issue23054  closed by vadmium

#23440: Extend http.server.SimpleHTTPRequestHandler testing
http://bugs.python.org/issue23440  closed by berker.peksag

#24206: Issues with equality of inspect objects
http://bugs.python.org/issue24206  closed by serhiy.storchaka

#24300: Code Refactoring  in function nis_mapname()
http://bugs.python.org/issue24300  closed by rhettinger

#24470: ctypes incorrect handling of long int on 64bits Linux
http://bugs.python.org/issue24470  closed by Marco Clemencic

#24485: Function source inspection fails on closures
http://bugs.python.org/issue24485  closed by meador.inge

#24503: csv.writer fails when within csv.reader
http://bugs.python.org/issue24503  closed by ezzieyguywuf

#24620: Segfault with nonsensical random state
http://bugs.python.org/issue24620  closed by serhiy.storchaka

#24642: Will there be an MSI installer?
http://bugs.python.org/issue24642  closed by tritium

#24654: PEP 492 - example benchmark doesn't work (TypeError)
http://bugs.python.org/issue24654  closed by yselivanov

#24655: _ssl.c: Missing "do" for do {} while(0) idiom
http://bugs.python.org/issue24655  closed by benjamin.peterson

#24656: remove "assret" from mock error checking
http://bugs.python.org/issue24656  closed by ncoghlan

#24660: Heapq + functools.partial : TypeError: unorderable types
http://bugs.python.org/issue24660  closed by vadmium

#24662: While condition not satisfied embarrassingly
http://bugs.python.org/issue24662  closed by ezio.melotti

#24663: ast.literal_eval does not handle empty set literals
http://bugs.python.org/issue24663  closed by ezio.melotti

#24664: build failure with _Py_BEGIN_SUPPRESS_IPH undefined
http://bugs.python.org/issue24664  closed by zbysz

#24669: inspect.getsource() returns the wrong lines for coroutine func
http://bugs.python.org/issue24669  closed by yselivanov

#24675: Avoid DeprecationWarning in test_os
http://bugs.python.org/issue24675  closed by haypo

#24676: Error in pickle using cProfile
http://bugs.python.org/issue24676  closed by serhiy.storchaka

#24677: "def f(*args, ): pass" does not compile
http://bugs.python.org/issue24677  closed by vadmium

#24678: raiseExceptions typo fix in logging tests
http://bugs.python.org/issue24678  closed by serhiy.storchaka

#24679: Windows embeddable Python zip file crashes (cannot find a dll)
http://bugs.python.org/issue24679  closed by steve.dower

#24680: typo in documentation, section extending python
http://bugs.python.org/issue24680  closed by python-dev

#24687: refleak on SyntaxError in function parameter annotation
http://bugs.python.org/issue24687  closed by yselivanov

#24688: Fix ast.get_docstring to support 'async def' functions
http://bugs.python.org/issue24688  closed by yselivanov

#24690: find_executable should expand ~
http://bugs.python.org/issue24690  closed by r.david.murray

#24694: callables registered in TestCase.addCleanup should be run befo
http://bugs.python.org/issue24694  closed by yselivanov

#24695: Don't print traceback header if traceback is None in Traceback
http://bugs.python.org/issue24695  closed by berker.peksag

#24701: list.pop() removes items from multiple lists
http://bugs.python.org/issue24701  closed by r.david.murray

#24702: Uninitialised Pointer buf.outobj
http://bugs.python.org/issue24702  closed by serhiy.storchaka

#24703: Resource Leak
http://bugs.python.org/issue24703  closed by serhiy.storchaka

#24704: Dereferencing  a Null Pointer
http://bugs.python.org/issue24704  closed by serhiy.storchaka

From ronaldoussoren at mac.com  Fri Jul 24 19:55:14 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 24 Jul 2015 19:55:14 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <CADiSq7f+bTyeAo-dOPkqPB0Rbk4OOUmWCq1yr+UESyg60O=xWw@mail.gmail.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
 <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7dD6xnXEayoJUmpDb8OJVQo2t2-H9uQAUmqPdNZbXmL1Q@mail.gmail.com>
 <5DEAA3E4-38E8-41FE-B7D7-F49B9CD4EFC5@mac.com>
 <CAP1=2W5jEf3zQYgBh5HadNsk-fX4RF5tQpKEZf2GtF4yqjh34g@mail.gmail.com>
 <CADiSq7f+bTyeAo-dOPkqPB0Rbk4OOUmWCq1yr+UESyg60O=xWw@mail.gmail.com>
Message-ID: <163D9AFC-CA17-4ABE-A4AA-42DCD0AA96AF@mac.com>


> On 24 Jul 2015, at 17:29, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 25 July 2015 at 00:50, Brett Cannon <brett at python.org> wrote:
>> Leave the decorator out like __new__, otherwise people are bound to forget
>> it and have a hard time debugging why their code doesn't work.
> 
> I'd actually advocate for keeping this as a metaclass method, rather
> than making it available to any type instance. The key thing to
> consider for me is "What additional power does making it a method on
> the class itself grant to mixin types??

To be honest, I hadn?t considered mixin types yet. 

> 
> With PEP 487, the __init_subclass__ proposal only grants mixins the
> power to implicitly run additional code when new subclasses are
> defined. They have no additional ability to influence the behaviour of
> the specific class adding the mixin into the inheritance hierarchy.
> 
> With PEP 447, as currently written, a mixin that wants to alter how
> descriptors are looked up will be able to do so implicitly as long as
> there are no other custom metaclasses in the picture. As soon as there
> are *two* custom metaclasses involved, you'll get an error at
> definition time and have to sort out how you want the metaclass
> inheritance to work and have a chance to notice if there are two
> competing __getdescriptor__ implementations.
> 
> However, if __getdescriptor__ moves to being a class method on object
> rather than an instance method on type, then you'll lose that
> assistance from the metaclass checker - if you have two classes in
> your MRO with mutually incompatible __getdescriptor__ implementations,
> you're likely to be in for a world of pain as you try to figure out
> the source of any related bugs.

That?s a good point, and something that will move something that I?ve 
wanted to look into forward on my list: the difference between a
classmethod and a method on the class defined through a metaclass.

The semantics I?d like to have is that __getdescriptor__ is a local decision,
defining __getdescriptor__ for a class should only affect that class and its
subclass, and shouldn?t affect how superclasses are handled by __getattribute__.
That is something that can be done by defining __getdescriptor__ on a metaclass,
and AFAIK requires active cooperation when using a @classmethod.

It should be possible to demonstrate the differences in a pure Python
prototype. 

Ronald

> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com


From victor.stinner at gmail.com  Fri Jul 24 20:25:13 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 24 Jul 2015 20:25:13 +0200
Subject: [Python-Dev] Benchmark Results for Python Default 2015-07-24
In-Reply-To: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>
References: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>
Message-ID: <CAMpsgwZYABGTLn5Mt6sA1LftPF5MEnLZ9PosbRYVR-6h6boHSA@mail.gmail.com>

Hi,

I don't know if it's related but at EuroPython at saw a new website
which can also help:

http://pybenchmarks.org/

Victor

From jdennis at redhat.com  Sat Jul 25 01:41:47 2015
From: jdennis at redhat.com (John Dennis)
Date: Fri, 24 Jul 2015 19:41:47 -0400
Subject: [Python-Dev] PyCapsule_Import semantics, relative imports,
	module names etc.
Message-ID: <55B2CD3B.6000708@redhat.com>

While porting several existing CPython extension modules that form a 
package to be 2.7 and 3.x compatible the existing PyObject_* API was 
replaced with PyCapsule_*. This introduced some issues the existing 
CPython docs are silent on. I'd like clarification on a few issues and 
wish to raise some questions.

1. Should an extension module name as provided in PyModule_Create (Py3) 
or Py_InitModule3 (Py2) be fully package qualified or just the module 
name? I believe it's just the module name (see item 5 below) Yes/No?

2. PyCapsule_Import does not adhere to the general import semantics. The 
module name must be fully qualified, relative imports are not supported.

3. PyCapsule_Import requires the package (e.g. __init__.py) to import 
*all* of it's submodules which utilize the PyCapsule mechanism 
preventing lazy on demand loading. This is because PyCapsule_Import only 
imports the top level module (e.g. the package). From there it iterates 
over each of the module names in the module path. However the parent 
module (e.g. globals) will not contain an attribute for the submodule 
unless it's already been loaded. If the submodule has not been loaded 
into the parent PyCapsule_Import throws an error instead of trying to 
load the submodule. The only apparent solution is for the package to 
load every possible submodule whether required or not just to avoid a 
loading error. The inability to load modules on demand seems like a 
design flaw and change in semantics from the prior use of 
PyImport_ImportModule in combination with PyObject. [One of the nice 
features with normal import loading is setting the submodule name in the 
parent, the fact this step is omitted is what causes PyCapsule_Import to 
fail unless all submodules are unconditionally loaded). Shouldn't 
PyCapsule_Import utilize PyImport_ImportModule?

4. Relative imports seem much more useful for cooperating submodules in 
a package as opposed to fully qualified package names. Being able to 
import a C_API from the current package (the package I'm a member of) 
seems much more elegant and robust for cooperating modules but this 
semantic isn't supported (in fact the leading dot syntax completely 
confuses PyCapsule_Import, doc should clarify this).

5. The requirement that a module specifies it's name as unqualified when 
it is initializing but then also has to use a fully qualified package 
name for PyCapsule_New, both of which occur inside the same 
initialization function seems like an odd inconsistency (documentation 
clarification would help here). Also, depending on your point of view 
package names could be considered a deployment/packaging decision, a 
module obtains it's fully qualified name by virtue of it's position in 
the filesystem, something at compile time the module will not be aware 
of, another reason why relative imports make sense. Note the identical 
comment regarding _Py_PackageContext in  modsupport.c (Py2) and 
moduleobject.c (Py3) regarding how a module obtains it's fully qualified 
package name (see item 1).

Thanks!

-- 
John

From ischwabacher at wisc.edu  Sat Jul 25 01:06:36 2015
From: ischwabacher at wisc.edu (ISAAC J SCHWABACHER)
Date: Fri, 24 Jul 2015 23:06:36 +0000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
Message-ID: <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>

Well, I was going to stay silent, but math is something I can do without wasting anyone's time or embarrassing myself. I don't think this mail answers Lennart's concerns, but I do want to get it out there to compete with the comment in `datetime.py`. I apologize if the LaTeX density is too high; I don't trust that my e-mail client would transmit the message faithfully were I to render it myself.

I disagree with the view Tim had of time zones when he wrote that comment (and that code). It sounds like he views US/Eastern and US/Central as time zones (which they are), but thinks of the various America/Indiana zones as switching back and forth between them, rather?than being time zones in their own right. I think the right perspective is that a time zone *is* the function that its?`fromutc()` method implements, although of course we need additional information in order to actually compute (rather than merely mathematically? define) its inverse. Daylight Saving Time is a red herring, and assumptions 2 and 4 in that exposition are just wrong from this point of view. In the worst case, Asia/Riyadh's two years of solar time completely shatter these assumptions.

I'm convinced that the right viewpoint on this is to view local time and UTC time each as isomorphic to $\RR$ (i.e., effectively as UNIX timestamps, minus the oft-violated guarantee that timestamps are in UTC), and to consider the time zone as
??? \[ fromutc : \RR \to \RR. \]
(Leap seconds are a headache for this perspective, but it can still support them with well-placed epicycles.) Then our assumptions (inspired by zoneinfo) about the nature of this map are as follows:

* $fromutc$ is piecewise defined, with each piece being continuous and strictly monotonic increasing.? Let us call the set of discontinuities $\{ utc_i \in \RR | i \in \ZZ \}$, where the labels are in increasing order, and define $fromutc_i$ to be the $i$-th? piece. (The theoretical treatment doesn't suffer if there are only finitely many discontinuities, since we can place additional piece boundaries at will where no discontinuities exist; obviously, an implementation would not take this view.) 
* The piece $fromutc_i : [utc_i, utc_{i+1}) \to [local_{start, i}, local_{end, i})$ and its inverse, which we will call $fromlocal_i$, are both readily computable.? In particular, this means that $local_{start, i} = fromutc(utc_i)$ and $local_{end, i}$ is the limit of $fromutc(t)$ as $t$ approaches $utc_{i+1}$ from the left, and that these values are known.? Note that the (tzfile(5))[1] format and (zic(8)[2]) both assume that $fromutc_i$ is of the form $t \mapsto t + off_i$, where $off_i$ is a constant.  This assumption is true in practice, but is stronger than?we actually need.
* The sequences $\{ local_{start, i} | i \in \ZZ \}$ and $\{ local_{end, i} | i \in \ZZ \}$ are strictly increasing, and $local_{end, i-1} < local_{start, i+1}$ for all $i \in \ZZ$.? This final condition is enough to guarantee that the preimage of any local time under $fromutc$ contains at most two UTC times.? This assumption would be violated if, for example, some jurisdiction decided to fall back two hours by falling back one hour and then immediately falling back a second hour.? I recommend the overthrow of any such jurisdiction and its (annexation by the Netherlands)[3].

Without the third assumption, it's impossible to specify a UTC time by a (local time, time zone, DST flag) triple since there may be more than two UTC times corresponding to the same local time, and computing $fromlocal$ becomes more complicated, but the problem can still be solved by replacing the DST flag by an index into the preimage.? (Lennart, I think this third assumption is the important part of your "no changes within 48 hours of each other" assumption, which is violated by Asia/Riyadh. Is it enough?)

Once we take this view, computing $fromutc(t)$ is trivial: find $i$ with $utc_i \le t < utc_{i+1}$ by binary search (presumably optimized to an $O(1)$ average case by using a good initial guess), and compute $fromutc_i(t)$.

Computing $fromlocal(t)$ is somewhat more difficult.? The first thing to address is that, as written, $fromlocal$ is not a function; in order to make it one, we need to pass it more information.? We could define $fromlocal(t, i) = fromlocal_i(t)$, but that's too circular to be useful.? Likewise with my (silly) earlier proposal to store $(local, offset)$ pairs-- then $fromlocal(t, off) = t - off$.? What we really need is a (partial, which is better than multi-valued!) function $fromlocal : \RR \times \{True, False\} \to \RR$ that takes a local time and a DST flag and returns a UTC time.  We define $fromlocal(local, flag)$ to be the first $utc \in \RR$ such that $fromutc(utc) = local$ when $flag$ is $True$ and the last such $utc$ when $flag$ is $False$.  (Our implementation will presumably also allow $flag$ to be $None$, in which case we require $utc$ to be unique.)

To compute $fromlocal$, we'll begin with a lemma:
    If $t < utc_i$, then $fromutc(t) < local_{end, i-1}$; and likewise, if $utc_i \le t$, then $local_{start, i} \le fromutc(t)$.
If $t < utc_i$, then we must have $utc_j \le t < utc_{j+1}$ for some $j \le i-1$, so $local_{start, j} \le fromutc(t) < local_{end, j} \le local_{end, i-1}$ because $local_{end, i}$ is increasing in $i$.  The proof of the second part is similar, using the fact that $local_{start, i}$ is increasing.

Now we compute $fromlocal(t, True)$ by finding the minimal $i$ such that $t < local_{end, i}$. Then for $s < utc_i$ we must have by the lemma that $fromutc(s) < local_{end, i-1} < t$, so $s < fromlocal(t, True)$ if the latter exists. For $s \ge utc_i$ the lemma gives us $fromutc(s) \ge local_{start, i}$, so if $t < local_{start, i}$ we see that there is no $s$ with $fromutc(s) = t$, so $fromlocal(t, True)$ is undefined (which we will implement as a NonexistentTimeError). If on the other hand $t \ge local_{start, i}$, we have $t \in [local_{start, i}, local_{end, i})$, so that $fromutc(fromlocal_i(t)) = t$.  Because $fromlocal_i$ is monotonic on this interval, $fromlocal(t, True) = fromlocal_i(t)$ is minimal.  An analogous argument establishes that if $i$ is maximal with $local_{start, i} \le t$, then $fromlocal(t, False) = fromlocal_i(t)$ if $t < local_{end, i}$ and $fromlocal(t, False)$ is undefined otherwise.  All of these computations can be accomplished by searches of ordered lists and applications of $fromlocal_i$.

We can also include the option for $fromlocal(t, None)$ to require uniqueness by computing $fromlocal(t, True)$ and verifying that $t < local_{start, i+1}$ where $i$ is as in the computation of $fromlocal(t, True)$, raising an AmbiguousTimeError if this condition is not met.

Notice that the definition of time zone that I've given here does not mention Daylight Saving Time, but this isn't a problem in most cases because ambiguity happens almost exclusively at "fall back" transitions, in which the first period is DST and the second period is STD.  I argue that the rare ambiguities for which this does not hold are best resolved by divorcing our DST flag from Daylight Saving Time; that is, by defining the flag to mean "choose the first ambiguous time"; otherwise, we fail to handle jurisdictional transitions not involving DST.

With this perspective, arithmetic becomes "translate to UTC, operate, translate back", which is as it should be.  The only arithmetic that is performed outside of this framework is in the implementation of  $fromutc_i$ and $fromlocal_i$, which operate on naive timestamps. But IIUC what Lennart is complaining about is the fact that the DST flag isn't part of and can't be embedded into a local time, so it's impossible to fold the second parameter to $fromlocal$ into $t$.  Without that, a local time isn't rich enough to designate a single point in time and the whole edifice breaks.

ijs

[1]:? http://linux.die.net/man/5/tzfile
[2]: http://linux.die.net/man/8/zic
[3]: https://what-if.xkcd.com/53/

Top-posted from Microsoft Outlook Web App; may its designers be consigned for eternity to that circle of hell in which their dog food is consumed.


From: Python-Dev <python-dev-bounces+ischwabacher=wisc.edu at python.org> on behalf of Alexander Belopolsky <alexander.belopolsky at gmail.com>
Sent: Thursday, July 23, 2015 20:28
To: Lennart Regebro
Cc: Python-Dev
Subject: Re: [Python-Dev] Status on PEP-431 Timezones
? 
On Thu, Jul 23, 2015 at 12:22 PM, Lennart Regebro? <regebro at gmail.com> wrote:

It turns out it's very complex to solve this when internally storing
the time as the local time. Basically you have to normalize the time
(ie check if daylight savings have changed) when doing arithmetic, but
normalize is doing arithmetic, and you get infinite recursion.?? 
This is not true.? Tim's analysis immortalized [1] at the end of the datetime.py file,
shows that UTC to local mapping can be unambiguously recovered from the
local to UTC rules using a simple finite algorithm.? Tim assumes [2] that standard (non-DST)
time offset is constant throughout the history, but this requirement can be relaxed to offset
changing no more than once in any 48 hour period (if you generously allow timezones
from -24 to 24 hours).


Actually, it looks like I am repeating what I wrote back in April, so I'll stop with a
reference [3] to that post.


[1]:?https://hg.python.org/cpython/file/v3.5.0b1/Lib/datetime.py#l1935
[2]:?https://hg.python.org/cpython/file/v3.5.0b1/Lib/datetime.py#l1948
[3]:?https://mail.python.org/pipermail/python-dev/2015-April/139171.html?????????? 

From breamoreboy at yahoo.co.uk  Sat Jul 25 02:28:47 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Sat, 25 Jul 2015 01:28:47 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
Message-ID: <moul7v$m3k$1@ger.gmane.org>

On 25/07/2015 00:06, ISAAC J SCHWABACHER wrote:


I got to "Daylight Saving Time is a red herring," and stopped reading.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From tim.peters at gmail.com  Sat Jul 25 03:39:13 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 24 Jul 2015 20:39:13 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
Message-ID: <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>

[ISAAC J SCHWABACHER <ischwabacher at wisc.edu>]
> ...
> I disagree with the view Tim had of time zones when he wrote that comment
> (and that code). It sounds like he views US/Eastern and US/Central as time
> zones (which they are), but thinks of the various America/Indiana zones as
> switching back and forth between them, rather than being time zones in their
> own right

You can think of them anyway you like.  The point of the code was to
provide a simple & efficient way to convert from UTC to local time in
all "time zones" in known actual use at the time; the point of the
comment was to explain the limitations of the code.  Although, as
Allexander noted, the stated assumptions are stronger than needed.

> I think the right perspective is that a time zone *is* the function that its
> `fromutc()` method implements,

Fine by me ;-)

> although of course we need additional information in order to actually
> compute (rather than merely mathematically define) its inverse. Daylight Saving
> Time is a red herring,

Overstated.  DST is in fact the _only_ real complication in 99.99% of
time zones (perhaps even 99.9913% ;-) ).  As the docs say, if you have
some crazy-ass time zone in mind, fine, that's why fromutc() was
exposed (so your; crazy-ass tzinfo class can override it).

> and assumptions 2 and 4

Nitpick:  4 is a consequence of 2, not an independent assumption.

> in that exposition are just wrong from this point of view.

As above, there is no particular POV in this code:  just a specific
fromutc() implementation, comments that explain its limitations, and
an invitation in the docs to override it if it's not enough for your
case.

> In the worst case, Asia/Riyadh's two years of solar time completely shatter
> these assumptions.

Sure.  But, honestly, who cares?  Riyadh Solar Time was so
off-the-wall that even the Saudis gave up on it 25 years ago (after a
miserable 3-year experiment with it).  "Practicality beats purity".

> [eliding a more-general view of what time zones "really" are]

I'm not eliding it because I disagree with it, but because time zones
are political constructions.  "The math" we make up may or may not be
good enough to deal with all future political abominations; for
example:

> ...
> This assumption would be violated if, for example, some jurisdiction
> decided to fall back two hours by falling back one hour and then
> immediately falling back a second hour.  I recommend the overthrow
> of any such jurisdiction and its (annexation by the Netherlands)[3].

That's not objectively any more bizarre than Riyadh Solar Time.
Although, if I've lived longer than you, I may be more wary about the
creative stupidity of political schemes ;-)


> ... (Lennart, I think this third assumption is the important part of your "no
> changes within 48 hours of each other" assumption,

The "48 hours" bit came from Alexander.  I'm personally unclear on
what Lennart's problems are.

> ...
> All of these computations can be accomplished by searches of ordered lists
> and applications of $fromlocal_i$.

Do you have real-world use cases in mind beyond supporting
long-abandoned Riyadh Solar time?

> ...
> With this perspective, arithmetic becomes "translate to UTC, operate, translate
> back", which is as it should be.

There _was_ a POV in the datetime design about that:  no, that's not
how it should be.  Blame Guido ;-)  If I add, say, 24 hours to noon
today, I want to get noon tomorrow, and couldn't care less whether DST
started or stopped (or any other political adjustment was made) in
between.  For that reason, it was wholly intentional that datetime +
timedelta treats datetime as "naive".  If that's not what someone
wants, fine, but then they don't want Python's datetime arithmetic
BTW, there's no implication that they're "wrong" for wanting something
different; what would be wrong is insisting that datetime's POV is
"wrong".  Both views are valid and useful, depending on the needs of
the application.  One had to picked as the built-in behavior, and
"naive" won.

> ...
> But IIUC what Lennart is complaining about

I don't, and I wish he would be more explicit about what "the
problem(s)" is(are).

> is the fact that the DST flag isn't part of and can't be embedded into a local time,
> so it's impossible to fold the second parameter to $fromlocal$ into $t$.  Without
> that, a local time isn't rich enough to designate a single point in time and the
> whole edifice breaks.

You can blame Guido for that too ;-) , but in this case I disagree(d)
with him:  Guido was overly (IMO) annoyed by that the only apparent
purpose for a struct tm's tm_ isdst flag was to disambiguate local
times in a relative handful of cases.  His thought:  an entire bit
just for that?!  My thought:  get over it, it's one measly bit.

my-kingdom-for-bit-ingly y'rs  - tim

From alexander.belopolsky at gmail.com  Sat Jul 25 04:13:55 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 24 Jul 2015 22:13:55 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
Message-ID: <CAP7h-xZbRQXua+wP7dhat92Qr9Uk3bpAee+gtYV927W5T-O8zg@mail.gmail.com>

On Fri, Jul 24, 2015 at 9:39 PM, Tim Peters <tim.peters at gmail.com> wrote:

> > But IIUC what Lennart is complaining about
>
> I don't, and I wish he would be more explicit about what "the
> problem(s)" is(are).
>
> > is the fact that the DST flag isn't part of and can't be embedded into a
> local time,
> > so it's impossible to fold the second parameter to $fromlocal$ into
> $t$.  Without
> > that, a local time isn't rich enough to designate a single point in time
> and the
> > whole edifice breaks.
>
> You can blame Guido for that too ;-) , but in this case I disagree(d)
> with him:  Guido was overly (IMO) annoyed by that the only apparent
> purpose for a struct tm's tm_ isdst flag was to disambiguate local
> times in a relative handful of cases.  His thought:  an entire bit
> just for that?!  My thought:  get over it, it's one measly bit.


IIUC, Lennart came to (a wrong IMHO) conclusion that one bit is not enough
and you
must either keep datetime in UTC or store the UTC offset with datetime.

My position is that one bit is enough to disambiguate local time in all
sane situations,
but the name "isdst" is misleading because discontinuities in UTC to Local
function
(from now on called L(t)) may be due to causes other than DST transitions.

The math here is very simple: there are two kinds of discontinuities: you
either move the
local clock forward by a certain amount or you move it back.  Let's call
these (unimaginatively)
discontinuities of the first and second kind.

When you have a discontinuity of the first kind, you have a range of values
u for which
the equation u = L(t) has no solution for t.  However, if we linearly
extrapolate L(t) from  before
the discontinuity forward, we get a linear function Lb(t) and we can solve
u = Lb(t) for any
value of u.  The problem, however is that we can also extend L(t) linearly
from the time
after the discontinuity to all times and get another function La(t) which
will also allow you to
solve equation u = La(t) for all times.  Without user input, there is no
way to tell which solution
she expects.  This is the 1-bit of information that we need.

The situation with the discontinuity of the second kind is similar, but
even simpler.  Here,
u = L(t) has two solutions and we need 1-bit of information to disambiguate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/bad93045/attachment-0001.html>

From regebro at gmail.com  Sat Jul 25 06:46:53 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 25 Jul 2015 06:46:53 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
Message-ID: <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>

And I would want to remind everyone again that this is not a question
of the problem being impossible. It's just really complex to get right
in all cases, and that always having the UTC timestamp around gets rid
of most of that complexity.

On Sat, Jul 25, 2015 at 3:39 AM, Tim Peters <tim.peters at gmail.com> wrote:
> [ISAAC J SCHWABACHER <ischwabacher at wisc.edu>]
>> ...
>> I disagree with the view Tim had of time zones when he wrote that comment
>> (and that code). It sounds like he views US/Eastern and US/Central as time
>> zones (which they are), but thinks of the various America/Indiana zones as
>> switching back and forth between them, rather than being time zones in their
>> own right
>
> You can think of them anyway you like.  The point of the code was to
> provide a simple & efficient way to convert from UTC to local time in
> all "time zones" in known actual use at the time; the point of the
> comment was to explain the limitations of the code.  Although, as
> Allexander noted, the stated assumptions are stronger than needed.
>
>> I think the right perspective is that a time zone *is* the function that its
>> `fromutc()` method implements,
>
> Fine by me ;-)
>
>> although of course we need additional information in order to actually
>> compute (rather than merely mathematically define) its inverse. Daylight Saving
>> Time is a red herring,
>
> Overstated.  DST is in fact the _only_ real complication in 99.99% of
> time zones (perhaps even 99.9913% ;-) ).  As the docs say, if you have
> some crazy-ass time zone in mind, fine, that's why fromutc() was
> exposed (so your; crazy-ass tzinfo class can override it).
>
>> and assumptions 2 and 4
>
> Nitpick:  4 is a consequence of 2, not an independent assumption.
>
>> in that exposition are just wrong from this point of view.
>
> As above, there is no particular POV in this code:  just a specific
> fromutc() implementation, comments that explain its limitations, and
> an invitation in the docs to override it if it's not enough for your
> case.
>
>> In the worst case, Asia/Riyadh's two years of solar time completely shatter
>> these assumptions.
>
> Sure.  But, honestly, who cares?  Riyadh Solar Time was so
> off-the-wall that even the Saudis gave up on it 25 years ago (after a
> miserable 3-year experiment with it).  "Practicality beats purity".
>
>> [eliding a more-general view of what time zones "really" are]
>
> I'm not eliding it because I disagree with it, but because time zones
> are political constructions.  "The math" we make up may or may not be
> good enough to deal with all future political abominations; for
> example:
>
>> ...
>> This assumption would be violated if, for example, some jurisdiction
>> decided to fall back two hours by falling back one hour and then
>> immediately falling back a second hour.  I recommend the overthrow
>> of any such jurisdiction and its (annexation by the Netherlands)[3].
>
> That's not objectively any more bizarre than Riyadh Solar Time.
> Although, if I've lived longer than you, I may be more wary about the
> creative stupidity of political schemes ;-)
>
>
>> ... (Lennart, I think this third assumption is the important part of your "no
>> changes within 48 hours of each other" assumption,
>
> The "48 hours" bit came from Alexander.  I'm personally unclear on
> what Lennart's problems are.
>
>> ...
>> All of these computations can be accomplished by searches of ordered lists
>> and applications of $fromlocal_i$.
>
> Do you have real-world use cases in mind beyond supporting
> long-abandoned Riyadh Solar time?
>
>> ...
>> With this perspective, arithmetic becomes "translate to UTC, operate, translate
>> back", which is as it should be.
>
> There _was_ a POV in the datetime design about that:  no, that's not
> how it should be.  Blame Guido ;-)  If I add, say, 24 hours to noon
> today, I want to get noon tomorrow, and couldn't care less whether DST
> started or stopped (or any other political adjustment was made) in
> between.  For that reason, it was wholly intentional that datetime +
> timedelta treats datetime as "naive".  If that's not what someone
> wants, fine, but then they don't want Python's datetime arithmetic
> BTW, there's no implication that they're "wrong" for wanting something
> different; what would be wrong is insisting that datetime's POV is
> "wrong".  Both views are valid and useful, depending on the needs of
> the application.  One had to picked as the built-in behavior, and
> "naive" won.
>
>> ...
>> But IIUC what Lennart is complaining about
>
> I don't, and I wish he would be more explicit about what "the
> problem(s)" is(are).
>
>> is the fact that the DST flag isn't part of and can't be embedded into a local time,
>> so it's impossible to fold the second parameter to $fromlocal$ into $t$.  Without
>> that, a local time isn't rich enough to designate a single point in time and the
>> whole edifice breaks.
>
> You can blame Guido for that too ;-) , but in this case I disagree(d)
> with him:  Guido was overly (IMO) annoyed by that the only apparent
> purpose for a struct tm's tm_ isdst flag was to disambiguate local
> times in a relative handful of cases.  His thought:  an entire bit
> just for that?!  My thought:  get over it, it's one measly bit.
>
> my-kingdom-for-bit-ingly y'rs  - tim

From tim.peters at gmail.com  Sat Jul 25 07:07:42 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 25 Jul 2015 00:07:42 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
Message-ID: <CAExdVNnLf5Ae=ZLpp8GMVCZ7ycXj05AHw+wFHuUoCpLjCxoGZg@mail.gmail.com>

[Tim]
> Sure.  But, honestly, who cares?  Riyadh Solar Time was so
> off-the-wall that even the Saudis gave up on it 25 years ago (after a
> miserable 3-year experiment with it).  "Practicality beats purity".

Heh.  It's even sillier than that - the Saudis never used "Riyadh
Solar Time", and it's been removed from release 2015e of the tz
database:

    https://www.ietf.org/timezones/data/NEWS
    Release 2015e - 2015-06-13 10:56:02 -0700
    ...
    The files solar87, solar88, and solar89 are no longer distributed.
    They were a negative experiment - that is, a demonstration that
    tz data can represent solar time only with some difficulty and error.
    Their presence in the distribution caused confusion, as Riyadh
    civil time was generally not solar time in those years.

Looking back, Paul Eggert explained more in 2013, but it took this
long for the patch to land:

    http://comments.gmane.org/gmane.comp.time.tz/7717
    > did Saudi Arabia really use this as clock time?

    Not as far as I know, for civil time.  There was some use
    for religious purposes but it didn't use the approximation
    in those files.

    These files probably cause more confusion than they're worth,
    so I'll propose a couple of patches to remove them, in two followup
    emails.  I haven't pushed these patches to the experimental
    github version.

The position of the sun is vital to establishing prayer times in
Islam, but that's got little to do with civil time in Islamic
countries.  And Olson didn't take his "Riyadh Solar Time" rules from
the Saudis, he made up the times himself:  "Times were computed using
formulas in the U.S. Naval Observatory's Almanac for Computers
1987[89]".  The formulas only produced approximations, and then
rounded to 5-second boundaries because the tz data format didn't have
enough bits.

So, as a motivating example, it's hard to get less compelling:  Riyadh
Solar is a wholly artificial "time zone" made up by a time zone wonk
to demonstrate some limitations of the tz database he maintained.
Although I expect he could have done so just as effectively by writing
a brief note about it ;-)

From tim.peters at gmail.com  Sat Jul 25 07:12:16 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 25 Jul 2015 00:12:16 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
Message-ID: <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>

[Lennart Regebro <regebro at gmail.com>]
> And I would want to remind everyone again that this is not a question
> of the problem being impossible. It's just really complex to get right
> in all cases, and that always having the UTC timestamp around gets rid
> of most of that complexity.

Could you please be explicit about what "the problem" is?  Everyone
here is guessing at what you think "the problem" is.

From tim.peters at gmail.com  Sat Jul 25 07:14:13 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 25 Jul 2015 00:14:13 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <SN1PR06MB1824EEC7FA270B03E344EDF5B6800@SN1PR06MB1824.namprd06.prod.outlook.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAExdVNnLf5Ae=ZLpp8GMVCZ7ycXj05AHw+wFHuUoCpLjCxoGZg@mail.gmail.com>
 <SN1PR06MB1824EEC7FA270B03E344EDF5B6800@SN1PR06MB1824.namprd06.prod.outlook.com>
Message-ID: <CAExdVNkUZt8Qju_63GLck0qY_R7Xpakg_+PcOMWBLe747U3R+g@mail.gmail.com>

[Tim]
>> The formulas only produced approximations, and then
>> rounded to 5-second boundaries because the tz data format didn't have
>> enough bits.

[ISAAC J SCHWABACHER <ischwabacher at wisc.edu>]
> Little known fact: if you have a sub-minute-resolution UTC offset when a
> leap second hits, it rips open a hole in the space-time continuum and
> you find yourself in New Netherlands.

Tell me about it!  Last time that happened I had to grow stinking
tulips for 3 years to get enough money to sail back home.  I'll never
use a sub-minute-resolution UTC offset again ;-)

From ischwabacher at wisc.edu  Sat Jul 25 07:21:40 2015
From: ischwabacher at wisc.edu (ISAAC J SCHWABACHER)
Date: Sat, 25 Jul 2015 05:21:40 +0000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkUZt8Qju_63GLck0qY_R7Xpakg_+PcOMWBLe747U3R+g@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAExdVNnLf5Ae=ZLpp8GMVCZ7ycXj05AHw+wFHuUoCpLjCxoGZg@mail.gmail.com>
 <SN1PR06MB1824EEC7FA270B03E344EDF5B6800@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkUZt8Qju_63GLck0qY_R7Xpakg_+PcOMWBLe747U3R+g@mail.gmail.com>
Message-ID: <SN1PR06MB1824F4A7DDE2C4AEFE7C2869B6800@SN1PR06MB1824.namprd06.prod.outlook.com>

> From: Tim Peters <tim.peters at gmail.com>
> Sent: Saturday, July 25, 2015 00:14
> To: ISAAC J SCHWABACHER
> Cc: Alexander Belopolsky; Lennart Regebro; Python-Dev
> Subject: Re: [Python-Dev] Status on PEP-431 Timezones

> [Tim]
> >> The formulas only produced approximations, and then
> >> rounded to 5-second boundaries because the tz data format didn't have
> >> enough bits.

> [ISAAC J SCHWABACHER <ischwabacher at wisc.edu>]
> > Little known fact: if you have a sub-minute-resolution UTC offset when a
> > leap second hits, it rips open a hole in the space-time continuum and
> > you find yourself in New Netherlands.

> Tell me about it!  Last time that happened I had to grow stinking
> tulips for 3 years to get enough money to sail back home.  I'll never
> use a sub-minute-resolution UTC offset again ;-)

I meant this one: https://what-if.xkcd.com/54/ :)

ijs

From ischwabacher at wisc.edu  Sat Jul 25 07:12:04 2015
From: ischwabacher at wisc.edu (ISAAC J SCHWABACHER)
Date: Sat, 25 Jul 2015 05:12:04 +0000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNnLf5Ae=ZLpp8GMVCZ7ycXj05AHw+wFHuUoCpLjCxoGZg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAExdVNnLf5Ae=ZLpp8GMVCZ7ycXj05AHw+wFHuUoCpLjCxoGZg@mail.gmail.com>
Message-ID: <SN1PR06MB1824EEC7FA270B03E344EDF5B6800@SN1PR06MB1824.namprd06.prod.outlook.com>

> The formulas only produced approximations, and then
> rounded to 5-second boundaries because the tz data format didn't have
> enough bits.

Little known fact: if you have a sub-minute-resolution UTC offset when a leap second hits, it rips open a hole in the space-time continuum and you find yourself in New Netherlands.

ijs

________________________________________
From: Tim Peters <tim.peters at gmail.com>
Sent: Saturday, July 25, 2015 00:07
To: ISAAC J SCHWABACHER
Cc: Alexander Belopolsky; Lennart Regebro; Python-Dev
Subject: Re: [Python-Dev] Status on PEP-431 Timezones

[Tim]
> Sure.  But, honestly, who cares?  Riyadh Solar Time was so
> off-the-wall that even the Saudis gave up on it 25 years ago (after a
> miserable 3-year experiment with it).  "Practicality beats purity".

Heh.  It's even sillier than that - the Saudis never used "Riyadh
Solar Time", and it's been removed from release 2015e of the tz
database:

    https://www.ietf.org/timezones/data/NEWS
    Release 2015e - 2015-06-13 10:56:02 -0700
    ...
    The files solar87, solar88, and solar89 are no longer distributed.
    They were a negative experiment - that is, a demonstration that
    tz data can represent solar time only with some difficulty and error.
    Their presence in the distribution caused confusion, as Riyadh
    civil time was generally not solar time in those years.

Looking back, Paul Eggert explained more in 2013, but it took this
long for the patch to land:

    http://comments.gmane.org/gmane.comp.time.tz/7717
    > did Saudi Arabia really use this as clock time?

    Not as far as I know, for civil time.  There was some use
    for religious purposes but it didn't use the approximation
    in those files.

    These files probably cause more confusion than they're worth,
    so I'll propose a couple of patches to remove them, in two followup
    emails.  I haven't pushed these patches to the experimental
    github version.

The position of the sun is vital to establishing prayer times in
Islam, but that's got little to do with civil time in Islamic
countries.  And Olson didn't take his "Riyadh Solar Time" rules from
the Saudis, he made up the times himself:  "Times were computed using
formulas in the U.S. Naval Observatory's Almanac for Computers
1987[89]".  The formulas only produced approximations, and then
rounded to 5-second boundaries because the tz data format didn't have
enough bits.

So, as a motivating example, it's hard to get less compelling:  Riyadh
Solar is a wholly artificial "time zone" made up by a time zone wonk
to demonstrate some limitations of the tz database he maintained.
Although I expect he could have done so just as effectively by writing
a brief note about it ;-)

From regebro at gmail.com  Sat Jul 25 08:40:53 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 25 Jul 2015 08:40:53 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
Message-ID: <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>

On Sat, Jul 25, 2015 at 7:12 AM, Tim Peters <tim.peters at gmail.com> wrote:
> [Lennart Regebro <regebro at gmail.com>]
>> And I would want to remind everyone again that this is not a question
>> of the problem being impossible. It's just really complex to get right
>> in all cases, and that always having the UTC timestamp around gets rid
>> of most of that complexity.
>
> Could you please be explicit about what "the problem" is?  Everyone
> here is guessing at what you think "the problem" is.

The problem is that it is exceedingly complicated to get all the
calculations back and forth between local time and UTC to be correct
at all times and for all cases. It really doesn't get more specific
than that. I don't remember which exact problem it was that made me
decide that this was not the correct solution and that we should use
UTC internally, but I don't think that matters, because I'm also sure
that it was not the last case, as I was far from near the end in
adding testcases.

Once again I'm sure it's not impossible to somehow come up with an
implementation and an API that can do this based on local time, but
once again I am of the opinion that it is the wrong thing to do. We
should switch to using UTC internally, because that will make
everything so much simpler.

I am in no way against other people implementing this PEP, but I think
you will end up with very complex code that will be hard to maintain.

There really is a reason every other date time implementation I know
of uses UTC internally, and there really is a reason why everyone
always recommends storing date times in UTC with the time zone or
offset separately.

//Lennart

From ronaldoussoren at mac.com  Sat Jul 25 13:26:37 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sat, 25 Jul 2015 13:26:37 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <163D9AFC-CA17-4ABE-A4AA-42DCD0AA96AF@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <mooero$hds$1@ger.gmane.org>
 <BLUPR0301MB16522088CC3A9FAF47631723F5830@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7dD6xnXEayoJUmpDb8OJVQo2t2-H9uQAUmqPdNZbXmL1Q@mail.gmail.com>
 <5DEAA3E4-38E8-41FE-B7D7-F49B9CD4EFC5@mac.com>
 <CAP1=2W5jEf3zQYgBh5HadNsk-fX4RF5tQpKEZf2GtF4yqjh34g@mail.gmail.com>
 <CADiSq7f+bTyeAo-dOPkqPB0Rbk4OOUmWCq1yr+UESyg60O=xWw@mail.gmail.com>
 <163D9AFC-CA17-4ABE-A4AA-42DCD0AA96AF@mac.com>
Message-ID: <0F337A04-5827-4906-84B4-8E9439C8F750@mac.com>

I?ve pushed a minor update to the PEP to the repository. The benchmark results are still out of date, I need want to run those on an idle machine to get reliable results.

The PEP has one significant change w.r.t. the previous version: it now requires the use of a new type flag to enable the usage of the new slot in C code. This is due to concerns that loading old extensions might crash the interpreter otherwise.

References to earlier discussions (also added to the PEP):

* http://marc.info/?l=python-dev&m=137510220928964&w=2
* https://mail.python.org/pipermail/python-ideas/2014-July/028420.html
* https://mail.python.org/pipermail/python-dev/2013-July/127321.html

And finally, I?ve updated the implementation in issue 18181. The implementation passes the test suite with the current trunk and is good enough to play around with.  There is still an important issue though: I?ve done some micro benchmarking and those indicate that the method_cache mechanism in typeobject.c doesn?t work with my changes and that has a clear performance impact and must be fixed. That shouldn?t be too hard to fix, it?s probably just a botched check before the blocks of code that use and update the cache.

Ronald

> On 24 Jul 2015, at 19:55, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> 
>> 
>> On 24 Jul 2015, at 17:29, Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> wrote:
>> 
>> On 25 July 2015 at 00:50, Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
>>> Leave the decorator out like __new__, otherwise people are bound to forget
>>> it and have a hard time debugging why their code doesn't work.
>> 
>> I'd actually advocate for keeping this as a metaclass method, rather
>> than making it available to any type instance. The key thing to
>> consider for me is "What additional power does making it a method on
>> the class itself grant to mixin types??
> 
> To be honest, I hadn?t considered mixin types yet. 
> 
>> 
>> With PEP 487, the __init_subclass__ proposal only grants mixins the
>> power to implicitly run additional code when new subclasses are
>> defined. They have no additional ability to influence the behaviour of
>> the specific class adding the mixin into the inheritance hierarchy.
>> 
>> With PEP 447, as currently written, a mixin that wants to alter how
>> descriptors are looked up will be able to do so implicitly as long as
>> there are no other custom metaclasses in the picture. As soon as there
>> are *two* custom metaclasses involved, you'll get an error at
>> definition time and have to sort out how you want the metaclass
>> inheritance to work and have a chance to notice if there are two
>> competing __getdescriptor__ implementations.
>> 
>> However, if __getdescriptor__ moves to being a class method on object
>> rather than an instance method on type, then you'll lose that
>> assistance from the metaclass checker - if you have two classes in
>> your MRO with mutually incompatible __getdescriptor__ implementations,
>> you're likely to be in for a world of pain as you try to figure out
>> the source of any related bugs.
> 
> That?s a good point, and something that will move something that I?ve 
> wanted to look into forward on my list: the difference between a
> classmethod and a method on the class defined through a metaclass.
> 
> The semantics I?d like to have is that __getdescriptor__ is a local decision,
> defining __getdescriptor__ for a class should only affect that class and its
> subclass, and shouldn?t affect how superclasses are handled by __getattribute__.
> That is something that can be done by defining __getdescriptor__ on a metaclass,
> and AFAIK requires active cooperation when using a @classmethod.
> 
> It should be possible to demonstrate the differences in a pure Python
> prototype. 
> 
> Ronald
> 
>> 
>> Cheers,
>> Nick.
>> 
>> -- 
>> Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org <mailto:Python-Dev at python.org>
>> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev>
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com <https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150725/3e24c889/attachment.html>

From alexander.belopolsky at gmail.com  Sat Jul 25 16:15:29 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sat, 25 Jul 2015 10:15:29 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
Message-ID: <CAP7h-xakY5Qz2sQHxMv+eUFyDPcwZFM0DTwtqnqbYh3iGQCQ2w@mail.gmail.com>

On Sat, Jul 25, 2015 at 2:40 AM, Lennart Regebro <regebro at gmail.com> wrote:

> There really is a reason every other date time implementation I know
> of uses UTC internally, and there really is a reason why everyone
> always recommends storing date times in UTC with the time zone or
> offset separately.
>

Current datetime design does not prevent your application from storing
date-times
in UTC.  You can store them in naive datetime instances, but the
recommended
approach is to use datetime instances with tzinfo=timezone.utc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150725/e10890f1/attachment.html>

From mark at hotpy.org  Sat Jul 25 17:39:34 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sat, 25 Jul 2015 16:39:34 +0100 (BST)
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
Message-ID: <128643133.270510.1437838774416.JavaMail.open-xchange@oxbsltgw13.schlund.de>

Hi,

On 22/07/15 09:25, Ronald Oussoren wrote:> Hi,
> 
> Another summer with another EuroPython, which means its time again to 
> try to revive PEP 447?
> 

IMO, there are two main issues with the PEP and implementation.

1. The implementation as outlined in the PEP is infinitely recursive, since the
lookup of "__getdescriptor__" on type must necessarily call
type.__getdescriptor__.
The implementation (in C) special cases classes that inherit "__getdescriptor__"
from type. This special casing should be mentioned in the PEP.

2. The actual implementation in C does not account for the case where the class
of a metaclass implements __getdescriptor__ and that method returns a value when
called with "__getdescriptor__" as the argument.



Why was "__getattribute_super__" rejected as an alternative? No reason is given.

"__getattribute_super__" has none of the problems listed above.
Making super(t, obj) delegate to t.__super__(obj) seems consistent with other
builtin method/classes and doesn't add corner cases to the already complex
implementation of PyType_Lookup().

Cheers,
Mark

From ryan at ryanhiebert.com  Sat Jul 25 18:00:34 2015
From: ryan at ryanhiebert.com (Ryan Hiebert)
Date: Sat, 25 Jul 2015 11:00:34 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAP7h-xakY5Qz2sQHxMv+eUFyDPcwZFM0DTwtqnqbYh3iGQCQ2w@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAP7h-xakY5Qz2sQHxMv+eUFyDPcwZFM0DTwtqnqbYh3iGQCQ2w@mail.gmail.com>
Message-ID: <63034541-98CC-421D-9101-73503D88D4D3@ryanhiebert.com>


> On Jul 25, 2015, at 09:15, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 
> 
>> On Sat, Jul 25, 2015 at 2:40 AM, Lennart Regebro <regebro at gmail.com> wrote:
>> There really is a reason every other date time implementation I know
>> of uses UTC internally, and there really is a reason why everyone
>> always recommends storing date times in UTC with the time zone or
>> offset separately.
> 
> Current datetime design does not prevent your application from storing date-times
> in UTC.  You can store them in naive datetime instances, but the recommended 
> approach is to use datetime instances with tzinfo=timezone.utc.

Yes, and now he wants to do the same thing for the internals of the datetime module, for the same reasons that it's the best thing most everywhere else. It's just going to take some significant effort to make that happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150725/703b2a2d/attachment.html>

From robertc at robertcollins.net  Sat Jul 25 21:28:56 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Sun, 26 Jul 2015 07:28:56 +1200
Subject: [Python-Dev] Burning down the backlog.
Message-ID: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>

On 21 July 2015 at 19:40, Nick Coghlan <ncoghlan at gmail.com> wrote:

> All of this is why the chart that I believe should be worrying people
> is the topmost one on this page:
> http://bugs.python.org/issue?@template=stats
>
> Both the number of open issues and the number of open issues with
> patches are steadily trending upwards. That means the bottleneck in
> the current process *isn't* getting patches written in the first
> place, it's getting them up to the appropriate standards and applied.
> Yet the answer to the problem isn't a simple "recruit more core
> developers", as the existing core developers are *also* the bottleneck
> in the review and mentoring process for *new* core developers.

Those charts doesn't show patches in 'commit-review' -
http://bugs.python.org/issue?%40columns=title&%40columns=id&stage=5&%40columns=activity&%40sort=activity&status=1&%40columns=status&%40pagesize=50&%40startwith=0&%40sortdir=on&%40action=search

There are only 45 of those patches.

AIUI - and I'm very new to core here - anyone in triagers can get
patches up to commit-review status.

I think we should set a goal to keep inventory low here - e.g. review
and either bounce back to patch review, or commit, in less than a
month. Now - a month isn't super low, but we have lots of stuff
greater than a month.

For my part, I'm going to pick up more or less one thing a day and
review it, but I think it would be great if other committers were to
also to do this: if we had 5 of us doing 1 a day, I think we'd burn
down this 45 patch backlog rapidly without significant individual
cost. At which point, we can fairly say to folk doing triage that
we're ready for patches :)

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From ischwabacher at wisc.edu  Sat Jul 25 20:44:33 2015
From: ischwabacher at wisc.edu (ISAAC J SCHWABACHER)
Date: Sat, 25 Jul 2015 18:44:33 +0000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
Message-ID: <SN1PR06MB182477F6100A6B97CABBBF20B6800@SN1PR06MB1824.namprd06.prod.outlook.com>

> From: Tim Peters <tim.peters at gmail.com>
> Sent: Friday, July 24, 2015 20:39
> To: ISAAC J SCHWABACHER
> Cc: Alexander Belopolsky; Lennart Regebro; Python-Dev
> Subject: Re: [Python-Dev] Status on PEP-431 Timezones
>
> [ISAAC J SCHWABACHER <ischwabacher at wisc.edu>]
> > ...
> > I disagree with the view Tim had of time zones when he wrote that comment
> > (and that code). It sounds like he views US/Eastern and US/Central as time
> > zones (which they are), but thinks of the various America/Indiana zones as
> > switching back and forth between them, rather than being time zones in their
> > own right
>
> You can think of them anyway you like.  The point of the code was to
> provide a simple & efficient way to convert from UTC to local time in
> all "time zones" in known actual use at the time; the point of the
> comment was to explain the limitations of the code.  Although, as
> Allexander noted, the stated assumptions are stronger than needed.
>
> > I think the right perspective is that a time zone *is* the function that its
> > `fromutc()` method implements,
>
> Fine by me ;-)

My issue is that you're computing `fromutc()`, which is a function, in terms of `dst()` and `utcoffset()`, which aren't. I think this is backwards; `dst()` and `utcoffset()` should be computed from `fromutc()` plus some additional information that has to be present anyway in order to implement `fromutc()`. With the extra bit, `dst()` and `utcoffset()` become partial functions, which makes it *possible* to get the right answer in all cases, but it's still simpler to start with the total function and work from there.

> > although of course we need additional information in order to actually
> > compute (rather than merely mathematically define) its inverse. Daylight Saving
> > Time is a red herring,
>
> Overstated.  DST is in fact the _only_ real complication in 99.99% of
> time zones (perhaps even 99.9913% ;-) ).  As the docs say, if you have
> some crazy-ass time zone in mind, fine, that's why fromutc() was
> exposed (so your; crazy-ass tzinfo class can override it).

I stand by what I meant by this, even if I did a bad job of expressing the point. Assuming that all time zone discontinuities are due to DST changes breaks many time zones (really almost all of the Olson time zones, though only for a vanishingly small fraction of datetimes), but that's not the point I was making. The point is that it doesn't buy us anything. Though this is probably obscured by all the markup, the more general algorithm I gave is also simpler than the one in the comment in datetime.py, and the reason for that is that it solves an easier problem, but one that serves our practical purposes just as well.

> > and assumptions 2 and 4
>
> Nitpick:  4 is a consequence of 2, not an independent assumption.
>
> > in that exposition are just wrong from this point of view.
>
> As above, there is no particular POV in this code:  just a specific
> fromutc() implementation, comments that explain its limitations, and
> an invitation in the docs to override it if it's not enough for your
> case.

I went too far in inferring your viewpoint from your code.  I don't find fault with the explanation on its own terms. But adding zoneinfo to the stdlib, as PEP 431 proposes to do, requires making weaker assumptions and asking a different question than the one answered in the comment. 

> > In the worst case, Asia/Riyadh's two years of solar time completely shatter
> > these assumptions.
>
> Sure.  But, honestly, who cares?  Riyadh Solar Time was so
> off-the-wall that even the Saudis gave up on it 25 years ago (after a
> miserable 3-year experiment with it).  "Practicality beats purity".

As a mathematician at heart, I have a deep and abiding conviction, which I expect nobody else to share, that purity begets practicality in the long run. At least if you've found the right abstraction.

> > [eliding a more-general view of what time zones "really" are]

[note for people just joining this conversation: I think the information in the elision is critical to understanding what I'm talking about]

> I'm not eliding it because I disagree with it, but because time zones
> are political constructions.  "The math" we make up may or may not be
> good enough to deal with all future political abominations; for
> example:
>
> > ...
> > This assumption would be violated if, for example, some jurisdiction
> > decided to fall back two hours by falling back one hour and then
> > immediately falling back a second hour.  I recommend the overthrow
> > of any such jurisdiction and its (annexation by the Netherlands)[3].
>
> That's not objectively any more bizarre than Riyadh Solar Time.
> Although, if I've lived longer than you, I may be more wary about the
> creative stupidity of political schemes ;-)

It's not, you have, and you probably are. :)

But these assumptions didn't come out of nowhere. They're the assumptions behind zoneinfo, weakened as much as possible without making the problem any harder. It's hard to weaken them further and still have anything to work with. (See? I *do* still have a sense of practicality!)

Nobody wants to read me discussing this at great length, but I'll say that I don't expect any legislative body to have the collective mathematical sophistication necessary to violate piecewise continuity or computability. If you really want to troll me, I invite you to take over a government and institute a time zone based on the (Weierstrass function)[1].

> > ... (Lennart, I think this third assumption is the important part of your "no
> > changes within 48 hours of each other" assumption,
>
> The "48 hours" bit came from Alexander.  I'm personally unclear on
> what Lennart's problems are.

Whoops!

> > ...
> > All of these computations can be accomplished by searches of ordered lists
> > and applications of $fromlocal_i$.
>
> Do you have real-world use cases in mind beyond supporting
> long-abandoned Riyadh Solar time?

Parts of five US states (Alaska, North Dakota, Indiana, Kentucky and Michigan) have changed their standard time since 1970. But I'll admit that mentioning Riyadh was a low blow.

> > ...
> > With this perspective, arithmetic becomes "translate to UTC, operate, translate
> > back", which is as it should be.
>
> There _was_ a POV in the datetime design about that:  no, that's not
> how it should be.  Blame Guido ;-)  If I add, say, 24 hours to noon
> today, I want to get noon tomorrow, and couldn't care less whether DST
> started or stopped (or any other political adjustment was made) in
> between.  For that reason, it was wholly intentional that datetime +
> timedelta treats datetime as "naive".  If that's not what someone
> wants, fine, but then they don't want Python's datetime arithmetic
> BTW, there's no implication that they're "wrong" for wanting something
> different; what would be wrong is insisting that datetime's POV is
> "wrong".  Both views are valid and useful, depending on the needs of
> the application.  One had to picked as the built-in behavior, and
> "naive" won.

Sigh. This offends my sensibilities so much, but I've said my bit on this elsewhere on this list, and I don't think I have the right abstraction to cut this Gordian knot.  Point conceded.

> > ...
> > But IIUC what Lennart is complaining about
>
> I don't, and I wish he would be more explicit about what "the
> problem(s)" is(are).
>
> > is the fact that the DST flag isn't part of and can't be embedded into a local time,
> > so it's impossible to fold the second parameter to $fromlocal$ into $t$.  Without
> > that, a local time isn't rich enough to designate a single point in time and the
> > whole edifice breaks.
>
> You can blame Guido for that too ;-) , but in this case I disagree(d)
> with him:  Guido was overly (IMO) annoyed by that the only apparent
> purpose for a struct tm's tm_ isdst flag was to disambiguate local
> times in a relative handful of cases.  His thought:  an entire bit
> just for that?!  My thought:  get over it, it's one measly bit.

I could have sworn that the last thing I saw Guido post about the previous point was something along the lines of "oops", but I bet it was really about this.

ijs

[1]: https://en.wikipedia.org/wiki/Weierstrass_function

From tim.peters at gmail.com  Sun Jul 26 02:56:52 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 25 Jul 2015 19:56:52 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
Message-ID: <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>

[Lennart Regebro <regebro at gmail.com>]
>>> And I would want to remind everyone again that this is not a question
>>> of the problem being impossible. It's just really complex to get right
>>> in all cases, and that always having the UTC timestamp around gets rid
>>> of most of that complexity.

[Tim]
>> Could you please be explicit about what "the problem" is?  Everyone
>> here is guessing at what you think "the problem" is.

[Lennart]
> The problem is that it is exceedingly complicated to get all the
> calculations back and forth between local time and UTC to be correct
> at all times and for all cases. It really doesn't get more specific
> than that. I don't remember which exact problem it was that made me
> decide that this was not the correct solution and that we should use
> UTC internally, but I don't think that matters, because I'm also sure
> that it was not the last case, as I was far from near the end in
> adding testcases.

I believe everyone here is saying it "shouldn't be" exceedingly
complicated, or even particularly hard, if you add the is_dst flags
the PEP says it would add.

But is the PEP complete?  Under the "Postponement" section, it says:

    The implementation has turned out to be exceedingly complex,
    due to having to convert back and forth between the local time
    and UTC during arithmetic and adjusting the DST for each
    arithmetic step, with ambiguous times being particularly hard
    to get right.

However, the _body_ of the PEP said nothing whatsoever about altering
arithmetic.  The body of the PEP sounds like it's mainly just
proposing to fold the pytz package into the core.  Perhaps doing
_just_ that much would get this project unstuck?  Hope springs eternal
:-)

> Once again I'm sure it's not impossible to somehow come up with an
> implementation and an API that can do this based on local time, but
> once again I am of the opinion that it is the wrong thing to do. We
> should switch to using UTC internally, because that will make
> everything so much simpler.

Like what?  I'm still looking for a concrete example of what "the
problem" is (or even "a" problem).

> I am in no way against other people implementing this PEP, but I think
> you will end up with very complex code that will be hard to maintain.

Somebody first needs to define what "the problem" is ;-)

> There really is a reason every other date time implementation I know
> of uses UTC internally,

Yes, but the fundamental reason datetime does not is that Guido
consciously and deliberately decided that "naive datetime" would be
most useful most often for most users.  That's why "naive" objects are
the default.  And even for "aware" objects, arithmetic staying within
a single time zone was deliberately specified to be "naive" too.  My
guess is that all other datetime implementations you know of have no
concept of "naive" datetimes. let alone make naive datetimes primary.
Small wonder, if so, that they're all different in this way.

That's a design decision not everyone likes, and certainly isn't
suitable for all purposes, but the debate over that ended a dozen
years ago when the decision was made.  If your vision of PEP 431
_changes_ that design decision (which it sure _sounds_ like it wants
to based on what you're typing here, but which PEP 431 itself does not
appear to say - impossible to tell which from here without any
specific example(s)), that may account for all sorts of complications
that aren't apparent to me.

> and there really is a reason why everyone always recommends storing date
> times in UTC with the time zone or offset separately.

Well, that's the second thing they recommend - and they can already do
that.  The first thing to recommend is to use naive objects in any
application where that's possible, so that you don't have to bother
with _any_ time zone esoterica, surprises, complications or overheads.
After all, it's 7:54 PM as I type this, and that's perfectly clear to
me ;-)

From regebro at gmail.com  Sun Jul 26 05:31:49 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 26 Jul 2015 05:31:49 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
Message-ID: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>

On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters <tim.peters at gmail.com> wrote:
> However, the _body_ of the PEP said nothing whatsoever about altering
> arithmetic.  The body of the PEP sounds like it's mainly just
> proposing to fold the pytz package into the core.  Perhaps doing
> _just_ that much would get this project unstuck?  Hope springs eternal
> :-)

The pytz package has an API and a usage that is different from the
datetime() module. One of the things you need to do is that after each
time you do arithmetic, you have to normalize the result. This is done
because the original API design did not realize the difficulties and
complexities of timezone handling and therefore left out things like
ambiguous times.

The PEP attemps to improved the datetime modules API so that it can
handle the ambiguous times. It also says that the implementation will
be based on pytz, because it was my assumption that this would be
easy, since pytz already handles ambiguous times. During my attempt of
implementing it I realized it wasn't easy at all, and it wasn't as
easy as folding pytz into the core.

Yes, the PEP gives that impression, because that was the assumption
when I wrote the draft. Just folding pytz into the core without
modifying the API defeats the whole purpose of the PEP, since
installing pytz is a trivial task.

> Like what?  I'm still looking for a concrete example of what "the
> problem" is (or even "a" problem).

A problem is that you have a datetime, and add a timedelata to it, and
it should then result in a datetime that is actually that timedelta
later. And if you subtract the same timedelta from the result, it
should return a datetime that is equal to the original datetime.

This sounds ridiculously simple, and is ridiculously difficult to make
happen in all cases that we want to support (Riyahd time zone and leap
seconds not included). That IS the specific, concrete problem, and if
you don't believe me, there is nothing I can do to convince you.
Perhaps I am a complete moron and simply incompetent to do this, and
in that case I'm sure you could implement this over a day, and then
please do so, but for the love of the founders of computing I'm not
going to spend more time repeating it on this mailing list, because
then we would do better in having you implement this instead of
reading emails. Me repeating this a waste of time for everyone
involved, and I will now stop.

> <discussing why Python's datetime is dfferent>

I was not involved in the discussion then, and even if I had been,
that's still before I knew anything about the topic. I don't know what
the arguments were, and I don't think it's constructive to try to
figure out exactly why that decision was made. That is all to similar
to assigning blame, which only makes people feel bad. Those who get
blamed feel bad, and those who blame feel like dicks and onlookers get
annoyed. Let us look forward instead.

I am operating both without any need to defend that decision, as I was
not involved in it, and I am operating with 20/20 hindsight as I am
one of the few people having tried to implement a timezone
implementation that supports ambiguous datetimes based on that
decision. And then it is perfectly clear and obvious that the decision
was a mistake and that we should rectify it.

The only question for me is how and when.

From mertz at gnosis.cx  Sun Jul 26 06:24:56 2015
From: mertz at gnosis.cx (David Mertz)
Date: Sat, 25 Jul 2015 21:24:56 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
Message-ID: <CAEbHw4Z_NiashSipsjQijwoO4WByp5UHgzJX9GqSHNeY2oz5jw@mail.gmail.com>

At the risk of being off-topic, I realize I really DO NOT currently
understand datetime in its current incarnation.  It's too bad PEP 431
proves so difficult to implement.

Even using `pytz` is there any way currently to get sensible answers to,
e.g.:

from datetime import *
from pytz import timezone
pacific = timezone('US/Pacific')
pacific.localize(datetime(2015, 11, 1, 1, 30))  # Ambiguous time
pacific.localize(datetime(2015, 3, 8, 2, 30))   # Non-existent time


That is, what if I had *not* just looked up when the time change happens,
and was innocently trying to define one of those datetimes above?  Is there
ANY existing way to have an error raised?or check in some other way?for the
fact that one of the times occurs twice on my clock, and the other never
occurs at all?


On Sat, Jul 25, 2015 at 8:31 PM, Lennart Regebro <regebro at gmail.com> wrote:

> On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters <tim.peters at gmail.com> wrote:
> > However, the _body_ of the PEP said nothing whatsoever about altering
> > arithmetic.  The body of the PEP sounds like it's mainly just
> > proposing to fold the pytz package into the core.  Perhaps doing
> > _just_ that much would get this project unstuck?  Hope springs eternal
> > :-)
>
> The pytz package has an API and a usage that is different from the
> datetime() module. One of the things you need to do is that after each
> time you do arithmetic, you have to normalize the result. This is done
> because the original API design did not realize the difficulties and
> complexities of timezone handling and therefore left out things like
> ambiguous times.
>
> The PEP attemps to improved the datetime modules API so that it can
> handle the ambiguous times. It also says that the implementation will
> be based on pytz, because it was my assumption that this would be
> easy, since pytz already handles ambiguous times. During my attempt of
> implementing it I realized it wasn't easy at all, and it wasn't as
> easy as folding pytz into the core.
>
> Yes, the PEP gives that impression, because that was the assumption
> when I wrote the draft. Just folding pytz into the core without
> modifying the API defeats the whole purpose of the PEP, since
> installing pytz is a trivial task.
>
> > Like what?  I'm still looking for a concrete example of what "the
> > problem" is (or even "a" problem).
>
> A problem is that you have a datetime, and add a timedelata to it, and
> it should then result in a datetime that is actually that timedelta
> later. And if you subtract the same timedelta from the result, it
> should return a datetime that is equal to the original datetime.
>
> This sounds ridiculously simple, and is ridiculously difficult to make
> happen in all cases that we want to support (Riyahd time zone and leap
> seconds not included). That IS the specific, concrete problem, and if
> you don't believe me, there is nothing I can do to convince you.
> Perhaps I am a complete moron and simply incompetent to do this, and
> in that case I'm sure you could implement this over a day, and then
> please do so, but for the love of the founders of computing I'm not
> going to spend more time repeating it on this mailing list, because
> then we would do better in having you implement this instead of
> reading emails. Me repeating this a waste of time for everyone
> involved, and I will now stop.
>
> > <discussing why Python's datetime is dfferent>
>
> I was not involved in the discussion then, and even if I had been,
> that's still before I knew anything about the topic. I don't know what
> the arguments were, and I don't think it's constructive to try to
> figure out exactly why that decision was made. That is all to similar
> to assigning blame, which only makes people feel bad. Those who get
> blamed feel bad, and those who blame feel like dicks and onlookers get
> annoyed. Let us look forward instead.
>
> I am operating both without any need to defend that decision, as I was
> not involved in it, and I am operating with 20/20 hindsight as I am
> one of the few people having tried to implement a timezone
> implementation that supports ambiguous datetimes based on that
> decision. And then it is perfectly clear and obvious that the decision
> was a mistake and that we should rectify it.
>
> The only question for me is how and when.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150725/5153dc28/attachment.html>

From tim.peters at gmail.com  Sun Jul 26 06:27:13 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 25 Jul 2015 23:27:13 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <SN1PR06MB182477F6100A6B97CABBBF20B6800@SN1PR06MB1824.namprd06.prod.outlook.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <SN1PR06MB182477F6100A6B97CABBBF20B6800@SN1PR06MB1824.namprd06.prod.outlook.com>
Message-ID: <CAExdVN=nAsurVC5qudd1_dGwHu_2+x44jJxzE5L0JAjqqTvE3Q@mail.gmail.com>

[ISAAC J SCHWABACHER <ischwabacher at wisc.edu>]
>>> ...
>>> I think the right perspective is that a time zone *is* the function that its
>>> `fromutc()` method implements,

[Tim]
>> Fine by me ;-)

[Isaac]
> My issue is that you're computing `fromutc()`, which is a function, in
> terms of `dst()` and `utcoffset()`, which aren't.

I know.  That's not "an issue" that will gain traction, though ;-)

> I think this is backwards; `dst()` and `utcoffset()` should be computed
> from `fromutc()` plus some additional information that has to be present
> anyway in order to implement `fromutc()`.

Memory lane:  that additional information doesn't exist now.  I think
it "should have", but at the time, as I recall there was fatal
opposition to storing an `isdst` flag because it would consume an
extra byte in the pickle format.  That was enough to kill it:
datetime development was paid for by a company very concerned about
pickle sizes ;-)

> With the extra bit, `dst()` and `utcoffset()` become partial functions, which
> makes it *possible* to get the right answer in all cases, but it's still simpler
> to start with the total function and work from there.

Well, maybe simpler for you, but I think not in general.  At the time,
all aspects of datetime's development were vigorously debated, but
mostly on Zope Corp (the company paying for it) wikis and mailing
lists.  While some people didn't care about time zones at all, most
did.  Of the latter:

- All were keenly aware of the need to incorporate UTC offsets.
- All were keenly aware of the need to accommodate "daylight time" schemes.
- None gave a fig about anything else.

Very late in the game, examples were given of localities that had in
fact changed their UTC offsets from time to time, but as curiosities
rather than as "issues".  That's when I created fromutc() - it was a
last-second addition.  I cared enough to make it _possible_ to
accommodate such cases, but there was no interest (or time) to cater
to them directly.  Instead fromutc() was written to use only the
already-existing utcoffset() and dst().  Everyone already knew how to
use the latter:  they directly corresponded to the two things everyone
cared about keenly from the start.

That doesn't _preclude_ anyone from writing a more-general fromutc(),
and I encourage, for example, you to do so ;-)  I agree it's the most
fundamental thing from an abstract mathematical view, but "UTC offset"
and "DST offset" fit most peoples' brains a hell of a lot better than
"collection of piecewise continuous monotonically increasing functions
whose images don't overlap too much" ;-)

>>> .... Daylight Saving Time is a red herring,

>> Overstated ....

> I stand by what I meant by this, even if I did a bad job of expressing
> the point. Assuming that all time zone discontinuities are due to DST
> changes breaks many time zones (really almost all of the Olson time
> zones, though only for a vanishingly small fraction of datetimes),

It's use cases that are missing here:  who needs to convert historic
times to/from UTC. and where the "problem times" are generally
arranged by politicians to occur when most people are sleeping?
That's why nobody really cared about offset-changing zones at the
start.  Yes, such zones exist, but times recorded in such zones are in
yesterday's databases we don't care about anymore except maybe to
display the values.

> but that's not the point I was making. The point is that it doesn't buy us
> anything.

Au contraire:  as above, it bought datetime a model people thought
they understood at once, since almost everyone has wrestled with UTC
offsets and daylight-time switches in ordinary daily life.  Implement
utcoffset() and dst(), and you're done.  Even if you're really not,
you _think_ you are, so you slumber peacefully then ;-)

> Though this is probably obscured by all the markup, the more general
> algorithm I gave is also simpler than the one in the comment in datetime.py,
> and the reason for that is that it solves an easier problem, but one that
> serves our practical purposes just as well.

It's heavily obscured by the heavy markup.  Write some Python code
instead?  I expect few people will try to untangle the meaning
otherwise.

As for whether it's simpler - eh, don't know.  Here's the actual code,
stripped of error-checking:

    def fromutc(self, dt):
        dtoff = dt.utcoffset()
        dtdst = dt.dst()
        delta = dtoff - dtdst
        if delta:
            dt += delta
            dtdst = dt.dst()
        return dt + dtdst

Will your code run faster?  Have fewer conditionals?  Fewer lines?
Shorter lines?  Less nesting?  Fewer operations?  Important to me,
though, is that your code should be far more self-evidently _correct_,
provided the reader understands the math underlying it (which will
require - as this code does - referring to a relatively massive wall
of text to explain it).

> ...
> I went too far in inferring your viewpoint from your code.  I don't find fault
> with the explanation on its own terms. But adding zoneinfo to the stdlib,
> as PEP 431 proposes to do, requires making weaker assumptions and
> asking a different question than the one answered in the comment.

pytz is already in wide use, yes?  How many complaints are there about
non-functioning cases?  I have no idea.

> As a mathematician at heart, I have a deep and abiding conviction, which
> I expect nobody else to share, that purity begets practicality in the long run.
> At least if you've found the right abstraction.

Guido is a mathematician by training, yet has an opposing view in this
case.  So:  resolved, there's no point in asking mathematicians about
anything, since they never agree ;-)


>>> [eliding a more-general view of what time zones "really" are]

> [note for people just joining this conversation: I think the information in
>  the elision is critical to understanding what I'm talking about]

By all means, yes!  Note that I found it helpful to paste it into a
web-based LaTeX renderer first, because it was close to impossible to
read otherwise.

> ...
> But these assumptions didn't come out of nowhere. They're the assumptions
> behind zoneinfo, weakened as much as possible without making the problem
> any harder. It's hard to weaken them further and still have anything to work
> with. (See? I *do* still have a sense of practicality!)

Good to hear ;-)

> Nobody wants to read me discussing this at great length, but I'll say
> that I don't expect any legislative body to have the collective
> mathematical sophistication necessary to violate piecewise
> continuity or computability. If you really want to troll me, I invite you
> to take over a government and institute a time zone based on the (Weierstrass
> function)[1].

No, politicians don't surprise with their sophistication, but with
their stupidity :-)  For example, when Mike Huckabee becomes US
President in 2016, I expect he'll put the US on Apocalypse Time.  This
will count time _backwards_ starting from now and ending with
0:00:00.000000 at the stroke of (what we now think of as) midnight at
the end of (what we now think of as) 2099.  And there goes "strictly
increasing" ;-)


> Parts of five US states (Alaska, North Dakota, Indiana, Kentucky
> and Michigan) have changed their standard time since 1970.

For example, North Dakota's Mercer County switched from US Mountain to
US Central on or about 7 Nov 2010.  That's the kind of thing you're
talking about?  Eh.  I don't believe anyone anywhere had a "time zone"
designed specifically for Mercer County before - and probably still
doesn't.  But, sure, if somebody really wants to create such a beast,
they should be able to.  Everyone else in the world will use US
Central for it now, and never know the difference ;-)

> But I'll admit that mentioning Riyadh was a low blow.

It was fun!  I just wish all examples were that engagingly bizarre :-)

>> ...
>> For that reason, it was wholly intentional that datetime +
>> timedelta treats datetime as "naive". ...

> Sigh. This offends my sensibilities so much, but I've said my bit
> on this elsewhere on this list, and I don't think I have the right abstraction
> to cut this Gordian knot.  Point conceded.

I should point out that I haven't paid any attention to datetime for
some years now (other than being a happy casual user), so don't know
what you previously said, and can't even say whether Guido is still of
the same opinion.  However, if he had changed his mind, he would have
used his time machine to change all he previously wrote about it, and
I didn't see any evidence of that.

From tim.peters at gmail.com  Sun Jul 26 08:05:45 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 26 Jul 2015 01:05:45 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
Message-ID: <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>

[Tim]
>> However, the _body_ of the PEP said nothing whatsoever about altering
>> arithmetic.  The body of the PEP sounds like it's mainly just
>> proposing to fold the pytz package into the core.  Perhaps doing
>> _just_ that much would get this project unstuck?  Hope springs eternal :-)

[Lennart Regebro <regebro at gmail.com>]
> The pytz package has an API and a usage that is different from the
> datetime() module. One of the things you need to do is that after each
> time you do arithmetic, you have to normalize the result. This is done
> because the original API design did not realize the difficulties and
> complexities of timezone handling and therefore left out things like
> ambiguous times.

Oh, they were realized - indeed, the pytz docs point to Python's
tzinfo docs to explain the ambiguities, and the latter docs existed
before ;-) day 1.

The Python docs also are quite clear about that all arithmetic within
a single timezone is "naive".  That was intentional.  The _intended_
way to do "aware" arithmetic was always to convert to UTC, do the
arithmetic, then convert back.

You never _have_ to normalize() in pytz.  But it's needed if you
_don't_ follow pytz's explicit

    The preferred way of dealing with times is to always work in UTC,
    converting to localtime only when generating output to be read by
    humans

advice, and want to do "aware" arithmetic directly in a non-UTC time
zone.  Python's datetime never intended to support that directly.
Quite the contrary.  I know people who feel otherwise tend to think of
that as a lazy compromise (or some such), but naive arithmetic was
intended to be "a feature".  Fight the design every step of the way,
and, yup, you get problems every step of the way.

> The PEP attemps to improved the datetime modules API so that it can
> handle the ambiguous times.

No problem with that.  I always thought the lack of storing
is_dst-like info was datetime's biggest wart.

> It also says that the implementation will be based on pytz, because it
> was my assumption that this would be easy, since pytz already handles
> ambiguous times. During my attempt of implementing it I realized it
> wasn't easy at all, and it wasn't as easy as folding pytz into the core.

Is it the case that pytz also "fails" in the cases your attempts "fail"?

In any case, if you're trying to change how "aware" datetime
arithmetic works, that's a major and backward-incompatible change.
Does Guido realize it?  As before, it's not at all clear from the PEP.

> Yes, the PEP gives that impression, because that was the assumption
> when I wrote the draft. Just folding pytz into the core without
> modifying the API defeats the whole purpose of the PEP, since
> installing pytz is a trivial task.

"Batteries included" has some attractions all on its own.  On top of
that, adding is_dst-like flags to appropriate methods may have major
attractions.  Changing the semantics of datetime arithmetic has major
attractions to some people, but also major drawbacks - regardless,
since changing it turns Guido's original design on its head, he really
needs to Pronounce on that part.

>> Like what?  I'm still looking for a concrete example of what "the
>> problem" is (or even "a" problem).

> A problem is that you have a datetime, and add a timedelata to it, and
> it should then result in a datetime that is actually that timedelta
> later. And if you subtract the same timedelta from the result, it
> should return a datetime that is equal to the original datetime.
>
> This sounds ridiculously simple

Ah, but it already happens that way - because the builtin datetime
arithmetic is "naive".  The docs have always promised this:

"""
datetime2 = datetime1 + timedelta (1)
datetime2 = datetime1 - timedelta (2)

1) datetime2 is a duration of timedelta removed from datetime1, moving
forward in time if timedelta.days > 0, or backward if timedelta.days <
0. The result has the same tzinfo attribute as the input datetime, and
datetime2 - datetime1 == timedelta after. OverflowError is raised if
datetime2.year would be smaller than MINYEAR or larger than MAXYEAR.
Note that no time zone adjustments are done even if the input is an
aware object.

2) Computes the datetime2 such that datetime2 + timedelta ==
datetime1. As for addition, the result has the same tzinfo attribute
as the input datetime, and no time zone adjustments are done even if
the input is aware. This isn?t quite equivalent to datetime1 +
(-timedelta), because -timedelta in isolation can overflow in cases
where datetime1 - timedelta does not.
"""

>, and is ridiculously difficult to make happen in all cases that we want to
> support (Riyahd time zone and leap seconds not included).
> That IS the specific, concrete problem, and if you don't believe me, there
> is nothing I can do to convince you.

I apologize if I've come off as unduly critical - I truly have been
_only_ trying to find out what "the problem" is.  That helps!  Thank
you.  Note that I've had nothing to do with datetime (except to use
it) for about a decade.  I have no idea what you, or anyone else, has
said about it for years & years until this very thread caught my
attention this week.  Heck, for all I know, Guido _demanded_ that
datetime arithmetic be changed - although I doubt it ;-)

> Perhaps I am a complete moron and simply incompetent to do this, and
> in that case I'm sure you could implement this over a day, and then
> please do so, but for the love of the founders of computing I'm not
> going to spend more time repeating it on this mailing list, because
> then we would do better in having you implement this instead of
> reading emails. Me repeating this a waste of time for everyone
> involved, and I will now stop.

Then special thanks for repeating it one more time, since it's the
first time I've heard it :-)

FWIW, I'm sure Isaac and Alexander already know how to make this work,
although it requires (as you found out the hard way) more than just
copying in bits of pytz, and DST transitions aren't the only
non-insane potential problem.  But whether, specifically, the
semantics of datetime arithmetic _should_ change is a major question,
one not explicitly mentioned in the PEP, so this project may have to
move back to square 1 on that specific question.  Resolving
ambiguities is a different question.

> ...
> I was not involved in the discussion then, and even if I had been,
> that's still before I knew anything about the topic. I don't know what
> the arguments were, and I don't think it's constructive to try to
> figure out exactly why that decision was made. That is all to similar
> to assigning blame, which only makes people feel bad. Those who get
> blamed feel bad, and those who blame feel like dicks and onlookers get
> annoyed. Let us look forward instead.

No problem:  there's only Guido to blame, and he's so used to that he
doesn't even notice it anymore ;-)


> I am operating both without any need to defend that decision, as I was
> not involved in it, and I am operating with 20/20 hindsight as I am
> one of the few people having tried to implement a timezone
> implementation that supports ambiguous datetimes based on that
> decision. And then it is perfectly clear and obvious that the decision
> was a mistake and that we should rectify it.

There's more than one decision affecting this  In cases where a single
local time corresponds to more than one UTC time (typically at the end
of DST, when a local hour repeats), datetime never did give any clear
way to do "the intended" conversion from that local time _to_ UTC.
But resolving such ambiguities has nothing to do with how arithmetic
works:  it's utterly unsolvable by any means short of supplying new
info ("which UTC value is intended?" AKA is_dst).

> The only question for me is how and when.

Well, since there's more than one decision, I'm afraid there's also
more than one question ;-)

From ronaldoussoren at mac.com  Sun Jul 26 09:14:47 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 26 Jul 2015 09:14:47 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <128643133.270510.1437838774416.JavaMail.open-xchange@oxbsltgw13.schlund.de>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <128643133.270510.1437838774416.JavaMail.open-xchange@oxbsltgw13.schlund.de>
Message-ID: <DC7BF8E6-DE58-4DFE-B9BB-85C905DDCC77@mac.com>


> On 25 Jul 2015, at 17:39, Mark Shannon <mark at hotpy.org> wrote:
> 
> Hi,
> 
> On 22/07/15 09:25, Ronald Oussoren wrote:> Hi,
>> 
>> Another summer with another EuroPython, which means its time again to 
>> try to revive PEP 447?
>> 
> 
> IMO, there are two main issues with the PEP and implementation.
> 
> 1. The implementation as outlined in the PEP is infinitely recursive, since the
> lookup of "__getdescriptor__" on type must necessarily call
> type.__getdescriptor__.
> The implementation (in C) special cases classes that inherit "__getdescriptor__"
> from type. This special casing should be mentioned in the PEP.

Sure.  An alternative is to slightly change the the PEP: use __getdescriptor__ when
present and directly peek into __dict__ when it is not, and then remove the default
__getdescriptor__. 

The reason I didn?t do this in the PEP is that I prefer a programming model where
I can explicitly call the default behaviour. 

> 
> 2. The actual implementation in C does not account for the case where the class
> of a metaclass implements __getdescriptor__ and that method returns a value when
> called with "__getdescriptor__" as the argument.

Isn?t that the same problem as with all slots, even when using __getattribute__? That is,
a meta class that implements __getattribute__ to return implementations for (say)
__getitem__ won?t work because the interpreter won?t call __getattribute__ to get that
implementation unless it already knows that the attribute is present.  Class creation,
and __setattr__ on type will not only fill __dict__, but also set slots in the type structure
as appropriate.  The interpreter than uses those slots to determine if a special method
is present.

In code:

class Meta1 (type):
    def __getitem__(self, key):
        return "<{} {}>".format(self.__name__, key)

class Class1 (metaclass=Meta1):
    pass



class Meta2 (type):
    def __getattribute__(self, name):
        if name == "__getitem__":
            return lambda key: "<{} {}>".format(self.__name__, key)

        return super().__getattribute__(name)

class Class2 (metaclass=Meta2):
    pass

print(Class1.__getitem__("hello"))
print(Class1["hello"])

print(Class2.__getitem__("hello"))
print(Class2["hello"])

The last line causes an exception:

Traceback (most recent call last):
  File "demo-getattr.py", line 24, in <module>
    print(Class2["hello"])
TypeError: 'Meta2' object is not subscriptable

I agree that this should be mentioned in the PEP as it can be confusing.

> 
> 
> 
> Why was "__getattribute_super__" rejected as an alternative? No reason is given.
> 
> "__getattribute_super__" has none of the problems listed above.

Not really. I initially used __getattribute_super__ as the name, but IIRC with
the same  semantics.

> Making super(t, obj) delegate to t.__super__(obj) seems consistent with other
> builtin method/classes and doesn't add corner cases to the already complex
> implementation of PyType_Lookup().

A disadvantage of delegation is t.__super__ then reproduce the logic dealing
with the MRO, while my proposal allows the metaclass to just deal with lookup
in a specific class object. 

Implementation complexity is an issue, but it seems to be acceptable so far. The main
problem w.r.t. additional complexity is that PyType_Lookup can now fail
with an exception other than an implied AttributeError and that causes
changes elsewhere in the implementation.

BTW. The patch for that part is slightly uglier than it needs to be, I currently
test for PyErr_Occurred() instead of using return codes in a number of places
to minimise the number of lines changes to make code review easier.  That 
needs to be changed before the code would actually be committed.

Ronald

P.S. Are you at the EP sprints? I?ll be there until early in the afternoon.

> 
> Cheers,
> Mark
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150726/063926a5/attachment.html>

From regebro at gmail.com  Sun Jul 26 10:12:15 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 26 Jul 2015 10:12:15 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
Message-ID: <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>

On Sun, Jul 26, 2015 at 8:05 AM, Tim Peters <tim.peters at gmail.com> wrote:
> The Python docs also are quite clear about that all arithmetic within
> a single timezone is "naive".  That was intentional.  The _intended_
> way to do "aware" arithmetic was always to convert to UTC, do the
> arithmetic, then convert back.

We can't explicitly implement incorrect timezone aware arithmetic and
then expect people to not use it. We can make the arithmetic correct,
and we can raise an error when doing tz-aware arithmetic in a
non-fixed timezone. But having an implementation we know is incorrect
and telling people "don't do that" doesn't seem like a good solution
here.

Why do we even have timezone aware datetimes if we don't intend them
for usage? There could just be naive datetimes, and timezones, and let
strftime take a timezone that is used when formatting. And we could
make date-time creation into a function that parses data including a
timezone, and returns the UTC time of that data.

But then again, if we do that, we could just as well have that
timezone as an attribute on the datetime object, and let strftime use
so it doesn't have to be passed in. And we could let the __init__ of
the datetime take a timezone and do that initial conversion to UTC.

> Python's datetime never intended to support that directly.

I think it should. It's expected that it supports it, and there is no
real reason not to support it. The timezone handling becomes
complicated if you base yourself on localtime, and simple if you base
yourself on UTC.

As you agree, we recommend to people to use UTC at all times, and only
use timezones for input and output. Well, what I'm now proposing is to
take that recommendation to heart, and change datetime's
implementation so it does exactly that.

I saw the previous mention of "pure" vs "practical", and that is often
a concern. Here it clearly is not. This is a choice between impure,
complicated and impractical, and pure, simple and practical.

> Is it the case that pytz also "fails" in the cases your attempts "fail"?

No, that is not the case. And if you wonder why I just don't do it
like pytz does it, it's because that leads to infinite recursion, much
as discussions on this mailing list does. ;-) And this is because we
need to normalize the datetime after arithmatic, but normalizing is
arithmetics.

> "Batteries included" has some attractions all on its own.  On top of
> that, adding is_dst-like flags to appropriate methods may have major
> attractions.

> Ah, but it already happens that way

No, in fact it does not. Pytz makes that happen only through a
separate explicit normalize() call (and some deep cleverness to keep
track of which timezone offset it is located in). dateutil.tz can't
guarantee these things to be true, because it doesn't keep track of
ambiguous times. So no, it does not already happen that way.

>>> from dateutil.zoneinfo import gettz
>>> from datetime import *
>>> dt = datetime(2015, 11, 1, 0, 30, tzinfo=est)
>>> dt2 = dt + timedelta(hours=1)

>>> utc = gettz('Etc/UTC')
>>> dtutc = dt.astimezone(utc)
>>> dt2utc = dt2.astimezone(utc)
>>> (dt2utc-dtutc).total_seconds()
7200.0

You add one hour, and you get a datetime that happens two hours later.
So no, it does not already happen that way.
In pytz the datetime will be adjusted after you do the normalize call.

> I apologize if I've come off as unduly critical - I truly have been
> _only_ trying to find out what "the problem" is.  That helps!  Thank
> you.  Note that I've had nothing to do with datetime (except to use
> it) for about a decade.  I have no idea what you, or anyone else, has
> said about it for years & years until this very thread caught my
> attention this week.  Heck, for all I know, Guido _demanded_ that
> datetime arithmetic be changed - although I doubt it ;-)

It's not a question of changing datetime arithmetic per se. The PEP
does indeed mean it has to be changed, but only to support ambiguous
and non-existent times.

It's helpful to me to understand, which I hadn't done before, that
this was never intended to work. That helps me argue for changing
datetimes internal implementation, once I get time to do that. (I'm
currently moving, renovating a new house, trying fix up a garden that
has been neglected for years, and insanely, write my own code editor,
all at the same time, so it won't be anytime soon).

> There's more than one decision affecting this  In cases where a single
> local time corresponds to more than one UTC time (typically at the end
> of DST, when a local hour repeats), datetime never did give any clear
> way to do "the intended" conversion from that local time _to_ UTC.
> But resolving such ambiguities has nothing to do with how arithmetic
> works:  it's utterly unsolvable by any means short of supplying new
> info ("which UTC value is intended?" AKA is_dst).

The "changing arithmetic" discussion is a  red herring.

Now my wife insist I help her pack, so this is the end of this
discussion for me. If i continue it will be only as a part of
discussing how we change how datetime works internally.

//Lennart

From ronaldoussoren at mac.com  Sun Jul 26 11:41:53 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 26 Jul 2015 11:41:53 +0200
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <DC7BF8E6-DE58-4DFE-B9BB-85C905DDCC77@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <128643133.270510.1437838774416.JavaMail.open-xchange@oxbsltgw13.schlund.de>
 <DC7BF8E6-DE58-4DFE-B9BB-85C905DDCC77@mac.com>
Message-ID: <B5856DE2-5FC2-4470-A4CB-030D2A1F6695@mac.com>


> On 26 Jul 2015, at 09:14, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> 
> 
>> On 25 Jul 2015, at 17:39, Mark Shannon <mark at hotpy.org <mailto:mark at hotpy.org>> wrote:
>> 
>> Hi,
>> 
>> On 22/07/15 09:25, Ronald Oussoren wrote:> Hi,
>>> 
>>> Another summer with another EuroPython, which means its time again to 
>>> try to revive PEP 447?
>>> 
>> 
>> IMO, there are two main issues with the PEP and implementation.
>> 
>> 1. The implementation as outlined in the PEP is infinitely recursive, since the
>> lookup of "__getdescriptor__" on type must necessarily call
>> type.__getdescriptor__.
>> The implementation (in C) special cases classes that inherit "__getdescriptor__"
>> from type. This special casing should be mentioned in the PEP.
> 
> Sure.  An alternative is to slightly change the the PEP: use __getdescriptor__ when
> present and directly peek into __dict__ when it is not, and then remove the default
> __getdescriptor__. 
> 
> The reason I didn?t do this in the PEP is that I prefer a programming model where
> I can explicitly call the default behaviour. 

I?m not sure there is a problem after all (but am willing to use the alternative I describe above),
although that might be because I?m too much focussed on CPython semantics.

The __getdescriptor__ method is a slot in the type object and because of that the
 normal attribute lookup mechanism is side-stepped for methods implemented in C. A
__getdescriptor__ that is implemented on Python is looked up the normal way by the 
C function that gets added to the type struct for such methods, but that?s not a problem for
type itself.

That?s not new for __getdescriptor__ but happens for most other special methods as well,
as I noted in my previous mail, and also happens for the __dict__ lookup that?s currently
used (t.__dict__ is an attribute and should be lookup up using __getattribute__, ?)

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150726/9cfd3da5/attachment.html>

From p.f.moore at gmail.com  Sun Jul 26 13:58:17 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 26 Jul 2015 12:58:17 +0100
Subject: [Python-Dev] Burning down the backlog.
In-Reply-To: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
References: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
Message-ID: <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>

On 25 July 2015 at 20:28, Robert Collins <robertc at robertcollins.net> wrote:
> Those charts doesn't show patches in 'commit-review' -
> http://bugs.python.org/issue?%40columns=title&%40columns=id&stage=5&%40columns=activity&%40sort=activity&status=1&%40columns=status&%40pagesize=50&%40startwith=0&%40sortdir=on&%40action=search
>
> There are only 45 of those patches.
>
> AIUI - and I'm very new to core here - anyone in triagers can get
> patches up to commit-review status.
>
> I think we should set a goal to keep inventory low here - e.g. review
> and either bounce back to patch review, or commit, in less than a
> month. Now - a month isn't super low, but we have lots of stuff
> greater than a month.

I'm not actually clear what "Commit Review" status means. I did do a
quick check of the dev guide, and couldn't come up with anything, but
looking at the first issue on that list
(http://bugs.python.org/issue24585) the change has been committed but
it can't practically be tested until it's released in a beta. The
second on the list also seems to have been committed.

While post-commit reviews are useful, I wouldn't classify not getting
them as a pressing problem (after all, the change is in, so in the
worst case we'll get bug reports if there *were* any issues). Getting
patches to a state where they can be committed, and more importantly
actually committing them, is the bigger problem.

Looking at "Issues with patches" for example, I find
http://bugs.python.org/issue21279. That is a simple doc patch, and
there's a pretty lengthy discussion on getting the exact wording right
(plus six revisions of the patch). That seems excessive, but
nevertheless...

My problem is that in order to commit that patch (which seems to be
the next step - I see no reason not to) I'd need to go through working
out all of the commit/merge process, and make sure I got it all right.
That's a lot of work (and some level of risk) - particularly compared
to working on pip, where I hit the "merge" button, and I'm done. So
that patch languishes until someone other than me, who's more familiar
with the commit process, merges it.

Of course, I could learn the patch process, but my time for working on
tracker items is limited, and my brain is getting old, so the
likelihood is that I'll forget some of the details before next time,
so that learning time isn't a one-off cost.

This is basically what the improved dev workflow peps are about, so
people are working on a solution, but to me that's the big problem -
we need a big red "Commit" button that provides a zero-effort means
for a core dev to point at a patch on the tracker that's already been
fully reviewed, and just say "do it". Personally, if I were actually
expecting to do enough commits to justify the effort, I'd write a
script to do that (and I'd probably isolate my build environment in a
VM, somehow, as I rebuild my main PC often enough that even having a
build env present on my PC isn't a given).

Paul

From mark at hotpy.org  Sun Jul 26 14:18:20 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sun, 26 Jul 2015 13:18:20 +0100 (BST)
Subject: [Python-Dev] PEP 447 (type.__getdescriptor__)
In-Reply-To: <B5856DE2-5FC2-4470-A4CB-030D2A1F6695@mac.com>
References: <00AA7433-C853-4101-9718-060468EBAC54@mac.com>
 <128643133.270510.1437838774416.JavaMail.open-xchange@oxbsltgw13.schlund.de>
 <DC7BF8E6-DE58-4DFE-B9BB-85C905DDCC77@mac.com>
 <B5856DE2-5FC2-4470-A4CB-030D2A1F6695@mac.com>
Message-ID: <1900153295.283384.1437913100285.JavaMail.open-xchange@oxbsltgw11.schlund.de>

> On 26 July 2015 at 10:41 Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> 
> 
> 
> > On 26 Jul 2015, at 09:14, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> > 
> > 
> >> On 25 Jul 2015, at 17:39, Mark Shannon <mark at hotpy.org
> >> <mailto:mark at hotpy.org>> wrote:
> >> 
> >> Hi,
> >> 
> >> On 22/07/15 09:25, Ronald Oussoren wrote:> Hi,
> >>> 
> >>> Another summer with another EuroPython, which means its time again to 
> >>> try to revive PEP 447?
> >>> 
> >> 
> >> IMO, there are two main issues with the PEP and implementation.
> >> 
> >> 1. The implementation as outlined in the PEP is infinitely recursive, since
> >> the
> >> lookup of "__getdescriptor__" on type must necessarily call
> >> type.__getdescriptor__.
> >> The implementation (in C) special cases classes that inherit
> >> "__getdescriptor__"
> >> from type. This special casing should be mentioned in the PEP.
> > 
> > Sure.  An alternative is to slightly change the the PEP: use
> > __getdescriptor__ when
> > present and directly peek into __dict__ when it is not, and then remove the
> > default
> > __getdescriptor__. 
> > 
> > The reason I didn?t do this in the PEP is that I prefer a programming model
> > where
> > I can explicitly call the default behaviour. 
> 
> I?m not sure there is a problem after all (but am willing to use the
> alternative I describe above),
> although that might be because I?m too much focussed on CPython semantics.
> 
> The __getdescriptor__ method is a slot in the type object and because of that
> the
>  normal attribute lookup mechanism is side-stepped for methods implemented in
> C. A
> __getdescriptor__ that is implemented on Python is looked up the normal way by
> the 
> C function that gets added to the type struct for such methods, but that?s not
> a problem for
> type itself.
> 
> That?s not new for __getdescriptor__ but happens for most other special
> methods as well,
> as I noted in my previous mail, and also happens for the __dict__ lookup
> that?s currently
> used (t.__dict__ is an attribute and should be lookup up using
> __getattribute__, ?)


"__getdescriptor__" is fundamentally different from "__getattribute__" in that
is defined in terms of itself.

object.__getattribute__ is defined in terms of type.__getattribute__, but
type.__getattribute__ just does 
dictionary lookups. However defining type.__getattribute__ in terms of
__descriptor__ causes a circularity as
__descriptor__ has to be looked up on a type.

So, not only must the cycle be broken by special casing "type", but that
"__getdescriptor__" can be defined
not only by a subclass, but also a metaclass that uses "__getdescriptor__" to
define  "__getdescriptor__" on the class.
(and so on for meta-meta classes, etc.)

Cheers,
Mark

From larry at hastings.org  Sun Jul 26 16:37:20 2015
From: larry at hastings.org (Larry Hastings)
Date: Sun, 26 Jul 2015 16:37:20 +0200
Subject: [Python-Dev] [RELEASED] Python 3.5.0b4 is now available
Message-ID: <CAOBd=7mj5gLt7bNMQ0sZV_Jx1iJH1cPEgEq+85fzNk+OjQ7RFw@mail.gmail.com>

On behalf of the Python development community and the Python 3.5 release
team, I'm delighted to announce the availability of Python 3.5.0b4.  Python
3.5.0b4 is scheduled to be the last beta release; the next release will be
Python 3.5.0rc1, or Release Candidate 1.

Python 3.5 has now entered "feature freeze".  By default new features may
no longer be added to Python 3.5.

This is a preview release, and its use is not recommended for production
settings.

An important reminder for Windows users about Python 3.5.0b4: if installing
Python 3.5.0b4 as a non-privileged user, you may need to escalate to
administrator privileges to install an update to your C runtime libraries.


You can find Python 3.5.0b4 here:

https://www.python.org/downloads/release/python-350b4/

Happy hacking,


*/arry*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150726/7e0777e4/attachment.html>

From stephane at wirtel.be  Sun Jul 26 16:41:09 2015
From: stephane at wirtel.be (Stephane Wirtel)
Date: Sun, 26 Jul 2015 16:41:09 +0200
Subject: [Python-Dev] [RELEASED] Python 3.5.0b4 is now available
In-Reply-To: <CAOBd=7mj5gLt7bNMQ0sZV_Jx1iJH1cPEgEq+85fzNk+OjQ7RFw@mail.gmail.com>
References: <CAOBd=7mj5gLt7bNMQ0sZV_Jx1iJH1cPEgEq+85fzNk+OjQ7RFw@mail.gmail.com>
Message-ID: <AFB57482-9352-4D7D-944B-90FDDFC95041@wirtel.be>

\o/

> On 26 juil. 2015, at 4:37 PM, Larry Hastings <larry at hastings.org> wrote:
> 
> 
> On behalf of the Python development community and the Python 3.5 release team, I'm delighted to announce the availability of Python 3.5.0b4.  Python 3.5.0b4 is scheduled to be the last beta release; the next release will be Python 3.5.0rc1, or Release Candidate 1.
> 
> Python 3.5 has now entered "feature freeze".  By default new features may no longer be added to Python 3.5.
> 
> This is a preview release, and its use is not recommended for production settings.
> 
> An important reminder for Windows users about Python 3.5.0b4: if installing Python 3.5.0b4 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries.
> 
> 
> You can find Python 3.5.0b4 here:
> https://www.python.org/downloads/release/python-350b4/
> Happy hacking,
> 
> 
> /arry
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/stephane%40wirtel.be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150726/67bdf70e/attachment.html>

From larry at hastings.org  Sun Jul 26 17:21:57 2015
From: larry at hastings.org (Larry Hastings)
Date: Sun, 26 Jul 2015 17:21:57 +0200
Subject: [Python-Dev] PyCapsule_Import semantics, relative imports,
 module names etc.
In-Reply-To: <55B2CD3B.6000708@redhat.com>
References: <55B2CD3B.6000708@redhat.com>
Message-ID: <CAOBd=7nNRFug7eh_EOfp_oGMCVqVo_Vp66hm_csj=PvvxTVprA@mail.gmail.com>

PyCapsule_Import() is a simple helper function, a slightly-updated analogue
to PyCObject_Import().  It's not particularly sophisticated, and I'm not
surprised it's bewildered by complicated scenarios like relative imports in
subpackages.  For now all I can recommend is that you not try and torture
PyCapsule_Import().  And, as always... patches welcome.


/arry

On Sat, Jul 25, 2015 at 1:41 AM, John Dennis <jdennis at redhat.com> wrote:

> While porting several existing CPython extension modules that form a
> package to be 2.7 and 3.x compatible the existing PyObject_* API was
> replaced with PyCapsule_*. This introduced some issues the existing CPython
> docs are silent on. I'd like clarification on a few issues and wish to
> raise some questions.
>
> 1. Should an extension module name as provided in PyModule_Create (Py3) or
> Py_InitModule3 (Py2) be fully package qualified or just the module name? I
> believe it's just the module name (see item 5 below) Yes/No?
>
> 2. PyCapsule_Import does not adhere to the general import semantics. The
> module name must be fully qualified, relative imports are not supported.
>
> 3. PyCapsule_Import requires the package (e.g. __init__.py) to import
> *all* of it's submodules which utilize the PyCapsule mechanism preventing
> lazy on demand loading. This is because PyCapsule_Import only imports the
> top level module (e.g. the package). From there it iterates over each of
> the module names in the module path. However the parent module (e.g.
> globals) will not contain an attribute for the submodule unless it's
> already been loaded. If the submodule has not been loaded into the parent
> PyCapsule_Import throws an error instead of trying to load the submodule.
> The only apparent solution is for the package to load every possible
> submodule whether required or not just to avoid a loading error. The
> inability to load modules on demand seems like a design flaw and change in
> semantics from the prior use of PyImport_ImportModule in combination with
> PyObject. [One of the nice features with normal import loading is setting
> the submodule name in the parent, the fact this step is omitted is what
> causes PyCapsule_Import to fail unless all submodules are unconditionally
> loaded). Shouldn't PyCapsule_Import utilize PyImport_ImportModule?
>
> 4. Relative imports seem much more useful for cooperating submodules in a
> package as opposed to fully qualified package names. Being able to import a
> C_API from the current package (the package I'm a member of) seems much
> more elegant and robust for cooperating modules but this semantic isn't
> supported (in fact the leading dot syntax completely confuses
> PyCapsule_Import, doc should clarify this).
>
> 5. The requirement that a module specifies it's name as unqualified when
> it is initializing but then also has to use a fully qualified package name
> for PyCapsule_New, both of which occur inside the same initialization
> function seems like an odd inconsistency (documentation clarification would
> help here). Also, depending on your point of view package names could be
> considered a deployment/packaging decision, a module obtains it's fully
> qualified name by virtue of it's position in the filesystem, something at
> compile time the module will not be aware of, another reason why relative
> imports make sense. Note the identical comment regarding _Py_PackageContext
> in  modsupport.c (Py2) and moduleobject.c (Py3) regarding how a module
> obtains it's fully qualified package name (see item 1).
>
> Thanks!
>
> --
> John
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/larry%40hastings.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150726/3b6c0ed8/attachment.html>

From ncoghlan at gmail.com  Sun Jul 26 17:33:56 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 27 Jul 2015 01:33:56 +1000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
Message-ID: <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>

On 26 July 2015 at 18:12, Lennart Regebro <regebro at gmail.com> wrote:
> On Sun, Jul 26, 2015 at 8:05 AM, Tim Peters <tim.peters at gmail.com> wrote:
>> The Python docs also are quite clear about that all arithmetic within
>> a single timezone is "naive".  That was intentional.  The _intended_
>> way to do "aware" arithmetic was always to convert to UTC, do the
>> arithmetic, then convert back.
>
> We can't explicitly implement incorrect timezone aware arithmetic and
> then expect people to not use it. We can make the arithmetic correct,
> and we can raise an error when doing tz-aware arithmetic in a
> non-fixed timezone. But having an implementation we know is incorrect
> and telling people "don't do that" doesn't seem like a good solution
> here.
>
> Why do we even have timezone aware datetimes if we don't intend them
> for usage? There could just be naive datetimes, and timezones, and let
> strftime take a timezone that is used when formatting. And we could
> make date-time creation into a function that parses data including a
> timezone, and returns the UTC time of that data.
>
> But then again, if we do that, we could just as well have that
> timezone as an attribute on the datetime object, and let strftime use
> so it doesn't have to be passed in. And we could let the __init__ of
> the datetime take a timezone and do that initial conversion to UTC.

I think we need to make sure to separate out the question of the
semantic model presented to users from the internal implementation
model here.

As a user, if the apparent semantics of time zone aware date time
arithmetic are accurately represented by "convert time to UTC ->
perform arithmetic -> convert back to stated timezone", then I *don't
care* how that is implemented internally.

This is the aspect Tim is pointing out is a change from the original
design of the time zone aware arithmetic in the datetime module. I
personally think its a change worth making that reflects additional
decades of experience with time zone aware datetime arithmetic, but
the PEP should be clear that it *is* a change.

As Alexander points out, the one bit of information which needs to be
provided by me as a *user* of such an API (rather than its
implementor), is how to handle ambiguities in the initial conversion
to UTC (whether to interpret any ambiguous time reference I supply as
a pre-rollback or post-rollback time). Similarly, the API needs to
tell *me* whether a returned time in a period of ambiguity is
pre-rollback or post-rollback. At the moment the "pre-rollback" flag
is specifically called "is_dst", since rolling clocks back at the end
of DST period is the most common instance of ambiguous times. That
then causes confusion since "DST" in common usage refers to the entire
period from the original roll forward to the eventual roll back, but
the extra bit is only relevant to time zone arithmetic during the
final two overlapping hours when the clocks are rolled back each year
(and is in fact relevant any time a clock rollback occurs, even if the
reason for the rollback has nothing to do with DST).

The above paragraphs represent the full extent of my *personal*
interest in the matter of the datetime module changing the way it
handles timezones - I think there's a right answer from a usability
perspective, and I think it involves treating UTC as the universal
time zone used for all datetime arithmetic, and finding a less
confusing name for the "isdst" flag (such as "prerollback", or
inverting the sense of it to "postrollback", such that 0/False
referred to the first time encountered, and 1/True referred to the
second time encountered).

There's a *separate* discussion, which relates to how best to
*implement* those semantics, given the datetime module implementation
we already have. For the original decimal module, we went with the
approach of storing the data in a display friendly format, and then
converting it explicitly as needed to and from a working
representation for arithmetic purposes. While it seems plausible to me
that such an approach may also work well for datetime arithmetic that
presents the appearance of all datetime arithmetic taking place in
terms of UTC, that's a guess based on general principles, not
something based on a detailed knowledge of datetime in particular
(and, in particular, with no knowledge of the performance
consequences, or if we have any good datetime focused benchmarks akin
to the telco benchmark that guided the original decimal module
implementation).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From berker.peksag at gmail.com  Sun Jul 26 17:39:47 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Sun, 26 Jul 2015 18:39:47 +0300
Subject: [Python-Dev] Burning down the backlog.
In-Reply-To: <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>
References: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
 <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>
Message-ID: <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>

On Sun, Jul 26, 2015 at 2:58 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 25 July 2015 at 20:28, Robert Collins <robertc at robertcollins.net> wrote:
>> Those charts doesn't show patches in 'commit-review' -
>> http://bugs.python.org/issue?%40columns=title&%40columns=id&stage=5&%40columns=activity&%40sort=activity&status=1&%40columns=status&%40pagesize=50&%40startwith=0&%40sortdir=on&%40action=search
>>
>> There are only 45 of those patches.
>>
>> AIUI - and I'm very new to core here - anyone in triagers can get
>> patches up to commit-review status.
>>
>> I think we should set a goal to keep inventory low here - e.g. review
>> and either bounce back to patch review, or commit, in less than a
>> month. Now - a month isn't super low, but we have lots of stuff
>> greater than a month.
>
> I'm not actually clear what "Commit Review" status means. I did do a
> quick check of the dev guide, and couldn't come up with anything,

https://docs.python.org/devguide/triaging.html#stage

From ncoghlan at gmail.com  Sun Jul 26 17:51:08 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 27 Jul 2015 01:51:08 +1000
Subject: [Python-Dev] PyCapsule_Import semantics, relative imports,
 module names etc.
In-Reply-To: <CAOBd=7nNRFug7eh_EOfp_oGMCVqVo_Vp66hm_csj=PvvxTVprA@mail.gmail.com>
References: <55B2CD3B.6000708@redhat.com>
 <CAOBd=7nNRFug7eh_EOfp_oGMCVqVo_Vp66hm_csj=PvvxTVprA@mail.gmail.com>
Message-ID: <CADiSq7eRX33CmyksJwJD3ALfh-URWOCMQ49baarvsU0kM1iH6A@mail.gmail.com>

On 27 July 2015 at 01:21, Larry Hastings <larry at hastings.org> wrote:
>
> PyCapsule_Import() is a simple helper function, a slightly-updated analogue
> to PyCObject_Import().  It's not particularly sophisticated, and I'm not
> surprised it's bewildered by complicated scenarios like relative imports in
> subpackages.  For now all I can recommend is that you not try and torture
> PyCapsule_Import().  And, as always... patches welcome.

In this case, there are actually a lot of limitations related to the
fact that extension modules generally have far more limited
information about where they live in the package hierarchy than normal
Python modules do. PEP 489 addressed quite a few of those with
multi-phase initialisation.

> On Sat, Jul 25, 2015 at 1:41 AM, John Dennis <jdennis at redhat.com> wrote:
>>
>> While porting several existing CPython extension modules that form a
>> package to be 2.7 and 3.x compatible the existing PyObject_* API was
>> replaced with PyCapsule_*. This introduced some issues the existing CPython
>> docs are silent on. I'd like clarification on a few issues and wish to raise
>> some questions.
>>
>> 1. Should an extension module name as provided in PyModule_Create (Py3) or
>> Py_InitModule3 (Py2) be fully package qualified or just the module name? I
>> believe it's just the module name (see item 5 below) Yes/No?

Fully qualified is generally better (if you know the ultimate
location), but it's mainly for introspection support, so most things
will work fine even if you set the name to something like "<this is
mostly ignored>".

>> 2. PyCapsule_Import does not adhere to the general import semantics. The
>> module name must be fully qualified, relative imports are not supported.

Correct, as it has no knowledge of the current module name to anchor a
relative import.

>> 3. PyCapsule_Import requires the package (e.g. __init__.py) to import
>> *all* of it's submodules which utilize the PyCapsule mechanism preventing
>> lazy on demand loading. This is because PyCapsule_Import only imports the
>> top level module (e.g. the package). From there it iterates over each of the
>> module names in the module path. However the parent module (e.g. globals)
>> will not contain an attribute for the submodule unless it's already been
>> loaded. If the submodule has not been loaded into the parent
>> PyCapsule_Import throws an error instead of trying to load the submodule.
>> The only apparent solution is for the package to load every possible
>> submodule whether required or not just to avoid a loading error. The
>> inability to load modules on demand seems like a design flaw and change in
>> semantics from the prior use of PyImport_ImportModule in combination with
>> PyObject. [One of the nice features with normal import loading is setting
>> the submodule name in the parent, the fact this step is omitted is what
>> causes PyCapsule_Import to fail unless all submodules are unconditionally
>> loaded). Shouldn't PyCapsule_Import utilize PyImport_ImportModule?

This sounds like it may be a bug in PyCapsule_Import, but I don't know
the capsule API very well myself (I've never had a reason to use it -
all the extension modules I've worked with personally have been
self-contained).

>> 4. Relative imports seem much more useful for cooperating submodules in a
>> package as opposed to fully qualified package names. Being able to import a
>> C_API from the current package (the package I'm a member of) seems much more
>> elegant and robust for cooperating modules but this semantic isn't supported
>> (in fact the leading dot syntax completely confuses PyCapsule_Import, doc
>> should clarify this).

Until PEP 489 (multi-phase initialisation) was implemented for Python
3.5, extension modules didn't know their actual runtime place in the
module hierarchy, so there was no easy way to provide a module name to
the API to anchor relative lookups.

Given PEP 489, it may be feasible to offer a PyCapsule_ImportRelative
for 3.6+, but it would require someone interested in working through
the details of such an API.

>> 5. The requirement that a module specifies it's name as unqualified when
>> it is initializing but then also has to use a fully qualified package name
>> for PyCapsule_New, both of which occur inside the same initialization
>> function seems like an odd inconsistency (documentation clarification would
>> help here). Also, depending on your point of view package names could be
>> considered a deployment/packaging decision, a module obtains it's fully
>> qualified name by virtue of it's position in the filesystem, something at
>> compile time the module will not be aware of, another reason why relative
>> imports make sense. Note the identical comment regarding _Py_PackageContext
>> in  modsupport.c (Py2) and moduleobject.c (Py3) regarding how a module
>> obtains it's fully qualified package name (see item 1).

Yes, these weird limitations were the genesis of Petr Viktorin's
efforts in implementing a new approach to import extension modules for
Python 3.5: https://www.python.org/dev/peps/pep-0489/

While the old single-phase initialisation mechanism is still supported
for backwards compatibility, the new multi-phase initialisation
approach brings the capabilities of extension modules much closer to
their pure Python counterparts.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From alexander.belopolsky at gmail.com  Sun Jul 26 18:54:18 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sun, 26 Jul 2015 12:54:18 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
Message-ID: <CAP7h-xZgpK8jJp48CQtvnaWqjCjzdAPWn4OijzNwGCn4hqqtjA@mail.gmail.com>

On Sun, Jul 26, 2015 at 11:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> As a user, if the apparent semantics of time zone aware date time
> arithmetic are accurately represented by "convert time to UTC ->
> perform arithmetic -> convert back to stated timezone", then I *don't
> care* how that is implemented internally.
>
> This is the aspect Tim is pointing out is a change from the original
> design of the time zone aware arithmetic in the datetime module. I
> personally think its a change worth making that reflects additional
> decades of experience with time zone aware datetime arithmetic, but
> the PEP should be clear that it *is* a change.
>

These semantics are already available in python 3:

>>> t = datetime(2015, 3, 7, 17, tzinfo=timezone.utc).astimezone()
>>> t.strftime('%D %T %z %Z')
'03/07/15 12:00:00 -0500 EST'
>>> (t+timedelta(1)).strftime('%D %T %z %Z')
'03/08/15 12:00:00 -0500 EST'   # a valid time, but not what you see on the
wall clock
>>> (t+timedelta(1)).astimezone().strftime('%D %T %z %Z')
'03/08/15 13:00:00 -0400 EDT'   # this is what the wall clock would show

Once CPython starts vendoring a complete timezone database, it would be
trivial to extend .astimezone() so that things like
t.astimezone('US/Eastern')
work as expected.

What is somewhat more challenging, is implementing a tzinfo subclass that
can be used
to construct datetime instances with the following behavior:

>>> t = datetime(2015, 3, 7, 12, tzinfo=timezone('US/Eastern'))
>>> t.strftime('%D %T %z %Z')
'03/07/15 12:00:00 -0500 EST'
>>> (t + timedelta(1)).strftime('%D %T %z %Z')
'03/08/15 12:00:00 -0400 EDT'

The solution to this problem has been provided as a documentation example
[1] for many years,
but also for many years it contained a subtle bug [2] which illustrates
that one has to be careful
implementing those things.

Although the examples [1] in the documentation only cover simple US
timezones, they cover
a case of changing DST rules and changing STD rules can be implemented
similarly.

Whether we want such tzinfo implementations in stdlib, is a valid question,
but it should be
completely orthogonal to the question of vendoring a TZ database.

If we agree that vendoring a TZ database is a good thing, we can make
.astimezone() understand how to construct a fixed offset timezone from a
location
and call it a day.

[1]:
https://hg.python.org/cpython/file/default/Doc/includes/tzinfo-examples.py
[2]: http://bugs.python.org/issue9063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150726/777fd985/attachment.html>

From alexander.belopolsky at gmail.com  Sun Jul 26 20:14:32 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sun, 26 Jul 2015 14:14:32 -0400
Subject: [Python-Dev] Burning down the backlog.
In-Reply-To: <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>
References: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
 <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>
 <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>
Message-ID: <CAP7h-xatryU7VJjuS6oJ=rQ3DbPj0kq8au89E3vg7YtLG17mpA@mail.gmail.com>

On Sun, Jul 26, 2015 at 11:39 AM, Berker Peksa? <berker.peksag at gmail.com>
wrote:

> > I'm not actually clear what "Commit Review" status means. I did do a
> > quick check of the dev guide, and couldn't come up with anything,
>
> https://docs.python.org/devguide/triaging.html#stage


What is probably missing from the dev-guide is an explanation that stages
do not necessarily
happen in the linear order.  For example, a committer may reset the stage
back to "needs a
patch" if the patch does not pass a "commit review".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150726/b8f75622/attachment.html>

From p.f.moore at gmail.com  Sun Jul 26 23:59:51 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 26 Jul 2015 22:59:51 +0100
Subject: [Python-Dev] Burning down the backlog.
In-Reply-To: <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>
References: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
 <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>
 <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>
Message-ID: <CACac1F9zEiafjQqVdaxV16CWTnQHRx2amZvVCsL77UnejQSg=A@mail.gmail.com>

On 26 July 2015 at 16:39, Berker Peksa? <berker.peksag at gmail.com> wrote:
>> I'm not actually clear what "Commit Review" status means. I did do a
>> quick check of the dev guide, and couldn't come up with anything,
>
> https://docs.python.org/devguide/triaging.html#stage

Thanks, I missed that. The patches I checked seemed to have been
committed and were still at commit review, though. Doesn't the roundup
robot update the stage when there's a commit? (Presumably not, and
people forget to do so too).

Paul

From p.f.moore at gmail.com  Mon Jul 27 00:15:14 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 26 Jul 2015 23:15:14 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
Message-ID: <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>

On 26 July 2015 at 16:33, Nick Coghlan <ncoghlan at gmail.com> wrote:
> As a user, if the apparent semantics of time zone aware date time
> arithmetic are accurately represented by "convert time to UTC ->
> perform arithmetic -> convert back to stated timezone", then I *don't
> care* how that is implemented internally.
>
> This is the aspect Tim is pointing out is a change from the original
> design of the time zone aware arithmetic in the datetime module. I
> personally think its a change worth making that reflects additional
> decades of experience with time zone aware datetime arithmetic, but
> the PEP should be clear that it *is* a change.

I think the current naive semantics are useful and should not be
discarded lightly. At an absolute minimum, there should be a clear,
documented way to get the current semantics under any changed
implementation.

As an example, consider an alarm clock. I want it to go off at 7am
each morning. I'd feel completely justified in writing tomorrows_alarm
= todays_alarm + timedelta(days=1).

If the time changes to DST overnight, I still want the alarm to go off
at 7am. Even though +1 day is in this case actually + 25 (or is it
23?) hours. That's the current semantics.

To be honest, I would imagine, from experience with programmers
writing naive algorithms, that the current semantics is a lot less
prone to error when used by such people. People forget about timezones
until they are bitten by them, and if they are using the convert to
UTC->calculate->convert back model, their code ends up with
off-by-1-hour bugs. Certainly such mistakes can be fixed, and the
people who make them educated, but I like the fact that Python's
typical behaviour is to do what a non-expert would expect. By all
means have the more sophisticated approach available, but if it's the
default then naive users have to either (1) learn the subtleties of
timezones, or (2) learn how to code naive datetime behaviour in Python
before they can write their code. If the current behaviour remains the
default, then *when* the naive user learns about the subtleties of
timezones, they can switch to the TZ-aware datetime - but that's a
single learning step, and it can be taken when the user is ready.

Paul

PS I don't think the above is particularly original - IIRC, it's
basically Guido's argument for naive datetimes from when they were
introduced. I think his example was checking his watch while on a
transatlantic plane flight, but the principle is the same.

From breamoreboy at yahoo.co.uk  Mon Jul 27 00:23:07 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Sun, 26 Jul 2015 23:23:07 +0100
Subject: [Python-Dev] Burning down the backlog.
In-Reply-To: <CACac1F9zEiafjQqVdaxV16CWTnQHRx2amZvVCsL77UnejQSg=A@mail.gmail.com>
References: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
 <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>
 <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>
 <CACac1F9zEiafjQqVdaxV16CWTnQHRx2amZvVCsL77UnejQSg=A@mail.gmail.com>
Message-ID: <mp3mkd$vu6$1@ger.gmane.org>

On 26/07/2015 22:59, Paul Moore wrote:
> On 26 July 2015 at 16:39, Berker Peksa? <berker.peksag at gmail.com> wrote:
>>> I'm not actually clear what "Commit Review" status means. I did do a
>>> quick check of the dev guide, and couldn't come up with anything,
>>
>> https://docs.python.org/devguide/triaging.html#stage
>
> Thanks, I missed that. The patches I checked seemed to have been
> committed and were still at commit review, though. Doesn't the roundup
> robot update the stage when there's a commit? (Presumably not, and
> people forget to do so too).
>
> Paul

I wouldn't know.  I certainly believe that the more time we spend 
assisting Cannon, Coghlan & Co on the core workflow, the quicker, in the 
medium to long term, we put the backlog of issues to bed.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From rdmurray at bitdance.com  Mon Jul 27 03:37:37 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 26 Jul 2015 21:37:37 -0400
Subject: [Python-Dev] Burning down the backlog.
In-Reply-To: <CACac1F9zEiafjQqVdaxV16CWTnQHRx2amZvVCsL77UnejQSg=A@mail.gmail.com>
References: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
 <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>
 <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>
 <CACac1F9zEiafjQqVdaxV16CWTnQHRx2amZvVCsL77UnejQSg=A@mail.gmail.com>
Message-ID: <20150727013741.87E48B14152@webabinitio.net>

On Sun, 26 Jul 2015 22:59:51 +0100, Paul Moore <p.f.moore at gmail.com> wrote:
> On 26 July 2015 at 16:39, Berker Peksa?? <berker.peksag at gmail.com> wrote:
> >> I'm not actually clear what "Commit Review" status means. I did do a
> >> quick check of the dev guide, and couldn't come up with anything,
> >
> > https://docs.python.org/devguide/triaging.html#stage
> 
> Thanks, I missed that. The patches I checked seemed to have been
> committed and were still at commit review, though. Doesn't the roundup
> robot update the stage when there's a commit? (Presumably not, and
> people forget to do so too).

Yes, it is manual.  Making it automatic would be nice.  Patches accepted
:) Writing a Roundup detector for this shouldn't be all that hard once
you figure out how detectors work.  See:

    http://www.roundup-tracker.org/docs/customizing.html#detectors-adding-behaviour-to-your-tracker

The steep part of the curve there is testing your work, which is
something some effort has been made to simplify, but unfortunately I'm
not up on the details of that currently.

In the meantime, this is a service triagers could perform: look at the
commit review issues and make sure that really is the correct stage.

Now, as for the original question:

First, a little history so that the old timers and the newer committers
are on the same page.  When 'commit review' was originally introduced,
what it was used for was for what was then a "second committer" required
review during the RC phase.  I have recently (last two years?) with
agreement of the workflow list and with no objection from committers
shifted this to the model documented in the devguide currently.

However, I agree that what is currently in the devguide is not
sufficient.  Here is my actual intent for the workflow:

1) Issue is opened.  Triager/committer sets it to 'patch needed' if they
believe the bug should be fixed/feature implemented.  (A committer may
choose to override a triager decision and close the bug, explaining why
for the benefit of the triager and all onlookers.)

2) Once we have a patch, one or more triage or committer people work
with the submitter or whoever is working on the patch (who may have no
special role or be a triager or be a committer) in a patch
review-and-update cycle until a triager or a committer thinks it is
ready for commit.

3) If the patch was submitted and/or worked on by a committer, the patch
can be committed.

4) If the patch is not by a committer, the stage should be set to
'commit review' by a triager.  Committers with time available should, as
Robert suggests, look for patches in 'commit review' status *and review
them*.  The wording of "a quick once over" in the devguide isn't
*wrong*, but it does give the impression the patch is "ready to commit",
whereas the goal here is to review the work of the *triager*.  If the
patch is not actually commit ready for whatever reason, it gets bounced
back to patch review with an explanation as to why.

5) Eventually (hopefully the first time or quickly thereafter most of
the time!) the patch really is ready to commit and gets committed.

An here, to my mind, is the most important bit:

6) When the patches moved to commit ready by a given triager are
consistently committable after the step 4 review, it is time to offer
that triager commit privileges.

My goal here is to *transfer* the knowledge of what makes a good review
process and a good patch from the existing committers to new committers,
and therefore acquire new committers.

Now, the problem that Paul cites about not feeling comfortable with the
*commit* process is real (although I will say that at this point I can
go months without doing a commit and I still remember quite clearly how
to do one; it isn't that complicated).  Improving the tooling is one way
to attack that.  I think there can be two types of tooling:  the large
scale problem the PEPs are working toward, and smaller scale helper
scripts such as Paul mentions that one or more committers could develop
and publish (patchcheck on steroids).

Before that, though, it is clear that the devguide needs a "memory
jogger" cheat sheet on how to do a multi-branch commit, linked from
the quicklinks section.

So, I'm hoping Carol will take what I've written above and turn it into
updates for the devguide (assuming no one disagrees with what I've said :)

--David

From tim.peters at gmail.com  Mon Jul 27 04:04:51 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 26 Jul 2015 21:04:51 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
Message-ID: <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>

[Paul Moore <p.f.moore at gmail.com>]
> I think the current naive semantics are useful and should not be
> discarded lightly. At an absolute minimum, there should be a clear,
> documented way to get the current semantics under any changed
> implementation.

Realistically, default arithmetic behavior can't change in Python 3
(let alone Python 2).  Pushing for a different design is fine, but
that can't be sold on the grounds that current behavior is "a bug" -
it's working as designed, as intended, and as documented, and hasn't
materially changed in the dozen-or-so years since it was introduced.
It's not even that the proposed alternative arithmetic is "better",
either:  while it's certainly more suitable for some applications,
it's certainly worse for others.  Making an incompatible change would
be (& should be) a hard sell even if there were a much stronger case
for it than there is here.

But that's just arithmetic.  Some way to disambiguate local times, and
support for most zoneinfo time zones, are different issues.


> As an example, consider an alarm clock. I want it to go off at 7am
> each morning. I'd feel completely justified in writing tomorrows_alarm
> = todays_alarm + timedelta(days=1).
>
> If the time changes to DST overnight, I still want the alarm to go off
> at 7am. Even though +1 day is in this case actually + 25 (or is it
> 23?) hours. That's the current semantics.

There was a long list of use cases coming to the same conclusion.  The
current arithmetic allows uniform patterns in local time to be coded
in uniform, straightforward ways.  Indeed, in "the obvious" ways.  The
alternative behavior favors uniform patterns in UTC, but who cares?
;-)  Few local clocks show UTC.  Trying to code uniform local-time
behaviors using "aware arithmetic" (which is uniform in UTC. but may
be "lumpy" in local time) can be a nightmare.

The canonical counterexample is a nuclear reactor that needs to be
vented every 24 hours.  To which the canonical rejoinder is that the
programmer in charge of that system is criminally incompetent if
they're using _any_ notion of time other than UTC ;-)

> To be honest, I would imagine, from experience with programmers
> writing naive algorithms, that the current semantics is a lot less
> prone to error when used by such people. People forget about timezones
> until they are bitten by them, and if they are using the convert to
> UTC->calculate->convert back model, their code ends up with
> off-by-1-hour bugs. Certainly such mistakes can be fixed, and the
> people who make them educated, but I like the fact that Python's
> typical behaviour is to do what a non-expert would expect. By all
> means have the more sophisticated approach available, but if it's the
> default then naive users have to either (1) learn the subtleties of
> timezones, or (2) learn how to code naive datetime behaviour in Python
> before they can write their code. If the current behaviour remains the
> default, then *when* the naive user learns about the subtleties of
> timezones, they can switch to the TZ-aware datetime - but that's a
> single learning step, and it can be taken when the user is ready.

There is a design flaw here, IMO:  when they switch to a TZ-aware
datetime, they _still_ get "naive" arithmetic within that time zone.
It's at best peculiar that such a datetime is _called_ "aware" yet
still ignores the time zone rules when doing arithmetic.  I would have
preferred a sharper distinction, like "completely naive" (tzinfo
absent) versus "completely aware" (tzinfo present).  But, again, it's
working as designed, intended and documented.

One possibility to get "the other" behavior in a backward-compatible
way:  recognize a new magic attribute on a tzinfo instance, say,
__aware_arithmetic__.  If it's present, arithmetic on a datetime with
such a tzinfo member "acts as if" arithmetic were done by converting
to UTC first, doing the arithmetic, then converting back.  Otherwise
(magic new attribute not present) arithmetic remains naive.  Bonus:
then you could stare at datetime code and have no idea which kind of
arithmetic is being used ;-)

> PS I don't think the above is particularly original - IIRC, it's
> basically Guido's argument for naive datetimes from when they were
> introduced. I think his example was checking his watch while on a
> transatlantic plane flight, but the principle is the same.

Yup, your account is fair (according to me ;-) ).  Here's Guido's
first message on the topic:

https://mail.python.org/pipermail/python-dev/2002-March/020648.html

From ncoghlan at gmail.com  Mon Jul 27 04:40:10 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 27 Jul 2015 12:40:10 +1000
Subject: [Python-Dev] Burning down the backlog.
In-Reply-To: <20150727013741.87E48B14152@webabinitio.net>
References: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
 <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>
 <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>
 <CACac1F9zEiafjQqVdaxV16CWTnQHRx2amZvVCsL77UnejQSg=A@mail.gmail.com>
 <20150727013741.87E48B14152@webabinitio.net>
Message-ID: <CADiSq7eP0Pwg4Vu_+CkFuKv_XteF7jZ+hkLHYt8J5r7WD_s6hw@mail.gmail.com>

On 27 July 2015 at 11:37, R. David Murray <rdmurray at bitdance.com> wrote:
> My goal here is to *transfer* the knowledge of what makes a good review
> process and a good patch from the existing committers to new committers,
> and therefore acquire new committers.

+1000 :)

A few years back, I wrote this patch review guide for work:
https://beaker-project.org/dev/guide/writing-a-patch.html#reviewing-a-patch

Helping to create a similarly opinionated guide to assist reviewers
for CPython has been kicking around on my todo list ever since, but
it's a lot easier to create that kind of guide when you're the
appointed development lead on a relatively small project produced
almost entirely through paid development - I wrote it one afternoon,
uploaded it to gerrit.beaker-project.org, and the only folks I needed
to get to review it were the other full-time developers on the Beaker
team.

I don't think that would be the right way to create such a guide for a
volunteer driven project like CPython, but steering a more
collaborative community discussion would require substantially more
time than it took me to put the Beaker one together.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From tim.peters at gmail.com  Mon Jul 27 08:04:03 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 01:04:03 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
Message-ID: <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>

[Tim]
>> The Python docs also are quite clear about that all arithmetic within
>> a single timezone is "naive".  That was intentional.  The _intended_
>> way to do "aware" arithmetic was always to convert to UTC, do the
>> arithmetic, then convert back.

[Lennart]
> We can't explicitly implement incorrect timezone aware arithmetic and
> then expect people to not use it.

Python didn't implement timezone-aware arithmetic at all within a
single time zone.  Read what I wrote just above.  It implements naive
arithmetic within a single time zone.

> We can make the arithmetic correct,

The naive arithmetic within a timezone is already correct, by its own
internal criteria.  It's also useful (see the original discussions, or
Paul Moore's recent brief account).  That it's not the arithmetic you
want doesn't make it "incorrect", it makes it different from what you
want.  That's fine - you're allowed to want anything ;-)  But it's a
dozen years too late to change that decision.  Maybe for Python 4.

> and we can raise an error when doing tz-aware arithmetic in a
> non-fixed timezone.

Sorry, I don't know what that means.  Under any plausible
interpretation, I don't see any need to raise an exception.

> But having an implementation we know is incorrect

You really have to get over insisting it's incorrect.  It's
functioning exactly the way it was intended to function.  It's
_different_ from what you favor.  Note that I'm not calling what you
favor "incorrect".  It's different.  Both kinds of arithmetic are
useful for different purposes, although I still agree with Guido's
original belief that the current arithmetic is most useful most often
for most programmers.

> and telling people "don't do that" doesn't seem like a good solution
> here.

We don't tell people "don't do that".  It's perfectly usable exactly
as-is for many applications.  Not all.  For those applications needing
the other kind of arithmetic, the convert-to/from-UTC dance was the
intended solution.

> Why do we even have timezone aware datetimes if we don't intend them
> for usage?

They are intended for usage.  But a single way of using them is not
suitable for all possible applications.

>> ...
>> Python's datetime never intended to support that directly.

> I think it should.

Ya, I picked that up ;-)  I don't, but it's too late to break backward
compatibility regardless.

> It's expected that it supports it,

By some people, yes.  Not by all.

> and there is no real reason not to support it.

Backward compatibility is a gigantic reason to continue with the
status quo.  See Paul Moore's post for a start on why naive arithmetic
was picked to begin with.

> The timezone handling becomes complicated if you base yourself on
> localtime, and simple if you base yourself on UTC.

That's an implementation detail unrelated (in principle) to how
arithmetic works.  Although as a practical matter it cuts both ways:
naive local-time arithmetic is complicated if the internal time is
stored in UTC, but simple if stored in local time.

> As you agree, we recommend to people to use UTC at all times,

I recommend people don't use tzinfo at all if they can avoid it.
Beyond that, there are many attractions to using UTC, and to
explicitly use UTC.  Not all applications need to care, though.

> and only use timezones for input and output. Well, what I'm now
> proposing is to take that recommendation to heart, and change
> datetime's implementation so it does exactly that.

Suppose I'm correct in my belief that there's scant chance of getting
approval for changing the default datetime arithmetic in Python 3 (or
Python 2).  Would you still be keen to replace the internals with UTC
format?  Note that there are many consequences to that implementation
detail.  For example, it was an explicit requirement of the datetime
design that the month, day, hour, minute and second components be very
cheap to extract.  If you have to do conversion every time one is
accessed, it's much slower; if you cache the "local time" components
separately, the memory burden increases.  Etc.

> I saw the previous mention of "pure" vs "practical", and that is often
> a concern. Here it clearly is not. This is a choice between impure,
> complicated and impractical, and pure, simple and practical.

There is nothing in the datetime world simpler than naive arithmetic
;-)  "Practical" is relevant to a specific application's specific
needs, and neither kind of arithmetic is "practical" for all
applications.  Guido believed naive arithmetic is most practical
overall.  But even believing that too, datetime certainly "should be"
beefed up to solve the _other_ problems:  like resolving ambiguous
times, and supporting the full range of zoneinfo possibilities

>> Is it the case that pytz also "fails" in the cases your attempts "fail"?

> No, that is not the case. And if you wonder why I just don't do it
> like pytz does it, it's because that leads to infinite recursion, much
> as discussions on this mailing list does. ;-) And this is because we
> need to normalize the datetime after arithmatic, but normalizing is
> arithmetics.

If I could talk you out of trying to "fix" the arithmetic, all those
headaches would go away and you could make swift progress on what
remains.  But I can't, so I won't try again ;-)

>> Ah, but it already happens that way

> No, in fact it does not.

Yes, it does.  But rather than repeat it all again, go back to the
original message.  I quoted the relevant Python docs in full, and
they're telling the truth.  They're talking about what happens _in a
single time zone_.  You go on to mix time zones again, and that's
_not_ what the docs are talking about.  Obviously, two times "an hour
apart" on a local clock may or may not be an hour apart in UTC, and
vice versa.

The real problem here, I suspect, is that I keep talking about naive
arithmetic, and you keep reading it as "an utterly broken
implementation of what I really want".  But neither what Python does,
_nor_ what you want, is "correct" or "incorrect".  They're different.
They're each consistent within their own view of the world.

> ...
> It's not a question of changing datetime arithmetic per se. The PEP
> does indeed mean it has to be changed, but only to support ambiguous
> and non-existent times.

The latter have nothing to do with arithmetic.  For example, in US
Eastern 2:37 AM doesn't exist on the local clock on the day DST
begins, and 1:48 AM is ambiguous on the day DST ends.  See?  Not one
word about arithmetic.  Those are just plain facts about how US
Eastern works, so datetime could address them even if no user-visible
datetime arithmetic of any kind were supported.  Naive arithmetic
doesn't care about them, but they're still potential issues when
converting to/from other time zones (and language-supplied conversions
have nothing to do with user-visible arithmetic semantics either).

> It's helpful to me to understand, which I hadn't done before, that
> this was never intended to work. That helps me argue for changing
> datetimes internal implementation, once I get time to do that. (I'm
> currently moving, renovating a new house, trying fix up a garden that
> has been neglected for years, and insanely, write my own code editor,
> all at the same time, so it won't be anytime soon).

If I were you, I'd work on the code editor.  That sounds like the most
fun, and moving sounds like the least fun ;-)

> The "changing arithmetic" discussion is a red herring.

I'm afraid it's crucial:  the prospect of breaking programs (by
changing arithmetic) that have worked for a dozen+ years is a major
problem.  If, e.g., some program "adds a week" to a datetime to
schedule a new meeting "at the same time" next week, and that's
suddenly off by an hour (one way or the other) because a DST
transition just happened to occur across that week, people would
rightfully scream bloody murder.  Many cases like that "just work"
_because_ single-zone arithmetic is naive.  With "your kind" of
arithmetic, conceptually trivial cases like that become a real pain in
the ass to program correctly (not a coincidence:  they're conceptually
trivial because "adding a week" is, to virtually everyone's mind, an
instance of naive datetime arithmetic - they're certainly not thinking
anything akin to "what I really want is to convert to UTC, add 168
hours, and convert back again", and they don't want the _result_ of
doing that either).

So if you're determined to change arithmetic, it will have to be done
in a backward-compatible way (and I briefly sketched such a way in an
earlier message today).

> Now my wife insist I help her pack, so this is the end of this
> discussion for me. If i continue it will be only as a part of
> discussing how we change how datetime works internally.

OK.  But do try to get some sleep too!  Sleep is good :-)

From regebro at gmail.com  Mon Jul 27 08:20:51 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 08:20:51 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
Message-ID: <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>

On Mon, Jul 27, 2015 at 12:15 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> I think the current naive semantics are useful and should not be
> discarded lightly. At an absolute minimum, there should be a clear,
> documented way to get the current semantics under any changed
> implementation.
>
> As an example, consider an alarm clock. I want it to go off at 7am
> each morning. I'd feel completely justified in writing tomorrows_alarm
> = todays_alarm + timedelta(days=1).

That's a calendar operation made with a timedelta. The "days"
attribute here is indeed confusing as it doesn't mean 1 day, it means
24 hours.

//Lennart

From regebro at gmail.com  Mon Jul 27 08:24:31 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 08:24:31 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
Message-ID: <CAL0kPAWf_6ZAeZRn46B5g2ZFzYeU5Cswi1xQDbph1h6mDiVA9g@mail.gmail.com>

On Mon, Jul 27, 2015 at 4:04 AM, Tim Peters <tim.peters at gmail.com> wrote:
> Realistically, default arithmetic behavior can't change in Python 3
> (let alone Python 2).

Then we can't implement timezones in a reasonable way with the current
API, but have to have something like pytz's normalize() function or
similar.

I'm sorry I've wasted everyones time with this PEP.

//Lennart

From tim.peters at gmail.com  Mon Jul 27 09:09:19 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 02:09:19 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
Message-ID: <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>

[Paul Moore <p.f.moore at gmail.com>]
>> ....
>> As an example, consider an alarm clock. I want it to go off at 7am
>> each morning. I'd feel completely justified in writing
>> tomorrows_alarm = todays_alarm + timedelta(days=1).

[Lennart Regebro <regebro at gmail.com>]
> That's a calendar operation made with a timedelta.

It's an instance of single-timezone datetime arithmetic, of the
datetime + timedelta form.  Your examples have been of the same form.
Note that after Paul's

     tomorrows_alarm = todays_alarm + timedelta(days=1)

it's guaranteed that

    assert tomorrows_alarm - todays_alarm == timedelta(days=1)

will succeed too.

> The "days" attribute here is indeed confusing as it doesn't mean 1 day,
> it means 24 hours.

Which, in naive arithmetic, are exactly the same thing.  That's
essentially why naive arithmetic is the default:  it doesn't insist on
telling people that everything they know is wrong ;-)  There's nothing
confusing about Paul's example _provided that_ single-timezone
arithmetic is naive.  It works exactly as he intends every time, and
obviously so.

Seriously, try this exercise:  how would you code Paul's example if
"your kind" of arithmetic were in use instead?  For a start, you have
no idea in advance how many hours you may need to add to get to "the
same local time tomorrow".  24 won't always work  Indeed, no _whole_
number of hours may work (according to one source I found, Australia's
Lord Howe Island uses a 30-minute DST adjustment).  So maybe you don't
want to do it by addition.  What then?  Pick apart the year, month and
day components, then simulate "naive arithmetic" by hand?

The point is that there's no _obvious_ way to do it then.  I'd
personally strip off the tzinfo member, leaving a wholly naive
datetime where arithmetic "works correctly" ;-) , add the day, then
attach the original tzinfo member again.

But for a dozen years it's sufficed to do what Paul did.

From regebro at gmail.com  Mon Jul 27 09:32:43 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 09:32:43 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
Message-ID: <CAL0kPAWMpBJab_mHG=VWxXEtTjCUqEPphdxUVxJ0EbAe_heTXw@mail.gmail.com>

On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters <tim.peters at gmail.com> wrote:
> It's an instance of single-timezone datetime arithmetic, of the
> datetime + timedelta form.

No, because in that case it would always move 24 hours, and it
doesn't. It sometimes moves 23 hours or 25 hours, when crossing a DST
border. That is a calendar operation, in the disguise of a datetime
arithmetic.

But this discussion is now moot, if we can't change this, then we
can't change this, and PEP431 is dead. The only reasonable way out if
this mess is a completely new module for dates and times that doesn't
make these kind of fundamental mistakes. I sincerely doubt I have the
time to implement that this decade.

//Lennart

From regebro at gmail.com  Mon Jul 27 09:34:38 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 09:34:38 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
Message-ID: <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>

On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters <tim.peters at gmail.com> wrote:
> But for a dozen years it's sufficed to do what Paul did.

No, it never did "suffice". It's just that people have been doing
various kinds of workarounds to compensate for these design flaws. I
guess they need to continue to do that for the time being.

//Lennart

From p.f.moore at gmail.com  Mon Jul 27 10:47:28 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2015 09:47:28 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
Message-ID: <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>

On 27 July 2015 at 08:34, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters <tim.peters at gmail.com> wrote:
>> But for a dozen years it's sufficed to do what Paul did.
>
> No, it never did "suffice". It's just that people have been doing
> various kinds of workarounds to compensate for these design flaws. I
> guess they need to continue to do that for the time being.

I'm confused by your position. If it's 7am on the clock behind me,
right now, then how (under the model proposed by the PEP) do I find
the datetime value where it will next be 7am on the clock?

I understand your point that "it's a calendar operation", but that
doesn't help me. I still don't know how you want me to *do* the
operation.

Whatever the outcome of this discussion, any PEP needs to explain how
to implement this operation, because at the moment, it's done with
+timedelta(days=1) and that won't be the case under the PEP. I'm not
trying to shoot down your proposal here, just trying to understand it.

Paul

From regebro at gmail.com  Mon Jul 27 10:54:02 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 10:54:02 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
Message-ID: <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>

On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> I'm confused by your position. If it's 7am on the clock behind me,
> right now, then how (under the model proposed by the PEP) do I find
> the datetime value where it will next be 7am on the clock?

PEP-431 does not propose to implement calendar operations, and hence
does not address that question.

//Lennart

From p.f.moore at gmail.com  Mon Jul 27 11:05:49 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2015 10:05:49 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
Message-ID: <CACac1F-qhQQG-yWytCYBQnFzVqxMLVRS-oWskKRxCLZ8XJ9XDw@mail.gmail.com>

On 27 July 2015 at 09:54, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> I'm confused by your position. If it's 7am on the clock behind me,
>> right now, then how (under the model proposed by the PEP) do I find
>> the datetime value where it will next be 7am on the clock?
>
> PEP-431 does not propose to implement calendar operations, and hence
> does not address that question.

OK, I see. But it does propose to remove that operation from datetime.
Thanks for the clarification.

Am I right to think that because you say "implement calendar
operations" this is not, as far as you are aware, something that
already exists in the stdlib (outside of datetime)? I'm certainly not
aware of an alternative way of doing it.

Paul

From regebro at gmail.com  Mon Jul 27 11:31:22 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 11:31:22 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F-qhQQG-yWytCYBQnFzVqxMLVRS-oWskKRxCLZ8XJ9XDw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <CACac1F-qhQQG-yWytCYBQnFzVqxMLVRS-oWskKRxCLZ8XJ9XDw@mail.gmail.com>
Message-ID: <CAL0kPAVUyYDiwgaJQUG0euLurY_+3YoY7A+OmCMV0giG-pt-=w@mail.gmail.com>

On Mon, Jul 27, 2015 at 11:05 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> Am I right to think that because you say "implement calendar
> operations" this is not, as far as you are aware, something that
> already exists in the stdlib (outside of datetime)? I'm certainly not
> aware of an alternative way of doing it.

Right, I think you need to use relativedelta (or rrule) from dateutil,
unless you want to do it yourself, which of course in most cases is
quite easy.

//Lennart

From jon+python-dev at unequivocal.co.uk  Mon Jul 27 12:15:53 2015
From: jon+python-dev at unequivocal.co.uk (Jon Ribbens)
Date: Mon, 27 Jul 2015 11:15:53 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
References: <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
Message-ID: <20150727101553.GO28550@unequivocal.co.uk>

On Mon, Jul 27, 2015 at 01:04:03AM -0500, Tim Peters wrote:
> [Tim]
> >> The Python docs also are quite clear about that all arithmetic within
> >> a single timezone is "naive".  That was intentional.  The _intended_
> >> way to do "aware" arithmetic was always to convert to UTC, do the
> >> arithmetic, then convert back.
> 
> [Lennart]
> > We can't explicitly implement incorrect timezone aware arithmetic and
> > then expect people to not use it.
> 
> Python didn't implement timezone-aware arithmetic at all within a
> single time zone.  Read what I wrote just above.  It implements naive
> arithmetic within a single time zone.

This usage of "time zone" is confusing. As far as I can tell, you
really mean "UTC offset". A time zone would be something like
"Europe/London", which has two different UTC offsets throughout
the year (not to mention other historical weirdnesses), whereas
arithmetic on a "timezone-aware" datetime is only going to work
so long as you don't cross any of the boundaries where the UTC
offset changes.

I agree with you about pretty much everything else about datetime,
just I find the terminology misleading. The only other thing I found
really weird about datetime is how Python 2 had no implementation of
a UTC tzinfo class, despite this being utterly trivial - but it's too
late to do anything about that now, of course.

From rdmurray at bitdance.com  Mon Jul 27 15:59:59 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 27 Jul 2015 09:59:59 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com> <CAL0
 kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
Message-ID: <20150727140000.75AA7B14150@webabinitio.net>

On Mon, 27 Jul 2015 02:09:19 -0500, Tim Peters <tim.peters at gmail.com> wrote:
> Seriously, try this exercise:  how would you code Paul's example if
> "your kind" of arithmetic were in use instead?  For a start, you have
> no idea in advance how many hours you may need to add to get to "the
> same local time tomorrow".  24 won't always work  Indeed, no _whole_
> number of hours may work (according to one source I found, Australia's
> Lord Howe Island uses a 30-minute DST adjustment).  So maybe you don't
> want to do it by addition.  What then?  Pick apart the year, month and
> day components, then simulate "naive arithmetic" by hand?
> 
> The point is that there's no _obvious_ way to do it then.  I'd
> personally strip off the tzinfo member, leaving a wholly naive
> datetime where arithmetic "works correctly" ;-) , add the day, then
> attach the original tzinfo member again.

I *think* I'd be happy with that solution.

I'm not sure if the opinion of a relatively inexperienced timezone user
(whose head hurts when thinking about these things) is relevant, but in
case it is:

My brief experience with pytz is that it gets this all "wrong".  (Wrong
is in quotes because it isn't wrong, it just doesn't match my use
cases).  If I add a timedelta to a pytz datetime that crosses the DST
boundary, IIRC I get something that still claims it is in the previous
"timezone" (which it therefore seemed to me was really a UTC offset),
and I have to call 'normalize' to get it to be in the correct "timezone"
(UTC offset).  I don't remember what that does to the time, and I have
no intuition about it (I just want it to do the naive arithmetic!)

This makes no sense to me, since I thought a tzinfo object was supposed
to represent the timezone including the DST transitions.  I presume this
comes from the fact that datetime does naive arithmetic and pytz is
trying to paste non-naive arithmetic on top?

So, would it be possible to take the timezone database support from
pytz, and continue to implement naive-single-zone arithmetic the way Tim
proposes, and have it automatically produce the correct UTC offset and
UTC-offset-label afterward, without a normalize call?  I assumed that
was what the PEP was proposing, but I never read it so I can't complain
that I was wrong :)

I have a feeling that I'm completely misunderstanding things, since
tzinfo is still a bit of a mystery to me.

Based on this discussion it seems to me that (1) datetime has to/should
continue to do naive arithmetic and (2) if you need to do non-naive UTC
based calculations (or conversions between timezones) you should be
converting to UTC *anyway* (explicit is better than implicit).  The
addition of the timezone DB would then give us the information to *add*
tools that do conversions between time zones &c.

At Tim says, the issue of disambiguation is separate, and I seem to
recall a couple of proposals from the last time this thread went around
for dealing with that.

--David

From steve at pearwood.info  Mon Jul 27 16:13:16 2015
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 28 Jul 2015 00:13:16 +1000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
Message-ID: <20150727141316.GA25179@ando.pearwood.info>

On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> > I'm confused by your position. If it's 7am on the clock behind me,
> > right now, then how (under the model proposed by the PEP) do I find
> > the datetime value where it will next be 7am on the clock?
> 
> PEP-431 does not propose to implement calendar operations, and hence
> does not address that question.

To me, Paul's example is a datetime operation: you start with a datetime 
(7am today), perform arithmetic on it by adding a period of time (one 
day), and get a datetime as the result (7am tomorrow).

To my naive mind, I would have thought of calendar operations to be 
things like:

- print a calendar;
- add or remove an appointment;
- send, accept or decline an invitation

What do you think calendar operations are, and how do they differ from 
datetime operations? And most importantly, how can we tell them apart?

Thanks,


-- 
Steve

From Steve.Dower at microsoft.com  Mon Jul 27 16:27:34 2015
From: Steve.Dower at microsoft.com (Steve Dower)
Date: Mon, 27 Jul 2015 14:27:34 +0000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <20150727141316.GA25179@ando.pearwood.info>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>,
 <20150727141316.GA25179@ando.pearwood.info>
Message-ID: <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>

Am I the only one feeling like this entire thread should be moved to python-ideas at this point?

Top-posted from my Windows Phone
________________________________
From: Steven D'Aprano<mailto:steve at pearwood.info>
Sent: ?7/?27/?2015 7:14
To: python-dev at python.org<mailto:python-dev at python.org>
Subject: Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> > I'm confused by your position. If it's 7am on the clock behind me,
> > right now, then how (under the model proposed by the PEP) do I find
> > the datetime value where it will next be 7am on the clock?
>
> PEP-431 does not propose to implement calendar operations, and hence
> does not address that question.

To me, Paul's example is a datetime operation: you start with a datetime
(7am today), perform arithmetic on it by adding a period of time (one
day), and get a datetime as the result (7am tomorrow).

To my naive mind, I would have thought of calendar operations to be
things like:

- print a calendar;
- add or remove an appointment;
- send, accept or decline an invitation

What do you think calendar operations are, and how do they differ from
datetime operations? And most importantly, how can we tell them apart?

Thanks,


--
Steve
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/a6a9dc38/attachment.html>

From rosuav at gmail.com  Mon Jul 27 16:34:01 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 28 Jul 2015 00:34:01 +1000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <20150727141316.GA25179@ando.pearwood.info>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
Message-ID: <CAPTjJmp2_OwuBGU8nZHkNL=d+LF8ba2vfd_K9fwcV9FCPN9Z1A@mail.gmail.com>

On Tue, Jul 28, 2015 at 12:13 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
>> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> > I'm confused by your position. If it's 7am on the clock behind me,
>> > right now, then how (under the model proposed by the PEP) do I find
>> > the datetime value where it will next be 7am on the clock?
>>
>> PEP-431 does not propose to implement calendar operations, and hence
>> does not address that question.
>
> To me, Paul's example is a datetime operation: you start with a datetime
> (7am today), perform arithmetic on it by adding a period of time (one
> day), and get a datetime as the result (7am tomorrow).
>
> To my naive mind, I would have thought of calendar operations to be
> things like:
>
> - print a calendar;
> - add or remove an appointment;
> - send, accept or decline an invitation
>
> What do you think calendar operations are, and how do they differ from
> datetime operations? And most importantly, how can we tell them apart?
>

Concrete example: I meet with my students on a weekly basis, with the
scheduled times being defined in the student's timezone. For instance,
I might meet with a student every Thursday at 1PM America/Denver. When
there's a DST switch in that timezone, our meetings will be either 167
or 169 hours apart. I want a script that waits until five minutes
before my next meeting (with anyone) and then plays "Let It Go" in a
randomly-selected language. How would I go about doing this with pytz
and/or datetime? How would I do this under the new proposal? (FWIW, I
currently have exactly such a script, but it's backed by my Google
Calendar. I'm seriously considering rewriting it to use a simple text
file as its primary source, in which case my options are Python
(datetime+pytz) and Pike (built-in Calendar module). This does not
strike me as an altogether unusual kind of script to write.)

And no, Steve, you're not the only one. But maybe the entire thread
should completely halt until there's a PEP draft to discuss, and
*then* reopen on -ideas.

ChrisA

From regebro at gmail.com  Mon Jul 27 16:37:47 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 16:37:47 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <20150727140000.75AA7B14150@webabinitio.net>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
Message-ID: <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>

On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> I'm not sure if the opinion of a relatively inexperienced timezone user
> (whose head hurts when thinking about these things) is relevant, but in
> case it is:
>
> My brief experience with pytz is that it gets this all "wrong".  (Wrong
> is in quotes because it isn't wrong, it just doesn't match my use
> cases).  If I add a timedelta to a pytz datetime that crosses the DST
> boundary, IIRC I get something that still claims it is in the previous
> "timezone" (which it therefore seemed to me was really a UTC offset),
> and I have to call 'normalize' to get it to be in the correct "timezone"
> (UTC offset).

Right.

> I don't remember what that does to the time, and I have
> no intuition about it (I just want it to do the naive arithmetic!)

But what is it that you expect?

That you add one hour to it, and the datetime moves forward one hour
in actual time? That's doable, but during certain circumstance this
may mean that you go from 1AM to 1AM, or from 1AM to 3AM.

Or do you expect that adding one hour will increase the hour count
with one, ie that the "wall time" increases with one hour? This may
actually leave you with a datetime that does not exist, so that is not
something you can consistently do.

Dates and times are tricky, and especially with DST it is simply
possible to make an implementation that is intuitive in all cases to
those who don't know about the problems. What we should aim for is an
implementation that is easy to understand and hard to make errors
with.

> This makes no sense to me, since I thought a tzinfo object was supposed
> to represent the timezone including the DST transitions.  I presume this
> comes from the fact that datetime does naive arithmetic and pytz is
> trying to paste non-naive arithmetic on top?

Exactly.

> So, would it be possible to take the timezone database support from
> pytz, and continue to implement naive-single-zone arithmetic the way Tim
> proposes, and have it automatically produce the correct UTC offset and
> UTC-offset-label afterward, without a normalize call?

That depends on your definition of "correct".

//Lennart

From ncoghlan at gmail.com  Mon Jul 27 16:45:34 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 28 Jul 2015 00:45:34 +1000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
Message-ID: <CADiSq7es2sBn+gVOBxi0yLGqGr572MRyjiMf8vAK56ep-RKM8g@mail.gmail.com>

On 28 July 2015 at 00:27, Steve Dower <Steve.Dower at microsoft.com> wrote:
> Am I the only one feeling like this entire thread should be moved to
> python-ideas at this point?

Since this is an area where the discussion of implementation details
and the discussion of the developer experience can easily end up at
cross purposes, I'm wondering if there may be value in actually
splitting those two discussions into different venues by creating a
datetime-sig, and specifically inviting the pytz and dateutil
developers to participate in the SIG as well.

The traffic on a similarly niche group like import-sig is only
intermittent, but it means that by the time we bring suggestions to
python-ideas or python-dev, we've already thrashed out the low level
arcana and know that whatever we're proposing *can* be made to work,
leaving the core lists to focus on the question of whether or not the
change *should* be made.

Whether or not to do that would be up to the folks with a specific
interest in working with dates and times, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From regebro at gmail.com  Mon Jul 27 16:46:13 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 16:46:13 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <20150727141316.GA25179@ando.pearwood.info>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
Message-ID: <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>

On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> To me, Paul's example is a datetime operation: you start with a datetime
> (7am today), perform arithmetic on it by adding a period of time (one
> day), and get a datetime as the result (7am tomorrow).

Well, OK, let's propose these wordings: It looks like a date
operation, ie, add one to the date, but in reality it's a time
operation, ie add 86400 seconds to the time. These things sound
similar but are very different.

I called it a "calendar" operation, because these operation include
such things as "add one year", where you expect to get the 27th of
July 2016, but you will get the 26th if you use a timedelta, because
2016 is a leap year. So we need to separate date (or calendar)
operations from time operations. The same thing goes with months, add
30 days, and you'll sometimes get the same result as if you add one
month and sometimes not.

timedelta adds time, not days, month or years. Except when you cross a
DST border where it suddenly, surprisingly and intentionally may add
more or less time than you told it to.

//Lennart

From regebro at gmail.com  Mon Jul 27 16:47:27 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 16:47:27 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
Message-ID: <CAL0kPAX=oWuYt4etvuzqcX2WOBeMjuXehN_8b48SDAmxDoYADg@mail.gmail.com>

On Mon, Jul 27, 2015 at 4:27 PM, Steve Dower <Steve.Dower at microsoft.com> wrote:
> Am I the only one feeling like this entire thread should be moved to
> python-ideas at this point?

Well, there isn't any idea to discuss. :-) It's just an explanation of
the problem space. Perhaps it should be moved somewhere else though.

From regebro at gmail.com  Mon Jul 27 16:48:30 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 16:48:30 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CADiSq7es2sBn+gVOBxi0yLGqGr572MRyjiMf8vAK56ep-RKM8g@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7es2sBn+gVOBxi0yLGqGr572MRyjiMf8vAK56ep-RKM8g@mail.gmail.com>
Message-ID: <CAL0kPAUU+3BnU3s7_j2DmeY3odyrZZ6bniEsOi2KtNr3TKm1-g@mail.gmail.com>

On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 28 July 2015 at 00:27, Steve Dower <Steve.Dower at microsoft.com> wrote:
>> Am I the only one feeling like this entire thread should be moved to
>> python-ideas at this point?
>
> Since this is an area where the discussion of implementation details
> and the discussion of the developer experience can easily end up at
> cross purposes, I'm wondering if there may be value in actually
> splitting those two discussions into different venues by creating a
> datetime-sig, and specifically inviting the pytz and dateutil
> developers to participate in the SIG as well.

+1 for that.

From p.f.moore at gmail.com  Mon Jul 27 16:59:53 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2015 15:59:53 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <20150727140000.75AA7B14150@webabinitio.net>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
Message-ID: <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>

On 27 July 2015 at 14:59, R. David Murray <rdmurray at bitdance.com> wrote:
> I have a feeling that I'm completely misunderstanding things, since
> tzinfo is still a bit of a mystery to me.

You're not the only one :-)

I think the following statements are true. If they aren't, I'd
appreciate clarification. I'm going to completely ignore leap seconds
in the following - I hope that's OK, I don't understand leap seconds
*at all* and I don't work in any application areas where they are
relevant (to my knowledge) so I feel that for my situation, ignoring
them (and being able to) is reasonable.

Note that I'm not talking about internal representations - this is
purely about user-visible semantics.

1. "Naive" datetime arithmetic means treating a day as 24 hours, an
hour as 60 minutes, etc. Basically base-24/60/60 arithmetic.
2. If you're only working in a single timezone that's defined as UTC
or a fixed offset from UTC, naive arithmetic is basically all there
is.
3. Converting between (fixed offset) timezones is a separate issue
from calculation - but it's nothing more than applying the relevant
offsets.
4. Calculations involving 2 different timezones (fixed-offset ones as
above) is like any other exercise involving values on different
scales. Convert both values to a common scale (in this case, a common
timezone) and do the calculation there. Simple enough.
5. The problems all arise *only* with timezones whose UTC offset
varies depending on the actual time (e.g., timezones that include the
transition to DST and back).

Are we OK to this point? This much comprises what I would class as a
"naive" (i.e. 99% of the population ;-)) understanding of datetimes.

The stdlib datetime module handles naive datetime values, and
fixed-offset timezones, fine, as far as I can see. (I'm not sure that
the original implementation included fixed-offset tzinfo objects, but
the 3.4 docs say they are there now, so that's fine).

Looking at the complicated cases, the only ones I'm actually aware of
in practice are the ones that switch to DST and back, so typically
have two offsets that differ by an hour, switching between the two at
some essentially arbitrary points. If there are other more complex
forms of timezone, I'd like to never need to know about them, please
;-)

The timezones we're talking about here are things like
"Europe/London", not "GMT" or "BST" (the latter two are fixed-offset).

There are two independent issues with complex timezones:

1. Converting to and from them. That's messy because the conversion to
UTC needs more information than just the date & time (typically, for
example, there is a day when 01:45:00 maps to 2 distinct UTC times).
This is basically the "is_dst" bit that Tim discussed in an earlier
post. The semantic issue here is that users typically say "01:45" and
it never occurs to them to even think about *which* 01:45 they mean.
So recovering that extra information is hard (it's like dealing with
byte streams where the user didn't provide details of the text
encoding used). Once we have the extra information, though, doing
conversions is just a matter of applying a set of rules.

2. Arithmetic within a complex timezone. Theoretically, this is simple
enough (convert to UTC, do the calculation naively, and convert back).
But in practice, that approach doesn't always match user expectations.
So you have 2 mutually incompatible semantic options - 1 day after 4pm
is 3pm the following day, or adding 1 day adds 25 hours - either is a
viable choice, and either will confuse *some* set of users. This, I
think, is the one where all the debate is occurring, and the one that
makes my head explode.

It seems to me that the problem is that for this latter issue, it's
the *timedelta* object that's not rich enough. You can't say "add 1
day, and by 1 day I mean keep the same time tomorrow" as opposed to
"add 1 day, and by that I mean 24 hours"[1]. In some ways, it's
actually no different from the issue of adding 1 month to a date
(which is equally ill-defined, but people "know what they mean" to
just as great an extent). Python bypasses the latter by not having a
timedelta for "a month". C (and the time module) bypasses the former
by limiting all time offsets to numbers of seconds - datetime gave us
a richer timedelta object and hence has extra problems.

I don't have any solutions to this final issue. But hopefully the
above analysis (assuming it's accurate!) helps clarify what the actual
debate is about, for those bystanders like me who are interested in
following the discussion. With luck, maybe it also gives the experts
an alternative perspective from which to think about the problem - who
knows?

Paul

[1] Well, you can, actually - you say that a timedelta of "1 day"
means "the same time tomorrow" and if you want 24 hours, you say "24
hours" not "1 day". So timedelta(days=1) != timedelta(hours=24) even
though they give the same result for every case except arithmetic
involving complex timezones. Is that what Lennart has been trying to
say in his posts?

From rdmurray at bitdance.com  Mon Jul 27 17:04:42 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 27 Jul 2015 11:04:42 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com> <CADi
 Sq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
Message-ID: <20150727150443.0E05BB14091@webabinitio.net>

On Mon, 27 Jul 2015 16:37:47 +0200, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> > I don't remember what that does to the time, and I have
> > no intuition about it (I just want it to do the naive arithmetic!)
> 
> But what is it that you expect?

"I just want it to do the naive arithmetic"

> > So, would it be possible to take the timezone database support from
> > pytz, and continue to implement naive-single-zone arithmetic the way Tim
> > proposes, and have it automatically produce the correct UTC offset and
> > UTC-offset-label afterward, without a normalize call?
> 
> That depends on your definition of "correct".

If I have a time X on date Y in timezone Z, it is either this UTC offset
or that UTC offset, depending on what the politicians decided.  Couple
that with naive arithmetic, and I think you have something easily
understandable from the end user perspective, and useful for a wide
variety (but far from all) use cases.

I'll stop now :)

--David

From keeely3 at gmail.com  Mon Jul 27 16:25:40 2015
From: keeely3 at gmail.com (Mark Kelley)
Date: Mon, 27 Jul 2015 15:25:40 +0100
Subject: [Python-Dev] Building python 2.7.10 for Windows from source
In-Reply-To: <CAKJDb-PAHFRXqTsV-KpJrYLThjmmyQwEGz4jPdRXQispOKAcWQ@mail.gmail.com>
References: <CAGZwN724kDq5KVaRFhiE2HUZbmqPz2b8oYrc24C2wVrjAKHFSg@mail.gmail.com>
 <CAKJDb-PAHFRXqTsV-KpJrYLThjmmyQwEGz4jPdRXQispOKAcWQ@mail.gmail.com>
Message-ID: <CAGZwN721G-jQe2aBXX7vVcPADcDDdJuksueL_t0LZuRg5C+1eA@mail.gmail.com>

Thanks, that got me a bit further.  Now I'm wondering how I figure out
which version of tcl,tk and Tix actually got built with the 2.7.10
installer.  Tools\buildbot\external.bat conflicts with the versions
found in PC\build_tkinter.py, and the version in
PC\VS8.0\build_tkinter.py.

I am assuming the buildbot script is the one that's actually, used?  I
would submit a patch to clean some of this up, but sounds as though
it's in the pipeline.

On Fri, Jul 24, 2015 at 2:46 PM, Zachary Ware
<zachary.ware+pydev at gmail.com> wrote:
> On Jul 24, 2015 8:30 AM, "Mark Kelley" <keeely3 at gmail.com> wrote:
>>
>> I have been using Python for some time but it's been a decade since
>> I've tried to build it from source, back in the 2.4 days.  Things seem
>> to have gotten a little more complicated now.
>>
>> I've read through the PCBuild/README file and got most stuff
>> compiling.  I find it a little odd that there are special instructions
>> for the building the release version of tcl/tk.  Is that what the
>> developers actually do when they cut a release, or is there some
>> other, top-level script that does this automatically? It just seems
>> odd.
>
> That used to be standard procedure, yes. However, I just recently backported
> the project files from 3.5, which include project files for building Tcl/Tk
> and Tix, in both Debug and Release configurations, so I may have missed some
> stuff that could be removed from PCbuild/readme.txt. You do need some extra
> stuff to build 2.7 with its new project files, though (which i know is now
> covered in readme.txt). There hasn't been a release with those project files
> yet though, they're just in the hg repo.
>
>> Anyhow, my specific question is around the distutils wininst stubs,
>> provided as binaries in the release tarball.  Where can I find the
>> source files that those binaries are built from?
>
> I believe the source for those is in PC/bdist_wininst/, or some very similar
> path.
>
> Hope this helps,
> --
> Zach
> (On a phone)

From ryan at ryanhiebert.com  Mon Jul 27 16:26:52 2015
From: ryan at ryanhiebert.com (Ryan Hiebert)
Date: Mon, 27 Jul 2015 09:26:52 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <20150727141316.GA25179@ando.pearwood.info>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
Message-ID: <7E886DED-6A08-4E5C-8A84-1E2D5B710603@ryanhiebert.com>


> On Jul 27, 2015, at 9:13 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
>> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>> I'm confused by your position. If it's 7am on the clock behind me,
>>> right now, then how (under the model proposed by the PEP) do I find
>>> the datetime value where it will next be 7am on the clock?
>> 
>> PEP-431 does not propose to implement calendar operations, and hence
>> does not address that question.
> 
> To me, Paul's example is a datetime operation: you start with a datetime 
> (7am today), perform arithmetic on it by adding a period of time (one 
> day), and get a datetime as the result (7am tomorrow).
> 
> To my naive mind, I would have thought of calendar operations to be 
> things like:
> 
> - print a calendar;
> - add or remove an appointment;
> - send, accept or decline an invitation
> 
> What do you think calendar operations are, and how do they differ from 
> datetime operations? And most importantly, how can we tell them apart?

The way I interpreted it is that "calendar operations" require knowledge of events like daylight savings time that require a more complete knowledge of the calendar, rather than just a naive notion of what a date and time are.


From p.f.moore at gmail.com  Mon Jul 27 17:12:20 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2015 16:12:20 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
Message-ID: <CACac1F_KZC6+vgWELNA4myJLqNyWDbFP=pxMb2-Bb5CpAW609g@mail.gmail.com>

On 27 July 2015 at 15:37, Lennart Regebro <regebro at gmail.com> wrote:
> That you add one hour to it, and the datetime moves forward one hour
> in actual time? That's doable, but during certain circumstance this
> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
>
> Or do you expect that adding one hour will increase the hour count
> with one, ie that the "wall time" increases with one hour? This may
> actually leave you with a datetime that does not exist, so that is not
> something you can consistently do.

OK, that pretty much validates what I thought might be the case at the
end of my recent lengthy email. What you're saying is that the idea of
a timedelta is insufficiently rich here - just saying "1 hour" doesn't
give you enough information to know which of the two expectations the
user has. (The fact that one of those expectations isn't viable is not
actually relevant here).

OK, I see what your point is now. No idea how to solve it, but at
least I understand what you're getting at (I think). Thanks for not
giving up on the thread!

Does thinking of the problem in terms of timedeltas not containing
enough information to make a_time + a_timedelta a well-defined
operation if a_time uses a non-fixed-offset timezone, make it any
easier to find a way forward?

Paul.

From python at mrabarnett.plus.com  Mon Jul 27 17:21:05 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 27 Jul 2015 16:21:05 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
Message-ID: <55B64C61.20701@mrabarnett.plus.com>

On 2015-07-27 15:46, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> To me, Paul's example is a datetime operation: you start with a datetime
>> (7am today), perform arithmetic on it by adding a period of time (one
>> day), and get a datetime as the result (7am tomorrow).
>
> Well, OK, let's propose these wordings: It looks like a date
> operation, ie, add one to the date, but in reality it's a time
> operation, ie add 86400 seconds to the time. These things sound
> similar but are very different.
>
> I called it a "calendar" operation, because these operation include
> such things as "add one year", where you expect to get the 27th of
> July 2016, but you will get the 26th if you use a timedelta, because
> 2016 is a leap year. So we need to separate date (or calendar)
> operations from time operations. The same thing goes with months, add
> 30 days, and you'll sometimes get the same result as if you add one
> month and sometimes not.
>
Also, if you "add one year" to 29 February 2016, what date do you get?

> timedelta adds time, not days, month or years. Except when you cross a
> DST border where it suddenly, surprisingly and intentionally may add
> more or less time than you told it to.
>


From regebro at gmail.com  Mon Jul 27 17:21:40 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 17:21:40 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F_KZC6+vgWELNA4myJLqNyWDbFP=pxMb2-Bb5CpAW609g@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
 <CACac1F_KZC6+vgWELNA4myJLqNyWDbFP=pxMb2-Bb5CpAW609g@mail.gmail.com>
Message-ID: <CAL0kPAWxmqfEy+7vDGbtcVJnyhe12Qa-FL3pWGpb7oKGdMGAOw@mail.gmail.com>

On Mon, Jul 27, 2015 at 5:12 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> Does thinking of the problem in terms of timedeltas not containing
> enough information to make a_time + a_timedelta a well-defined
> operation if a_time uses a non-fixed-offset timezone, make it any
> easier to find a way forward?

Well, I think it is a well-defined operation, but that datetime
currently does it wrongly, to be honest. Adding 3600 seconds to a
datetime should move that datetime 3600 seconds forward at all time. I
just do not see a usecase for doing anything else, to be honest. But
if somebody has one, I'm all ears.

The problem here is that the issue of "get the next day" has been
mixed into timedeltas, when it in my opinion is an entirely different
issue that should be kept separate from timedeltas.

It is possible to implement something so that you can both have
"realtimedeltas" and "walltimedeltas" where adding one hour might give
you two hours (or an error) but as per above I can't think of a
usecase.

//Lennart

From python at mrabarnett.plus.com  Mon Jul 27 17:26:28 2015
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 27 Jul 2015 16:26:28 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
Message-ID: <55B64DA4.2020303@mrabarnett.plus.com>

On 2015-07-27 15:59, Paul Moore wrote:
> On 27 July 2015 at 14:59, R. David Murray <rdmurray at bitdance.com> wrote:
>> I have a feeling that I'm completely misunderstanding things, since
>> tzinfo is still a bit of a mystery to me.
>
> You're not the only one :-)
>
> I think the following statements are true. If they aren't, I'd
> appreciate clarification. I'm going to completely ignore leap seconds
> in the following - I hope that's OK, I don't understand leap seconds
> *at all* and I don't work in any application areas where they are
> relevant (to my knowledge) so I feel that for my situation, ignoring
> them (and being able to) is reasonable.
>
> Note that I'm not talking about internal representations - this is
> purely about user-visible semantics.
>
Would it help if it was explicit and we had LocalDateTime and
UTCDateTime?

> 1. "Naive" datetime arithmetic means treating a day as 24 hours, an
> hour as 60 minutes, etc. Basically base-24/60/60 arithmetic.
> 2. If you're only working in a single timezone that's defined as UTC
> or a fixed offset from UTC, naive arithmetic is basically all there
> is.
> 3. Converting between (fixed offset) timezones is a separate issue
> from calculation - but it's nothing more than applying the relevant
> offsets.
> 4. Calculations involving 2 different timezones (fixed-offset ones as
> above) is like any other exercise involving values on different
> scales. Convert both values to a common scale (in this case, a common
> timezone) and do the calculation there. Simple enough.
> 5. The problems all arise *only* with timezones whose UTC offset
> varies depending on the actual time (e.g., timezones that include the
> transition to DST and back).
>
> Are we OK to this point? This much comprises what I would class as a
> "naive" (i.e. 99% of the population ;-)) understanding of datetimes.
>
> The stdlib datetime module handles naive datetime values, and
> fixed-offset timezones, fine, as far as I can see. (I'm not sure that
> the original implementation included fixed-offset tzinfo objects, but
> the 3.4 docs say they are there now, so that's fine).
>
> Looking at the complicated cases, the only ones I'm actually aware of
> in practice are the ones that switch to DST and back, so typically
> have two offsets that differ by an hour, switching between the two at
> some essentially arbitrary points. If there are other more complex
> forms of timezone, I'd like to never need to know about them, please
> ;-)
>
> The timezones we're talking about here are things like
> "Europe/London", not "GMT" or "BST" (the latter two are fixed-offset).
>
> There are two independent issues with complex timezones:
>
> 1. Converting to and from them. That's messy because the conversion to
> UTC needs more information than just the date & time (typically, for
> example, there is a day when 01:45:00 maps to 2 distinct UTC times).
> This is basically the "is_dst" bit that Tim discussed in an earlier
> post. The semantic issue here is that users typically say "01:45" and
> it never occurs to them to even think about *which* 01:45 they mean.
> So recovering that extra information is hard (it's like dealing with
> byte streams where the user didn't provide details of the text
> encoding used). Once we have the extra information, though, doing
> conversions is just a matter of applying a set of rules.
>
> 2. Arithmetic within a complex timezone. Theoretically, this is simple
> enough (convert to UTC, do the calculation naively, and convert back).
> But in practice, that approach doesn't always match user expectations.
> So you have 2 mutually incompatible semantic options - 1 day after 4pm
> is 3pm the following day, or adding 1 day adds 25 hours - either is a
> viable choice, and either will confuse *some* set of users. This, I
> think, is the one where all the debate is occurring, and the one that
> makes my head explode.
>
> It seems to me that the problem is that for this latter issue, it's
> the *timedelta* object that's not rich enough. You can't say "add 1
> day, and by 1 day I mean keep the same time tomorrow" as opposed to
> "add 1 day, and by that I mean 24 hours"[1]. In some ways, it's
> actually no different from the issue of adding 1 month to a date
> (which is equally ill-defined, but people "know what they mean" to
> just as great an extent). Python bypasses the latter by not having a
> timedelta for "a month". C (and the time module) bypasses the former
> by limiting all time offsets to numbers of seconds - datetime gave us
> a richer timedelta object and hence has extra problems.
>
> I don't have any solutions to this final issue. But hopefully the
> above analysis (assuming it's accurate!) helps clarify what the actual
> debate is about, for those bystanders like me who are interested in
> following the discussion. With luck, maybe it also gives the experts
> an alternative perspective from which to think about the problem - who
> knows?
>
> Paul
>
> [1] Well, you can, actually - you say that a timedelta of "1 day"
> means "the same time tomorrow" and if you want 24 hours, you say "24
> hours" not "1 day". So timedelta(days=1) != timedelta(hours=24) even
> though they give the same result for every case except arithmetic
> involving complex timezones. Is that what Lennart has been trying to
> say in his posts?
>


From p.f.moore at gmail.com  Mon Jul 27 17:37:03 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2015 16:37:03 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <55B64DA4.2020303@mrabarnett.plus.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
 <55B64DA4.2020303@mrabarnett.plus.com>
Message-ID: <CACac1F_LXegD8Lon27mQ12S67x6iGNuhzfDXz+9ZVB1D9oOzpg@mail.gmail.com>

On 27 July 2015 at 16:26, MRAB <python at mrabarnett.plus.com> wrote:
>> Note that I'm not talking about internal representations - this is
>> purely about user-visible semantics.
>>
> Would it help if it was explicit and we had LocalDateTime and
> UTCDateTime?

I don't see how. Why should I care about the internal representation?
Paul

From alexander.belopolsky at gmail.com  Mon Jul 27 17:37:31 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 27 Jul 2015 11:37:31 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
Message-ID: <CAP7h-xaGYPK=s7KXre+ecdon02vHMjX7OKLvpcZrW=TFXpzrMQ@mail.gmail.com>

On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> The semantic issue here is that users typically say "01:45" and
> it never occurs to them to even think about *which* 01:45 they mean.
> So recovering that extra information is hard (it's like dealing with
> byte streams where the user didn't provide details of the text
> encoding used). Once we have the extra information, though, doing
> conversions is just a matter of applying a set of rules.
>

It is slightly more complicated than that.  There are locations (even in
the US, I've heard)
where clocks have been moved back for reasons other than DST.  I described
one such
example in my earlier post [1].  On July 1, 1990, at 2AM, the people of
Ukraine celebrated
their newly acquired independence by moving their clocks  back to 1AM thus
living
through "1990-07-01T01:45" local time twice.  This happened in the middle
of summer and
daylight savings time was in effect before and after the transition, so you
cannot use isdst
to disambiguate between the first and the second "01:45".

On the other hand, these rare events are not that different from more or
less regular DST
transitions.  You still have either a non-existent or ambiguous local times
interval and
you can resolve the ambiguity by adding 1 bit of information.  The only
question is what
should we call the flag that will supply that information?  IMO, "isdst" is
a wrong name
for dealing with the event I described above.

[1]: https://mail.python.org/pipermail/python-dev/2015-April/139099.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/50246309/attachment.html>

From ryan at ryanhiebert.com  Mon Jul 27 17:42:42 2015
From: ryan at ryanhiebert.com (Ryan Hiebert)
Date: Mon, 27 Jul 2015 10:42:42 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAP7h-xaGYPK=s7KXre+ecdon02vHMjX7OKLvpcZrW=TFXpzrMQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
 <CAP7h-xaGYPK=s7KXre+ecdon02vHMjX7OKLvpcZrW=TFXpzrMQ@mail.gmail.com>
Message-ID: <2CBC98AD-FA10-46B3-A35A-44A284B7104C@ryanhiebert.com>


> On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 
> On the other hand, these rare events are not that different from more or less regular DST
> transitions.  You still have either a non-existent or ambiguous local times interval and
> you can resolve the ambiguity by adding 1 bit of information.  The only question is what
> should we call the flag that will supply that information?  IMO, "isdst" is a wrong name
> for dealing with the event I described above.

While I see your point that isdst is the wrong name in that it doesn't describe what's actually happening in all cases, it is the most well known instance of the issue, and I personally think that using isdst for the other cases makes sense, and that they would disambiguate in the same direction that it would in a dst transition of the same type (clocks forward or backward).

From alexander.belopolsky at gmail.com  Mon Jul 27 18:10:39 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 27 Jul 2015 12:10:39 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <2CBC98AD-FA10-46B3-A35A-44A284B7104C@ryanhiebert.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
 <CAP7h-xaGYPK=s7KXre+ecdon02vHMjX7OKLvpcZrW=TFXpzrMQ@mail.gmail.com>
 <2CBC98AD-FA10-46B3-A35A-44A284B7104C@ryanhiebert.com>
Message-ID: <CAP7h-xbUXZ0d9HLJmD+mRdztFL7P-4AD8WY8XJeniWNevNDjgw@mail.gmail.com>

On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert <ryan at ryanhiebert.com> wrote:

> > On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky <
> alexander.belopolsky at gmail.com> wrote:
> >
> > On the other hand, these rare events are not that different from more or
> less regular DST
> > transitions.  You still have either a non-existent or ambiguous local
> times interval and
> > you can resolve the ambiguity by adding 1 bit of information.  The only
> question is what
> > should we call the flag that will supply that information?  IMO, "isdst"
> is a wrong name
> > for dealing with the event I described above.
>
> While I see your point that isdst is the wrong name in that it doesn't
> describe what's actually happening in all cases, it is the most well known
> instance of the issue, and I personally think that using isdst for the
> other cases makes sense, and that they would disambiguate in the same
> direction that it would in a dst transition of the same type (clocks
> forward or backward).


Well, my specific proposal in [1] was to also change the semantics.  The
proposed "which" flag would have the following
meaning:

  1. If local time is valid and unambiguous, "which" is ignored.
  2. If local time is ambiguous, which=0 means the first and which=1 means
the second (chronologically).
  3. If local time is invalid, which=0 means the time extrapolated from
before the transition and
      which = 1 means the time extrapolated from after the transition.

Note that these rules have some nice properties: if t is ambiguous, UTC(t,
which=0) <  UTC(t, which=1)
and if t is invalid, UTC(t, which=0) > UTC(t, which=1).  This property can
be used to take different
actions in those cases.  The result for ambiguous t and which=0 has a
natural interpretation as time
specified by a user not aware of the clock change.

I think these rules are simpler and more natural than those for isdst which
takes 3 values: 0, 1 and -1 and
the rules for -1 vary between implementations.  Under my proposal
unspecified "which" means which=0.

[1]: https://mail.python.org/pipermail/python-dev/2015-April/139099.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/19750bda/attachment.html>

From Nikolaus at rath.org  Mon Jul 27 18:15:33 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Mon, 27 Jul 2015 09:15:33 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
 (Lennart Regebro's message of "Mon, 27 Jul 2015 16:37:47 +0200")
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
Message-ID: <87mvyha862.fsf@thinkpad.rath.org>

On Jul 27 2015, Lennart Regebro <regebro at gmail.com> wrote:
> That you add one hour to it, and the datetime moves forward one hour
> in actual time? That's doable, but during certain circumstance this
> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
>
> Or do you expect that adding one hour will increase the hour count
> with one, ie that the "wall time" increases with one hour? This may
> actually leave you with a datetime that does not exist, so that is not
> something you can consistently do.

Apologies for asking yet another dumb question about this, but I have
the impression that a lot of other people are struggling with the basics
here too.

Can you tell us which of the two operations datetime currently
implements?

And when people talk about explicitly converting to UTC and back, does
that mean that if you're (again, with the current implementation)
converting to UTC, *then* add the one hour, and then convert back, you
get the other operation (that you don't get when you directly add 1
day)?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From regebro at gmail.com  Mon Jul 27 18:30:03 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 18:30:03 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <87mvyha862.fsf@thinkpad.rath.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
 <87mvyha862.fsf@thinkpad.rath.org>
Message-ID: <CAL0kPAVHLiPjhaowZdsmYpBHwkX_NNEODjKmHzPARTUigQ8eWQ@mail.gmail.com>

On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath <Nikolaus at rath.org> wrote:
> On Jul 27 2015, Lennart Regebro <regebro at gmail.com> wrote:
>> That you add one hour to it, and the datetime moves forward one hour
>> in actual time? That's doable, but during certain circumstance this
>> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
>>
>> Or do you expect that adding one hour will increase the hour count
>> with one, ie that the "wall time" increases with one hour? This may
>> actually leave you with a datetime that does not exist, so that is not
>> something you can consistently do.
>
> Apologies for asking yet another dumb question about this, but I have
> the impression that a lot of other people are struggling with the basics
> here too.
>
> Can you tell us which of the two operations datetime currently
> implements?

It's intended that the first one is implemented, meaning that
datetime.now() + timedelta(hours=24) can result in a datetime
somewhere between 23 and 25 hours into the future. Or well, any
amount, in theory, I guess some changes are more than an hour, but
that's very unusual.

> And when people talk about explicitly converting to UTC and back, does
> that mean that if you're (again, with the current implementation)
> converting to UTC, *then* add the one hour, and then convert back, you
> get the other operation (that you don't get when you directly add 1
> day)?

Yes, exactly.

//Lennart

From alexander.belopolsky at gmail.com  Mon Jul 27 18:32:37 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 27 Jul 2015 12:32:37 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <87mvyha862.fsf@thinkpad.rath.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
 <87mvyha862.fsf@thinkpad.rath.org>
Message-ID: <CAP7h-xauKNEMcUoFUqv3sC56_GAtXK3m+YojUf+eDVwH2nf7Rg@mail.gmail.com>

On Mon, Jul 27, 2015 at 12:15 PM, Nikolaus Rath <Nikolaus at rath.org> wrote:

> On Jul 27 2015, Lennart Regebro <regebro at gmail.com> wrote:
> > That you add one hour to it, and the datetime moves forward one hour
> > in actual time? That's doable, but during certain circumstance this
> > may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
> >
> > Or do you expect that adding one hour will increase the hour count
> > with one, ie that the "wall time" increases with one hour? This may
> > actually leave you with a datetime that does not exist, so that is not
> > something you can consistently do.
>
> Apologies for asking yet another dumb question about this, but I have
> the impression that a lot of other people are struggling with the basics
> here too.
>

I believe your questions are addressed to Lennart, but let me offer
my answer to the first:

>
> Can you tell us which of the two operations datetime currently
> implements?


The first one, but not as directly as one might wish.  (I think the
situation
is similar to that of pytz's normalize(), but I am not an expert on pytz.)

>>> t = datetime(2014,11,2,5,tzinfo=timezone.utc).astimezone()
>>> t.strftime("%D %T%z %Z")
'11/02/14 01:00:00-0400 EDT'
>>> (t+timedelta(hours=1)).astimezone().strftime("%D %T%z %Z")
'11/02/14 01:00:00-0500 EST'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/81fd290f/attachment.html>

From willingc at willingconsulting.com  Mon Jul 27 18:19:14 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Mon, 27 Jul 2015 09:19:14 -0700
Subject: [Python-Dev] Burning down the backlog.
In-Reply-To: <20150727013741.87E48B14152@webabinitio.net>
References: <CAJ3HoZ366ra+yn3OC2DkVbNoKN3LEZw34Jp-SMgCmJo9byWS-w@mail.gmail.com>
 <CACac1F-p_g9C-bhbF9x7mB8HHVDZurHEv0RbrVKfQN4MXvXegw@mail.gmail.com>
 <CAF4280Jo0BBEehZeNYS1p5H7YhU+HUjWV8jTnqQxmm0tikZpRA@mail.gmail.com>
 <CACac1F9zEiafjQqVdaxV16CWTnQHRx2amZvVCsL77UnejQSg=A@mail.gmail.com>
 <20150727013741.87E48B14152@webabinitio.net>
Message-ID: <55B65A02.7060708@willingconsulting.com>

On 7/26/15 6:37 PM, R. David Murray wrote:
> On Sun, 26 Jul 2015 22:59:51 +0100, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 26 July 2015 at 16:39, Berker Peksa?? <berker.peksag at gmail.com> wrote:
> So, I'm hoping Carol will take what I've written above and turn it into
> updates for the devguide (assuming no one disagrees with what I've said :)
>
David, I'm happy to try to incorporate your detailed steps into the 
devguide.


From alexander.belopolsky at gmail.com  Mon Jul 27 18:42:55 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 27 Jul 2015 12:42:55 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVHLiPjhaowZdsmYpBHwkX_NNEODjKmHzPARTUigQ8eWQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
 <87mvyha862.fsf@thinkpad.rath.org>
 <CAL0kPAVHLiPjhaowZdsmYpBHwkX_NNEODjKmHzPARTUigQ8eWQ@mail.gmail.com>
Message-ID: <CAP7h-xYFbdyOsETqW99bpDp=vf_sC1U4SzWfGEoOUx832JrjyQ@mail.gmail.com>

On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro <regebro at gmail.com> wrote:

> On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath <Nikolaus at rath.org> wrote:
> > On Jul 27 2015, Lennart Regebro <regebro at gmail.com> wrote:
>
(The *first* option)

> >> That you add one hour to it, and the datetime moves forward one hour
> >> in actual time? That's doable, but during certain circumstance this
> >> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
> >>
>
(The *second* option)

> >> Or do you expect that adding one hour will increase the hour count
> >> with one, ie that the "wall time" increases with one hour? ...
> > Can you tell us which of the two operations datetime currently
> > implements?
>
> It's intended that the first one is implemented, meaning that
> datetime.now() + timedelta(hours=24) can result in a datetime
> somewhere between 23 and 25 hours into the future.


I think this describes what was originally your *second*, not *first*
option. It
will also help if you focus on one use case at a time.  Your original
example
dealt with adding 1 hour, but now you switch to adding 24.

In my previous email, I explained what is currently doable using the
datetime
module:

>>> t = datetime(2014,11,2,5,tzinfo=timezone.utc).astimezone()
>>> t.strftime("%D %T%z %Z")
'11/02/14 01:00:00-0400 EDT'
>>> (t+timedelta(hours=1)).astimezone().strftime("%D %T%z %Z")
'11/02/14 01:00:00-0500 EST'

Is this your *first* or your *second* option?  Note that this is not what
is "intended".  This is an actual Python 3.4.3 session.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/7173afef/attachment.html>

From regebro at gmail.com  Mon Jul 27 18:44:53 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 18:44:53 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAP7h-xYFbdyOsETqW99bpDp=vf_sC1U4SzWfGEoOUx832JrjyQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
 <87mvyha862.fsf@thinkpad.rath.org>
 <CAL0kPAVHLiPjhaowZdsmYpBHwkX_NNEODjKmHzPARTUigQ8eWQ@mail.gmail.com>
 <CAP7h-xYFbdyOsETqW99bpDp=vf_sC1U4SzWfGEoOUx832JrjyQ@mail.gmail.com>
Message-ID: <CAL0kPAVH8gVMqPTeafHkK4Eq1j1JZuW7fRHB3xL5yiO+yv0eew@mail.gmail.com>

On Mon, Jul 27, 2015 at 6:42 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> I think this describes what was originally your *second*, not *first*
> option.

Yes, you are absolutely correct, I didn't read my own description of
the options carefully enough.

From p.f.moore at gmail.com  Mon Jul 27 18:45:40 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2015 17:45:40 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVHLiPjhaowZdsmYpBHwkX_NNEODjKmHzPARTUigQ8eWQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CAL0kPAXLS-VjWLxgHoser-GXAOg4zs3ZUR-WmG3HHCTsvw5ZFA@mail.gmail.com>
 <87mvyha862.fsf@thinkpad.rath.org>
 <CAL0kPAVHLiPjhaowZdsmYpBHwkX_NNEODjKmHzPARTUigQ8eWQ@mail.gmail.com>
Message-ID: <CACac1F-sB0BaoSizjQAGw5jE7rWOnwqKg+U7vZkAMXu_1wz2YQ@mail.gmail.com>

On 27 July 2015 at 17:30, Lennart Regebro <regebro at gmail.com> wrote:
>> Apologies for asking yet another dumb question about this, but I have
>> the impression that a lot of other people are struggling with the basics
>> here too.
>>
>> Can you tell us which of the two operations datetime currently
>> implements?
>
> It's intended that the first one is implemented, meaning that
> datetime.now() + timedelta(hours=24) can result in a datetime
> somewhere between 23 and 25 hours into the future. Or well, any
> amount, in theory, I guess some changes are more than an hour, but
> that's very unusual.

Maybe that's what the PEP intends. But the stdlib as currently
implemented simply adds the appropriate number to the relevant field
(i.e., "increase the hour count with one").

It's not possible to detect the difference between these two using
only stdlib timezones, though, as those are all fixed-offset.

Both Tim and I have pointed out that Guido's original intention was
precisely what is implemented, for better or worse. What Guido's view
was on DST-aware timezones and whether the behaviour was appropriate
for those, I don't know personally (maybe Tim does). It may well be
that it was "let's not think about it for now".

If we can ever straighten out what the question is, maybe Guido can
chip in and answer it :-)

Paul

PS Ideally, Guido could pop into his time machine and fix the whole
issue at source. But apparently he can't, because the time machine
isn't DST-aware...

From p.f.moore at gmail.com  Mon Jul 27 18:46:59 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2015 17:46:59 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
Message-ID: <CACac1F_V+cdjzxPi=eS8mTOHGVdBV9fU2NUqTZ9TRNnzYMqgkw@mail.gmail.com>

On 27 July 2015 at 15:57, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> IMHO ?+ 1 days? and ?+ 24 hours? are two different things.  Date
> arithmetic is full of messy things like that.  ?+ 1 month? is another
> example of that (which the datetime module punts completely
> and can be a source of endless bikeshidding).

Precisely.
Paul

From ronaldoussoren at mac.com  Mon Jul 27 16:57:16 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 27 Jul 2015 16:57:16 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
Message-ID: <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>


> On 27 Jul 2015, at 04:04, Tim Peters <tim.peters at gmail.com> wrote:
> 
> 
>> As an example, consider an alarm clock. I want it to go off at 7am
>> each morning. I'd feel completely justified in writing tomorrows_alarm
>> = todays_alarm + timedelta(days=1).
>> 
>> If the time changes to DST overnight, I still want the alarm to go off
>> at 7am. Even though +1 day is in this case actually + 25 (or is it
>> 23?) hours. That's the current semantics.
> 
> There was a long list of use cases coming to the same conclusion.  The
> current arithmetic allows uniform patterns in local time to be coded
> in uniform, straightforward ways.  Indeed, in "the obvious" ways.  The
> alternative behavior favors uniform patterns in UTC, but who cares?
> ;-)  Few local clocks show UTC.  Trying to code uniform local-time
> behaviors using "aware arithmetic" (which is uniform in UTC. but may
> be "lumpy" in local time) can be a nightmare.
> 
> The canonical counterexample is a nuclear reactor that needs to be
> vented every 24 hours.  To which the canonical rejoinder is that the
> programmer in charge of that system is criminally incompetent if
> they're using _any_ notion of time other than UTC ;-)

IMHO ?+ 1 days? and ?+ 24 hours? are two different things.  Date 
arithmetic is full of messy things like that.  ?+ 1 month? is another
example of that (which the datetime module punts completely
and can be a source of endless bikeshidding).

Ronald



From breamoreboy at yahoo.co.uk  Mon Jul 27 19:06:02 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Mon, 27 Jul 2015 18:06:02 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CADiSq7es2sBn+gVOBxi0yLGqGr572MRyjiMf8vAK56ep-RKM8g@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7es2sBn+gVOBxi0yLGqGr572MRyjiMf8vAK56ep-RKM8g@mail.gmail.com>
Message-ID: <mp5ods$rb7$1@ger.gmane.org>

On 27/07/2015 15:45, Nick Coghlan wrote:
> On 28 July 2015 at 00:27, Steve Dower <Steve.Dower at microsoft.com> wrote:
>> Am I the only one feeling like this entire thread should be moved to
>> python-ideas at this point?
>
> Since this is an area where the discussion of implementation details
> and the discussion of the developer experience can easily end up at
> cross purposes, I'm wondering if there may be value in actually
> splitting those two discussions into different venues by creating a
> datetime-sig, and specifically inviting the pytz and dateutil
> developers to participate in the SIG as well.
>
> The traffic on a similarly niche group like import-sig is only
> intermittent, but it means that by the time we bring suggestions to
> python-ideas or python-dev, we've already thrashed out the low level
> arcana and know that whatever we're proposing *can* be made to work,
> leaving the core lists to focus on the question of whether or not the
> change *should* be made.
>
> Whether or not to do that would be up to the folks with a specific
> interest in working with dates and times, though.
>
> Cheers,
> Nick.
>

Would it be worth doing a straw poll to gauge how many people really 
need this, from my perspective anyway, level of complexity?  I've used 
datetimes a lot, but I don't even need naive timezones, completely dumb 
suits me.

Alternatively just go ahead, knowing that if the proposal isn't accepted 
into the stdlib it can at least go on pypi.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From rosuav at gmail.com  Mon Jul 27 19:11:25 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 28 Jul 2015 03:11:25 +1000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
Message-ID: <CAPTjJmrBE0FPHaOi2hTsKv+WNVp+mS=tx7F1O5UHZ_7-E1QibQ@mail.gmail.com>

On Tue, Jul 28, 2015 at 12:57 AM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
> IMHO ?+ 1 days? and ?+ 24 hours? are two different things.  Date
> arithmetic is full of messy things like that.  ?+ 1 month? is another
> example of that (which the datetime module punts completely
> and can be a source of endless bikeshidding).

https://www.youtube.com/watch?v=ppfpa5XgZHI

MATLAB defines "+ 1 month" as, if I'm not mistaken, "add the time it
would take to go from the beginning of time to the beginning of
January of the year 0 (which is totally a thing, by the way)". I'm
fairly sure that this is the most WAT-worthy definition possible, as
it means that adding one month does nothing, and adding two months
adds the length of January (31 days)... and adding three months adds
January + February, *in a leap year*.

But I agree that adding days and adding hours are different things. If
I add one day, I expect that the time portion should not change, in
the given timezone. (With the exception that DST switches might mean
that that time doesn't exist.) If I add 86400 seconds, I expect that
it should add 86400 ISO seconds to the time period, which might not be
the same thing. If you convert a datetime to a different timezone, add
86400 seconds, and convert back to the original timezone, I would
expect the result to be the same as adding 86400 seconds to the
original, unless there's something seriously bizarre going on with the
size of the second. But if you convert, add 1 day, and convert back,
you will get a different result if the two differ on DST. Does that
sound plausible?

ChrisA

From srkunze at mail.de  Mon Jul 27 19:32:40 2015
From: srkunze at mail.de (Sven R. Kunze)
Date: Mon, 27 Jul 2015 19:32:40 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAPTjJmrBE0FPHaOi2hTsKv+WNVp+mS=tx7F1O5UHZ_7-E1QibQ@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAPTjJmrBE0FPHaOi2hTsKv+WNVp+mS=tx7F1O5UHZ_7-E1QibQ@mail.gmail.com>
Message-ID: <55B66B38.3080804@mail.de>

I agree and my 2 cents: I can expect something different depending on 
the timezone and DST if I add

years
months
weeks
days
hours
minutes
seconds

to a given datetime

Even though, in 90% of the cases, there is a more or less obvious 
conversion formula between all of them. But consider months to days. 
That is not clear at all.

On 27.07.2015 19:11, Chris Angelico wrote:
> On Tue, Jul 28, 2015 at 12:57 AM, Ronald Oussoren
> <ronaldoussoren at mac.com> wrote:
>> IMHO ?+ 1 days? and ?+ 24 hours? are two different things.  Date
>> arithmetic is full of messy things like that.  ?+ 1 month? is another
>> example of that (which the datetime module punts completely
>> and can be a source of endless bikeshidding).
> https://www.youtube.com/watch?v=ppfpa5XgZHI
>
> MATLAB defines "+ 1 month" as, if I'm not mistaken, "add the time it
> would take to go from the beginning of time to the beginning of
> January of the year 0 (which is totally a thing, by the way)". I'm
> fairly sure that this is the most WAT-worthy definition possible, as
> it means that adding one month does nothing, and adding two months
> adds the length of January (31 days)... and adding three months adds
> January + February, *in a leap year*.
>
> But I agree that adding days and adding hours are different things. If
> I add one day, I expect that the time portion should not change, in
> the given timezone. (With the exception that DST switches might mean
> that that time doesn't exist.) If I add 86400 seconds, I expect that
> it should add 86400 ISO seconds to the time period, which might not be
> the same thing. If you convert a datetime to a different timezone, add
> 86400 seconds, and convert back to the original timezone, I would
> expect the result to be the same as adding 86400 seconds to the
> original, unless there's something seriously bizarre going on with the
> size of the second. But if you convert, add 1 day, and convert back,
> you will get a different result if the two differ on DST. Does that
> sound plausible?
>
> ChrisA
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de


From tjreedy at udel.edu  Mon Jul 27 20:28:58 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 27 Jul 2015 14:28:58 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <55B64C61.20701@mrabarnett.plus.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B64C61.20701@mrabarnett.plus.com>
Message-ID: <mp5t9b$eb0$1@ger.gmane.org>

On 7/27/2015 11:21 AM, MRAB wrote:

> Also, if you "add one year" to 29 February 2016, what date do you get?

I believe the 'conventional' answer is 1 March 2017.  That is also 1 Mar 
2016 + 1 year.  1 March 2017 - 1 year would be 1 Mar 2016.  Leap days 
get cheated.

-- 
Terry Jan Reedy


From tim.peters at gmail.com  Mon Jul 27 20:49:32 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 13:49:32 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
Message-ID: <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>

[Ronald Oussoren <ronaldoussoren at mac.com>]
> IMHO ?+ 1 days? and ?+ 24 hours? are two different things.
> Date arithmetic is full of messy things like that.

But it's a fact that they _are_ the same in naive time, which Python's
datetime single-timezone arithmetic implements:

- A minute is exactly 60 seconds.
- An hour is exactly 60 minutes.
- A day is exactly 24 hours.
- A week is exactly 7 days.

No context is necessary:  those are always true in naive time, and
that lack of mess is "a feature" to those who accept it for what it
is.

> ?+ 1 month? is another example of that (which the datetime
> module punts completely and can be a source of endless
> bikeshidding).

Note that the only units timedelta accepts have clear (utterly
inarguable) meanings in naive time.  That's intentional too.  For
example, "a month" and "a year" have no clear meanings (as durations)
in naive time, so timedelta doesn't even pretend to support them.
Despite all appearance to the contrary in this thread, naive time is
bikeshed-free:  it's easy for someone to know all there is to know
about it by the time they're 12 ;-)

    datetime + timedelta(days=1)

is equivalent to

    datetime + timedelta(hours=24)

is equivalent to

    datetime + timedelta(minutes=60*24)

is equivalent to

    datetime + timedelta(seconds=60*60*24)

is equivalent to

    datetime + timedelta(microseconds=1000000*60*60*24)

Naive time is easy to understand, reason about, and work with.  When
it comes to the real world, political adjustments to and within time
zones can make the results dodgy, typically in the two DST-transition
hours per year when most people living in a given time zone are
sleeping.  How much complexity do you want to endure in case they wake
up? ;-)  Guido's answer was "none in arithmetic - push all the
complexity into conversions - then most uses can blissfully ignore the
complexities".

And note that because DST transitions "cancel out" over the span of a
year, the benefits and the few dodgy cases don't really change
regardless of whether you add one week or a hundred thousand weeks
(although there's no way to predict what governments will decide the
local clock "should say" a hundred thousand weeks from now - it's only
predictable in naive time).

From tjreedy at udel.edu  Mon Jul 27 20:55:53 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 27 Jul 2015 14:55:53 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
Message-ID: <mp5urq$8ks$1@ger.gmane.org>

On 7/27/2015 3:09 AM, Tim Peters wrote:
> [Paul Moore <p.f.moore at gmail.com>]
>>> ....
>>> As an example, consider an alarm clock. I want it to go off at 7am
>>> each morning. I'd feel completely justified in writing
>>> tomorrows_alarm = todays_alarm + timedelta(days=1).
>
> [Lennart Regebro <regebro at gmail.com>]
>> That's a calendar operation made with a timedelta.
>
> It's an instance of single-timezone datetime arithmetic, of the
> datetime + timedelta form.  Your examples have been of the same form.
> Note that after Paul's
>
>       tomorrows_alarm = todays_alarm + timedelta(days=1)
>
> it's guaranteed that
>
>      assert tomorrows_alarm - todays_alarm == timedelta(days=1)
>
> will succeed too.
>
>> The "days" attribute here is indeed confusing as it doesn't mean 1 day,
>> it means 24 hours.
>
> Which, in naive arithmetic, are exactly the same thing.

I think using the word 'naive' is both inaccurate and a mistake.  The 
issue is civil or legal time versus STEM time, where the latter includes 
applications like baking cakes.  It could also be called calendar time 
versus elapsed time.  (Financial/legal arithmetic versus STEM arithmetic 
is a somewhat similar contrast.)

The idea that an hour can be sliced out of a somewhat random March day 
and inserting it into a somewhat random October day is rather 
sophisticated.  It came from the minds of government bureaucrats.  It 
might be smart, dumb, or just a cunning way for civil authorities to 
show who is in charge by making us all jump.  But not 'naive'.

'Naive' means simple, primitive, or deficient in informed judgement. It 
is easy to take it as connoting 'wrong'.  Tim, you have been arguing 
that civil/legal time arithmetic is not naive. Calling civil time naive 
undercuts this claim.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Mon Jul 27 21:01:28 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 27 Jul 2015 15:01:28 -0400
Subject: [Python-Dev] Building python 2.7.10 for Windows from source
In-Reply-To: <CAGZwN721G-jQe2aBXX7vVcPADcDDdJuksueL_t0LZuRg5C+1eA@mail.gmail.com>
References: <CAGZwN724kDq5KVaRFhiE2HUZbmqPz2b8oYrc24C2wVrjAKHFSg@mail.gmail.com>
 <CAKJDb-PAHFRXqTsV-KpJrYLThjmmyQwEGz4jPdRXQispOKAcWQ@mail.gmail.com>
 <CAGZwN721G-jQe2aBXX7vVcPADcDDdJuksueL_t0LZuRg5C+1eA@mail.gmail.com>
Message-ID: <mp5v6a$e4e$1@ger.gmane.org>

On 7/27/2015 10:25 AM, Mark Kelley wrote:
> Thanks, that got me a bit further.  Now I'm wondering how I figure out
> which version of tcl,tk and Tix actually got built with the 2.7.10
> installer.

This is really a python-list question, but for the PSF installer, 
tcl/tk 8.5.15

-- 
Terry Jan Reedy


From rosuav at gmail.com  Mon Jul 27 21:07:13 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 28 Jul 2015 05:07:13 +1000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
Message-ID: <CAPTjJmoyqdrQmQ5CurDEv1WCY-BYPvVjLJBUE83t7tWAwvufxA@mail.gmail.com>

On Tue, Jul 28, 2015 at 4:49 AM, Tim Peters <tim.peters at gmail.com> wrote:
> But it's a fact that they _are_ the same in naive time, which Python's
> datetime single-timezone arithmetic implements:
>
> - A minute is exactly 60 seconds.

No leap second support, presumably. Also feature?

ChrisA

From tim.peters at gmail.com  Mon Jul 27 21:14:06 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 14:14:06 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp5urq$8ks$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <mp5urq$8ks$1@ger.gmane.org>
Message-ID: <CAExdVN=J4P4YrLJomRO13wuhKKFU3kQzZSU_LZ08Zv0aJmv_0Q@mail.gmail.com>

....

>>> The "days" attribute here is indeed confusing as it doesn't mean 1 day,
>>> it means 24 hours.

>> Which, in naive arithmetic, are exactly the same thing.

[Terry Reedy]
> I think using the word 'naive' is both inaccurate and a mistake.  The issue
> is civil or legal time versus STEM time, where the latter includes
> applications like baking cakes.

Sorry, never heard of "STEM time" before - & a quick Google search didn't help.

> It could also be called calendar time versus elapsed time.  (Financial/legal
> arithmetic versus STEM arithmetic is a somewhat similar contrast.)

And I am, alas, equally unclear on what any of those others mean
(exactly) to you.

> The idea that an hour can be sliced out of a somewhat random March day and
> inserting it into a somewhat random October day is rather sophisticated.  It
> came from the minds of government bureaucrats.  It might be smart, dumb, or
> just a cunning way for civil authorities to show who is in charge by making
> us all jump.  But not 'naive'.

I agree.  Python's "naive time" single-timezone arithmetic
intentionally ignores all that:  it ignores leap seconds, it ignores
DST transition points, it ignores governments deciding to change the
base UTC offset within a pre-existing time zone, ...  It's time soooo
naive that it thinks 24 hours is the same thing as a day ;-)

> 'Naive' means simple, primitive, or deficient in informed judgement. It is
> easy to take it as connoting 'wrong'.

While some people in this thread seem convinced Python's naive time
_is_ "wrong", it's not because it's called "naive".  In any case,
Guido decided to call it "naive" over 13 years ago, starting here, and
that terminology has been in use ever since:

https://mail.python.org/pipermail/python-dev/2002-March/020648.html

> Tim, you have been arguing that civil/legal time arithmetic is not naive.

Yes.  But that's not "an argument", it's a plain fact that Python's
"naive time" (note that "naive" here is technical term, used widely in
the datetime docs) is not civil/legal time (assuming I understand what
you mean by that phrase).

> Calling civil time naive undercuts this claim.

I don't see that I ever said civil time is naive.  Adding a day is
_not_ always the same as adding 24 hours in (at least Lennart's
beliefs about) civil time.  They _are_ always the same in Python's
("naive") datetime arithmetic.  And the latter is all I said in the
quote at the top of this msg.

What am I missing?  It's always something ;-)

From chris.barker at noaa.gov  Mon Jul 27 21:18:49 2015
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 27 Jul 2015 12:18:49 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp5urq$8ks$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <mp5urq$8ks$1@ger.gmane.org>
Message-ID: <CALGmxELeK4tCzXOAtR3j+42YDRE5zN=76aUjw1dh5sZ8=1oxrw@mail.gmail.com>

On Mon, Jul 27, 2015 at 11:55 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> I think using the word 'naive' is both inaccurate and a mistake.
>
<snip>

> 'Naive' means simple, primitive, or deficient in informed judgement. It is
> easy to take it as connoting 'wrong'.


In this context "naive" means "having no knowledge of timezone". And it
does make some sense as a word to use in that case. I don't like it much,
but it's the term used in the datetime module docs, so there you go.

and infact, everything Tim said can also apply to UTC time. We've had a lot
of discussion on teh numpy list about the difference between UTC and
"naive" times, but for practicle putrposes, they are exactly the same --
unitl you try to convert to a known time zone anyway.

But really, the points Tim was making are not about timezones at all -- but
about two concepts:

Time arithmetic with:
 1) Time spans (timedeltas) -- this is an "amount" of time, and can be
added, subtracted, etc to a datetime. such time spans have various
appropriate units, like seconds, days. weeks -- but, as Tim pointed out,
"years" is NOT an appropriate unit of timedeltas, and should not be allowed
in any lib that uses them.

2) Calendar time arithmetic: this is things like "next year", "next week",
"two years from now" -- these are quite tricky, and in some special cases
have no obvious clear definition (leap years, etc...).

Calendar manipulations like (2) should be kept completely separate from
time span manipulation. Is anyone suggesting adding that to the standard
lib?

-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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/5647f43b/attachment.html>

From chris.barker at noaa.gov  Mon Jul 27 21:20:00 2015
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 27 Jul 2015 12:20:00 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAPTjJmoyqdrQmQ5CurDEv1WCY-BYPvVjLJBUE83t7tWAwvufxA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <CAPTjJmoyqdrQmQ5CurDEv1WCY-BYPvVjLJBUE83t7tWAwvufxA@mail.gmail.com>
Message-ID: <CALGmxEJJbK63NdUTnoKgWG62EJc1P5TxhxVf1KgT35Jwq76+GQ@mail.gmail.com>

On Mon, Jul 27, 2015 at 12:07 PM, Chris Angelico <rosuav at gmail.com> wrote:

> > - A minute is exactly 60 seconds.
>
> No leap second support, presumably. Also feature?
>

Leap seconds come in when you convert to a Calendar representation -- a
minute is 60 seconds, always -- even when passing over a leap second.

-CHB



-- 

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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/a3d25467/attachment.html>

From tim.peters at gmail.com  Mon Jul 27 21:23:50 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 14:23:50 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAPTjJmoyqdrQmQ5CurDEv1WCY-BYPvVjLJBUE83t7tWAwvufxA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <CAPTjJmoyqdrQmQ5CurDEv1WCY-BYPvVjLJBUE83t7tWAwvufxA@mail.gmail.com>
Message-ID: <CAExdVNn1NCVpcRUARgtnw38WQMnLZQp_EkDHx8YhgvW0n+3B8Q@mail.gmail.com>

[Tim]
>> But it's a fact that they _are_ the same in naive time, which Python's
>> datetime single-timezone arithmetic implements:
>>
>> - A minute is exactly 60 seconds.
>> ...

[Chris Angelico <rosuav at gmail.com>]
> No leap second support, presumably. Also feature?

Absolutely none, and absolutely "a feature", but that didn't start
with the datetime module.  Read Guido's original 13+ year old message
about "naive time":

https://mail.python.org/pipermail/python-dev/2002-March/020648.html

Note especially this part:

"""
I'm thinking that for most *business* uses of date and time, we should
have the same attitude towards DST that we've already decided to take
towards leap seconds.
"""

Guido has never had the slightest use for leap seconds in any part of
Python's implementation, and has consistently opposed attempts to
incorporate them.  This was well established long before datetime was
even an idea.

Here's another, later quote from him:

"""
Python's datetime objects will not support leap seconds in any way,
shape or form.  A tzinfo object that does support leap seconds is on
its own, but I don't see the point since Python will never represent a
time as a number of seconds since some epoch.  (If you want to get a
POSIX time_t value, you'll have to convert first to local time, then
to a struct tm, and then use mktime().)
"""

From tjreedy at udel.edu  Mon Jul 27 21:42:31 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 27 Jul 2015 15:42:31 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVN=J4P4YrLJomRO13wuhKKFU3kQzZSU_LZ08Zv0aJmv_0Q@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <mp5urq$8ks$1@ger.gmane.org>
 <CAExdVN=J4P4YrLJomRO13wuhKKFU3kQzZSU_LZ08Zv0aJmv_0Q@mail.gmail.com>
Message-ID: <mp61j9$n0n$1@ger.gmane.org>

On 7/27/2015 3:14 PM, Tim Peters wrote:

> [Terry Reedy]
>> I think using the word 'naive' is both inaccurate and a mistake.  The issue
>> is civil or legal time versus STEM time, where the latter includes
>> applications like baking cakes.
>
> Sorry, never heard of "STEM time" before - & a quick Google search didn't help.

Searching for 'STEM' to discover the meaning of the acronym displays, 
for me, after the second
"STEM is an acronym referring to the academic disciplines of science, 
technology, engineering and mathematics." STEM time is the time used in 
science, technology, engineering and mathematics, with the added note 
indicating that I mean for technology and engineering to be taken 
broadly, to include all uses of actual (natural) elapsed time, as 
opposed to occasionally artificial government time.

>> The idea that an hour can be sliced out of a somewhat random March day and
>> inserting it into a somewhat random October day is rather sophisticated.  It
>> came from the minds of government bureaucrats.  It might be smart, dumb, or
>> just a cunning way for civil authorities to show who is in charge by making
>> us all jump.  But not 'naive'.
>
> I agree.  Python's "naive time" single-timezone arithmetic
> intentionally ignores all that:  it ignores leap seconds, it ignores
> DST transition points, it ignores governments deciding to change the
> base UTC offset within a pre-existing time zone, ...  It's time soooo
> naive that it thinks 24 hours is the same thing as a day ;-)

To me, having 1 day be 23 or 25 hours of elapsed time on the DST 
transition days, as in Paul's alarm example, hardly ignores the 
transition point.

-- 
Terry Jan Reedy


From tim.peters at gmail.com  Mon Jul 27 21:53:24 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 14:53:24 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CALGmxELeK4tCzXOAtR3j+42YDRE5zN=76aUjw1dh5sZ8=1oxrw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <mp5urq$8ks$1@ger.gmane.org>
 <CALGmxELeK4tCzXOAtR3j+42YDRE5zN=76aUjw1dh5sZ8=1oxrw@mail.gmail.com>
Message-ID: <CAExdVNnbyLzHEqwHsdNx8KKZJRBjraPhci2YpRGHYX-8UQRc2g@mail.gmail.com>

[Chris Barker]
> ...
> and infact, everything Tim said can also apply to UTC time. We've had a lot
> of discussion on teh numpy list about the difference between UTC and "naive"
> times, but for practicle putrposes, they are exactly the same -- unitl you
> try to convert to a known time zone anyway.

Yes, "naive arithmetic" is "correct" (by everyone's definition) in any
time zone that has a fixed-for-all-eternity offset from UTC.  UTC is
the simplest case of that (with offset 0).

So for all practical purposes you can think of a naive datetime as
being "the time" in any eternally-fixed-offset time zone you like - or
as in no time zone at all (the time zone _concept_ isn't necessary to
grasp naive time - it only takes effort to _forget_ it).  But the
paranoid should consider that nothing can stop governments from
changing the definition of UTC (or any other time zone).  They'll have
to pry your naive datetimes out of your computer's cold, dead disk
drives though ;-)


> ...
> 2) Calendar time arithmetic: this is things like "next year", "next week",
> "two years from now" -- these are quite tricky, and in some special cases
> have no obvious clear definition (leap years, etc...).
>
> Calendar manipulations like (2) should be kept completely separate from time
> span manipulation. Is anyone suggesting adding that to the standard lib?

It comes up, and would be useful to many.  But it's the kind of thing
waiting for an extension module to take the world by storm.  If people
think the bikeshedding in _this_ thread is excessive ... ;-)

From tim.peters at gmail.com  Mon Jul 27 22:10:00 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 15:10:00 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp61j9$n0n$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <mp5urq$8ks$1@ger.gmane.org>
 <CAExdVN=J4P4YrLJomRO13wuhKKFU3kQzZSU_LZ08Zv0aJmv_0Q@mail.gmail.com>
 <mp61j9$n0n$1@ger.gmane.org>
Message-ID: <CAExdVN=fVUaYmiwwxKLfCg+A2gqeUXWbTVCWs7TLha_qCtaBmw@mail.gmail.com>

[Terry Reedy <tjreedy at udel.edu>]
> To me, having 1 day be 23 or 25 hours of elapsed time on the DST transition
> days, as in Paul's alarm example, hardly ignores the transition point.

It's 2:56PM.  What time will it be 24 hours from now?  If your answer
is "not enough information to say, but it will be some minute between
1.56PM and 3:56PM inclusive", you want to call _that_ "naive"?  I sure
don't.  You can only give such an answer if you're acutely aware of
(for example) DST transitions.

If you're truly naive, utterly unaware of the possibility of
occasional time zone adjustments, then you give the obvious answer:
2:56PM.  That's what Python's datetime arithmetic gives.  That's naive
in both technical and colloquial senses.

You're only aware of that "2:56PM tomorrow" may be anywhere between 23
and 25 hours away from "2:56PM today" because you're _not_ ignoring
possible transitions.  So,. sure, I agree that your pointing it out
"hardly ignores the transition point".  But I wasn't talking about you
;-)  I was talking about the arithmetic, which does thoroughly ignore
it.

From ethan at stoneleaf.us  Mon Jul 27 21:47:19 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 27 Jul 2015 12:47:19 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
Message-ID: <55B68AC7.3080501@stoneleaf.us>

On 07/27/2015 07:46 AM, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano wrote:
>>
>> To me, Paul's example is a datetime operation: you start with a datetime
>> (7am today), perform arithmetic on it by adding a period of time (one
>> day), and get a datetime as the result (7am tomorrow).
>
> Well, OK, let's propose these wordings: It looks like a date
> operation, ie, add one to the date, but in reality it's a time
> operation, ie add 86400 seconds to the time. These things sound
> similar but are very different.

I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be at work at 8am I don't care exactly how many seconds have passed, that alarm better go off at 7am local time.

--
~Ethan~

From tim.peters at gmail.com  Mon Jul 27 22:38:31 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 15:38:31 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <20150727101553.GO28550@unequivocal.co.uk>
References: <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <20150727101553.GO28550@unequivocal.co.uk>
Message-ID: <CAExdVNkqgfOkPmHnzZeiXac3jDbU8XNzj7fmbtkGQ9xLcbg4rQ@mail.gmail.com>

[Tim]
>> Python didn't implement timezone-aware arithmetic at all within a
>> single time zone.  Read what I wrote just above.  It implements naive
>> arithmetic within a single time zone.

[Jon Ribbens <jon+python-dev at unequivocal.co.uk>]
> This usage of "time zone" is confusing.

Ha!  _All_ usages of "time zone" are confusing ;-)

This specific use pointed at something pretty trivial to state but
technical:  any instance of Python datetime arithmetic in which the
datetime input(s) and, possibly also the output, share the same tzinfo
member(s).  Specifically:

     datetime + timedelta
     datetime - timedelta
     datetime - datetime

Maybe another, but you get the idea.  Those all do "naive datetime
arithmetic", and in the last case the "same tzinfo member" part is
crucial (if the input datetimes have different tzinfo members in
subtraction, we're no longer "within a single time zone", and time
zone adjustments _are_ made:  it acts like both inputs are converted
to UTC before subtracting; but not so if both inputs share their
tzinfo members).

> As far as I can tell, you really mean "UTC offset". A time zone
> would be something like "Europe/London", which has two different
> UTC offsets throughout the year (not to mention other historical
> weirdnesses), whereas arithmetic on a "timezone-aware" datetime
>: is only going to work so long as you don't cross any of the
> boundaries where the UTC offset changes.

In this context I only had in mind tzinfo members.  They may represent
fixed-offset or multiple-offset "time zones" (or anything else a
programmer dreams up), or may even be None.  The datetime
implementation has no idea what they represent:  the implementation
can only judge whether two given tzinfo objects are or aren't the same
object.  So "within a single time zone" here just means there's only
one tzinfo object in play.

> I agree with you about pretty much everything else about datetime,
> just I find the terminology misleading. The only other thing I found
> really weird about datetime is how Python 2 had no implementation of
> a UTC tzinfo class, despite this being utterly trivial - but it's too
> late to do anything about that now, of course.

At the time, Guido ran his time machine forward, and saw that Stuart
Bishop would soon enough supply all the time zones known to mankind
;-)

From regebro at gmail.com  Mon Jul 27 22:42:27 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 27 Jul 2015 22:42:27 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <55B68AC7.3080501@stoneleaf.us>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B68AC7.3080501@stoneleaf.us>
Message-ID: <CAL0kPAX5Rc6CO8RQu6Ja9ynR0KWA0cd52yNWx97FJMMwR24D2g@mail.gmail.com>

On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 07/27/2015 07:46 AM, Lennart Regebro wrote:
>> Well, OK, let's propose these wordings: It looks like a date
>> operation, ie, add one to the date, but in reality it's a time
>> operation, ie add 86400 seconds to the time. These things sound
>> similar but are very different.
>
> I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be at
> work at 8am I don't care exactly how many seconds have passed, that alarm
> better go off at 7am local time.

Right. And then adding 86400 seconds to it is not the right thing to do.

//Lennart

From brett at python.org  Mon Jul 27 22:52:33 2015
From: brett at python.org (Brett Cannon)
Date: Mon, 27 Jul 2015 20:52:33 +0000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUU+3BnU3s7_j2DmeY3odyrZZ6bniEsOi2KtNr3TKm1-g@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7es2sBn+gVOBxi0yLGqGr572MRyjiMf8vAK56ep-RKM8g@mail.gmail.com>
 <CAL0kPAUU+3BnU3s7_j2DmeY3odyrZZ6bniEsOi2KtNr3TKm1-g@mail.gmail.com>
Message-ID: <CAP1=2W5ZfOaqfapcLa+ReHzA7qNiYfsMJz-Q_JGm=15HWPe=zg@mail.gmail.com>

On Mon, Jul 27, 2015 at 7:49 AM Lennart Regebro <regebro at gmail.com> wrote:

> On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 28 July 2015 at 00:27, Steve Dower <Steve.Dower at microsoft.com> wrote:
> >> Am I the only one feeling like this entire thread should be moved to
> >> python-ideas at this point?
> >
> > Since this is an area where the discussion of implementation details
> > and the discussion of the developer experience can easily end up at
> > cross purposes, I'm wondering if there may be value in actually
> > splitting those two discussions into different venues by creating a
> > datetime-sig, and specifically inviting the pytz and dateutil
> > developers to participate in the SIG as well.
>
> +1 for that.
>

Alexander and Tim, you okay with moving this conversation to a datetime-sig
if we got one created?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/1f1e2442/attachment.html>

From tim.peters at gmail.com  Mon Jul 27 23:10:12 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 16:10:12 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
Message-ID: <CAExdVNniaJpSeV+8P0GvfPNJbn0KSEJ7WVScZ-89cJuHx7GATw@mail.gmail.com>

[Paul Moore]
> ...
> I think the following statements are true. If they aren't, I'd
> appreciate clarification. I'm going to completely ignore leap seconds
> in the following - I hope that's OK, I don't understand leap seconds
> *at all* and I don't work in any application areas where they are
> relevant (to my knowledge) so I feel that for my situation, ignoring
> them (and being able to) is reasonable.

Guido will never allow any aspect of "leap seconds" into the core,
although it's fine by him if someone wants to write their own tzinfo
class to try to model them.


> Note that I'm not talking about internal representations - this is
> purely about user-visible semantics.
>
> 1. "Naive" datetime arithmetic means treating a day as 24 hours, an
> hour as 60 minutes, etc. Basically base-24/60/60 arithmetic.

It also means that the tzinfo(s) member (if any) is(are) ignored.  So
not only leap seconds are ignored:

1. Possible DST transitions are ignored.
2. Possible changes to the base UTC offset are ignored.
3. Possible changes to the name of the time zone (even if "the rules"
don't change) are ignored.
4. Everything else whatsover that could be learned from the tzinfo
member is ignored.

Note that in "aware" arithmetic, the current fromutc() implementation
is only strong enough to account reliably for #1.

> 2. If you're only working in a single timezone that's defined as UTC
> or a fixed offset from UTC, naive arithmetic is basically all there
> is.

Yup!

> 3. Converting between (fixed offset) timezones is a separate issue
> from calculation - but it's nothing more than applying the relevant
> offsets.

Yup!  Although that can't be exploited by Python:  there's nothing in
a tzinfo instance Python can query to discover the rules it
implements.

> 4. Calculations involving 2 different timezones (fixed-offset ones as
> above) is like any other exercise involving values on different
> scales. Convert both values to a common scale (in this case, a common
> timezone) and do the calculation there. Simple enough.

Yup.

> 5. The problems all arise *only* with timezones whose UTC offset
> varies depending on the actual time (e.g., timezones that include the
> transition to DST and back).

Yup.

> Are we OK to this point? This much comprises what I would class as a
> "naive" (i.e. 99% of the population ;-)) understanding of datetimes.
>
> The stdlib datetime module handles naive datetime values, and
> fixed-offset timezones, fine, as far as I can see.

It ignores the possibility called #3 above (that some bureaucrat
changed the name of a fixed-offset time zone despite that the offset
didn't change).  Everyone ignores #4, and always will ;-)

> (I'm not sure that the original implementation included fixed-offset tzinfo
> objects, but the 3.4 docs say they are there now, so that's fine).

The original implementation supplied no tzinfo objects, only an
abstract tzinfo base class.

> Looking at the complicated cases, the only ones I'm actually aware of
> in practice are the ones that switch to DST and back, so typically
> have two offsets that differ by an hour,

Some number of minutes, anyway (not all DST transitions move by whole hours).

> switching between the two at some essentially arbitrary points. If there are
> other more complex forms of timezone, I'd like to never need to know about
> them, please ;-)

#2 above is common enough, although there's not a _lot_ of
base-offset-changing going on in current times.

> The timezones we're talking about here are things like
> "Europe/London", not "GMT" or "BST" (the latter two are fixed-offset).
>
> There are two independent issues with complex timezones:
>
> 1. Converting to and from them. That's messy because the conversion to
> UTC needs more information than just the date & time (typically, for
> example, there is a day when 01:45:00 maps to 2 distinct UTC times).
> This is basically the "is_dst" bit that Tim discussed in an earlier
> post. The semantic issue here is that users typically say "01:45" and
> it never occurs to them to even think about *which* 01:45 they mean.
> So recovering that extra information is hard (it's like dealing with
> byte streams where the user didn't provide details of the text
> encoding used).

"Flatly impossible" is more on target than "hard".  In the case of
text encoding, it's often possible to guess correctly by statistical
analysis of the bytes.  01:45:00 in isolation gives no clue at all
about whether standard or daylight time was intended.  A similar point
applies to some ambiguous cases when the base ("standard") UTC offset
changes.

> Once we have the extra information, though, doing
> conversions is just a matter of applying a set of rules.

Yup, and it's easy.

> 2. Arithmetic within a complex timezone. Theoretically, this is simple
> enough (convert to UTC, do the calculation naively, and convert back).
> But in practice, that approach doesn't always match user expectations.
> So you have 2 mutually incompatible semantic options - 1 day after 4pm
> is 3pm the following day, or adding 1 day adds 25 hours - either is a
> viable choice, and either will confuse *some* set of users. This, I
> think, is the one where all the debate is occurring, and the one that
> makes my head explode.

Stick to naive time, and your head won't even hurt ;-)  There is no
"right" or "wrong" answer to this one:  different apps can _need_
different behaviors for this.  Python picked one to make dead easy
("naive"), and intended to make the other _possible_ via longer-winded
(but conceptually straightforward) code.

> It seems to me that the problem is that for this latter issue, it's
> the *timedelta* object that's not rich enough. You can't say "add 1
> day, and by 1 day I mean keep the same time tomorrow" as opposed to
> "add 1 day, and by that I mean 24 hours"[1]. In some ways, it's
> actually no different from the issue of adding 1 month to a date
> (which is equally ill-defined, but people "know what they mean" to
> just as great an extent). Python bypasses the latter by not having a
> timedelta for "a month". C (and the time module) bypasses the former
> by limiting all time offsets to numbers of seconds - datetime gave us
> a richer timedelta object and hence has extra problems.

There's more to it than that.  "Naive time" also wants, e.g.,
"01:45:00 tomorrow minus 01:45:00 today" to return 24 hours.  Maybe
the same thing in disguise, though.

> I don't have any solutions to this final issue. But hopefully the
> above analysis (assuming it's accurate!) helps clarify what the actual
> debate is about, for those bystanders like me who are interested in
> following the discussion. With luck, maybe it also gives the experts
> an alternative perspective from which to think about the problem - who
> knows?
>
> Paul
>
> [1] Well, you can, actually - you say that a timedelta of "1 day"
> means "the same time tomorrow" and if you want 24 hours, you say "24
> hours" not "1 day". So timedelta(days=1) != timedelta(hours=24) even
> though they give the same result for every case except arithmetic
> involving complex timezones.

While perhaps that _could_ have been said at the start, it's a decade
too late to say that now ;-)

> Is that what Lennart has been trying to say in his posts?

Have to leave that to him to say.  Various date-and-time
implementations have all sorts of gimmicks.  Possibilities raised in
this thread so far kind of scratch the surface :-(

From ethan at stoneleaf.us  Mon Jul 27 23:13:07 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 27 Jul 2015 14:13:07 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAX5Rc6CO8RQu6Ja9ynR0KWA0cd52yNWx97FJMMwR24D2g@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B68AC7.3080501@stoneleaf.us>
 <CAL0kPAX5Rc6CO8RQu6Ja9ynR0KWA0cd52yNWx97FJMMwR24D2g@mail.gmail.com>
Message-ID: <55B69EE3.50807@stoneleaf.us>

On 07/27/2015 01:42 PM, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman wrote:
>> On 07/27/2015 07:46 AM, Lennart Regebro wrote:

>>> Well, OK, let's propose these wordings: It looks like a date
>>> operation, ie, add one to the date, but in reality it's a time
>>> operation, ie add 86400 seconds to the time. These things sound
>>> similar but are very different.
>>
>> I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be at
>> work at 8am I don't care exactly how many seconds have passed, that alarm
>> better go off at 7am local time.
>
> Right. And then adding 86400 seconds to it is not the right thing to do.

Yes, it is, because that's the number that will get me to 7am the next day.  My program has no control over the computer's clock -- it merely works with what it is told by the computer's clock.

--
~Ethan~

From tim.peters at gmail.com  Mon Jul 27 23:13:33 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 16:13:33 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAP1=2W5ZfOaqfapcLa+ReHzA7qNiYfsMJz-Q_JGm=15HWPe=zg@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7es2sBn+gVOBxi0yLGqGr572MRyjiMf8vAK56ep-RKM8g@mail.gmail.com>
 <CAL0kPAUU+3BnU3s7_j2DmeY3odyrZZ6bniEsOi2KtNr3TKm1-g@mail.gmail.com>
 <CAP1=2W5ZfOaqfapcLa+ReHzA7qNiYfsMJz-Q_JGm=15HWPe=zg@mail.gmail.com>
Message-ID: <CAExdVN=me3Ov+JyEVoQjnhgqTuB6B6VRTG60QXQYsSd=nJ_Xxg@mail.gmail.com>

[Brett Cannon <brett at python.org>]
\> Alexander and Tim, you okay with moving this conversation to a datetime-sig
> if we got one created?

Fine by me!

From p.f.moore at gmail.com  Mon Jul 27 23:19:08 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2015 22:19:08 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNniaJpSeV+8P0GvfPNJbn0KSEJ7WVScZ-89cJuHx7GATw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
 <CAExdVNniaJpSeV+8P0GvfPNJbn0KSEJ7WVScZ-89cJuHx7GATw@mail.gmail.com>
Message-ID: <CACac1F_si2dEKEmBO5CdipMn3eWkUaLn9X-DQBw0_kJ72M-q3Q@mail.gmail.com>

On 27 July 2015 at 22:10, Tim Peters <tim.peters at gmail.com> wrote:
>> 1. Converting to and from them. That's messy because the conversion to
>> UTC needs more information than just the date & time (typically, for
>> example, there is a day when 01:45:00 maps to 2 distinct UTC times).
>> This is basically the "is_dst" bit that Tim discussed in an earlier
>> post. The semantic issue here is that users typically say "01:45" and
>> it never occurs to them to even think about *which* 01:45 they mean.
>> So recovering that extra information is hard (it's like dealing with
>> byte streams where the user didn't provide details of the text
>> encoding used).
>
> "Flatly impossible" is more on target than "hard".  In the case of
> text encoding, it's often possible to guess correctly by statistical
> analysis of the bytes.  01:45:00 in isolation gives no clue at all
> about whether standard or daylight time was intended.  A similar point
> applies to some ambiguous cases when the base ("standard") UTC offset
> changes.

By "hard", what I meant was that you'd have to explain what you need
to the user, and accept their answer, in the user interface to your
application. Explaining why you need to know in a way that isn't
totally confusing is what I classed as "hard".

I wouldn't even consider trying to guess the user's intent. Although
"if you don't say, I'll use naive datetimes" seems to me a plausible
position to take if you want to allow the user not to care. Strange
that this is how Python works... ;-)

Paul

From ethan at stoneleaf.us  Mon Jul 27 23:30:45 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 27 Jul 2015 14:30:45 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <55B69EE3.50807@stoneleaf.us>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B68AC7.3080501@stoneleaf.us>
 <CAL0kPAX5Rc6CO8RQu6Ja9ynR0KWA0cd52yNWx97FJMMwR24D2g@mail.gmail.com>
 <55B69EE3.50807@stoneleaf.us>
Message-ID: <55B6A305.60806@stoneleaf.us>

To use Alexander's example:
>
> --> t = datetime(2015, 3, 7, 12, tzinfo=timezone('US/Eastern'))
> --> t.strftime('%D %T %z %Z')
> '03/07/15 12:00:00 -0500 EST'
>
> --> (t + timedelta(1)).strftime('%D %T %z %Z')
> '03/08/15 12:00:00 -0400 EDT'

The data (aka the time) should act naively, but the metadata (aka the timezone) is what should be changing [1].

--
~Ethan~

[1] Which is to say that naive datetime's should continue as-is, and aware datetimes should exhibit the above behavior.

From tseaver at palladion.com  Mon Jul 27 23:34:20 2015
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 27 Jul 2015 17:34:20 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
Message-ID: <mp684v$676$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/27/2015 02:04 AM, Tim Peters wrote:
> The naive arithmetic within a timezone is already correct, by its own 
> internal criteria.  It's also useful (see the original discussions,
> or Paul Moore's recent brief account).

"Naive" alarm clocks (those which don't know from timezones) break human
expectations twice a year, because their users have to be awake to fix
them (or make the clock itself out-of-whack with real civil time for the
hours between fixing and the actual transition). For confirmatoin, ask
your local priest / pastor about the twice yearly mixups among
congregants whose clocks don't self-adjust for the DST boundary:  some
show up late / early for church *every* time the local zone changes.

I'd be in favor of dropping "days" from timedelta, myself, for just this
reason:  if "1 day" is the same for your usecase as "24 hours", then just
do the math yourself.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVtqPcAAoJEPKpaDSJE9HY4oEP+wUSWTeQS7cn3FLVBOeUV/lZ
MIqZSnIGYOaSS6JDo2oTjm+yQWySEp5QMXHNYohPOkkkYDdu8L/r250KKb6F3fbo
OMnNXlBCVHi66kFCs0x3+zQIlhSzkYV2FcT39gNu0llw5gODtmbbvYZE+CA4ej6R
PIhnizyT7bXa+q2WYBrL0/+w/IBuv4H3d/x0b79cPZpqRZeI57k90qsee9SSPyDb
MGs76IUOfJuZNruqfuY+zhFlfwB5kOt8U4kTlXZS4At1TKskoH5zuIiaHZooN6gy
fBz3Zzt2XKYiWPWrzEbVeXrdXmAFRyr5sWqVQ0SliKA06rq1Tr5h53orGLidMaPe
noUnz8YQHssY5e/kAbSUv6C93GNbldNEFOV1Ab03JT+NPrhNxPqi1ZGTJsMDc+Tl
HI2I5C1TXW8ZPx/US2+Zt0yu0HX82EX03UPlRW4wZZSyKw7eCosF9fWXwufF9yTP
9v0otEB/x3rN1TJgc+7U4r1JmYPy+eYyjKs1xy58kb/a7awSvlmEeWvQelGqQKc+
lnRT6VxzVlgmTginq/5oHyFkI5OFTYuukuQDZx3ocd1g7EX42pNRYHVcMbZiQ9L5
DFKrENQDkegTkX+g1BUlVSW67smrFfki6Y7O/5R378x+q/sn6oqYe9334C+ccbz8
8jA16niF9EiwaxieLH9w
=I31e
-----END PGP SIGNATURE-----


From tim.peters at gmail.com  Tue Jul 28 00:03:28 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 17:03:28 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp684v$676$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
Message-ID: <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>

[Tres Seaver <tseaver at palladion.com>]
> "Naive" alarm clocks (those which don't know from timezones) break human
> expectations twice a year, because their users have to be awake to fix
> them (or make the clock itself out-of-whack with real civil time for the
> hours between fixing and the actual transition). For confirmatoin, ask
> your local priest / pastor about the twice yearly mixups among
> congregants whose clocks don't self-adjust for the DST boundary:  some
> show up late / early for church *every* time the local zone changes.

Sure.  I don't see how this applies to Python's arithmetic, though.
For a start, you're talking about alarm clocks ;-)  Note that "naive"
is a technical term in the datetime context, used all over the
datetime docs.  However, I'm using "naive arithmetic" as a shorthand
for what would otherwise be a wall of text.  That's my own usage; the
docs only apply "naive" and "aware" to date, time and datetime objects
(not to operations on such objects).


> I'd be in favor of dropping "days" from timedelta, myself, for just this
> reason:  if "1 day" is the same for your usecase as "24 hours", then just
> do the math yourself.

timedelta objects only store days, seconds, and microseconds, which is
advertised.  It would be bizarre not to allow to set them directly.
They're the only timedelta components for which instance attributes
exist.  In the timedelta constructor, it's the seconds,  milliseconds,
minutes, hours, and weeks arguments that exist solely for convenience.
You could "do the math yourself" for all those too - but why would you
want to make anyone do that for any of them?  All the world's alarm
clocks would remain just as broken regardless ;-)

Even if days weren't a distinguished unit for timedelta, I'd still
much rather write, e.g.,

    timedelta(days=5, hours=3)

than

    timedelta(hours=123)

or

    timedelta(hours=5*24 + 3)

etc.  The intent of the first spelling is obvious at a glance.

From ronaldoussoren at mac.com  Tue Jul 28 00:11:00 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 28 Jul 2015 00:11:00 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu> <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu> <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
Message-ID: <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>



> On 27 jul. 2015, at 20:49, Tim Peters <tim.peters at gmail.com> wrote:
> 
> [Ronald Oussoren <ronaldoussoren at mac.com>]
>> IMHO ?+ 1 days? and ?+ 24 hours? are two different things.
>> Date arithmetic is full of messy things like that.
> 
> But it's a fact that they _are_ the same in naive time, which Python's
> datetime single-timezone arithmetic implements:
> 
> ...
> 
> Naive time is easy to understand, reason about, and work with.  When
> it comes to the real world, political adjustments to and within time
> zones can make the results dodgy, typically in the two DST-transition
> hours per year when most people living in a given time zone are
> sleeping.  How much complexity do you want to endure in case they wake
> up? ;-)  Guido's answer was "none in arithmetic - push all the
> complexity into conversions - then most uses can blissfully ignore the
> complexities".

I totally agree with that, having worked on applications that had to deal with time a lot and including some where the end of a day was at 4am the following day.  That app never had to deal with DST because not only are the transitions at night, the are also during the weekend. 


Treating time as UTC with conversions at the application edge might be "cleaner" in some sense, but can make code harder to read for application domain experts.

It might be nice to have time zone aware datetime objects with the right(TM) semantics, but those can and should not replace the naive objects we know and love. 

That said,  I have had the need for date delta objects that can deal with deltas expressed at days or months but it is easy enough to write your own library for that that can deal with the local conventions for those. 

Ronald

From alexander.belopolsky at gmail.com  Tue Jul 28 00:30:42 2015
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 27 Jul 2015 18:30:42 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVN=me3Ov+JyEVoQjnhgqTuB6B6VRTG60QXQYsSd=nJ_Xxg@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <BLUPR0301MB1652309D80858850ECE69320F58E0@BLUPR0301MB1652.namprd03.prod.outlook.com>
 <CADiSq7es2sBn+gVOBxi0yLGqGr572MRyjiMf8vAK56ep-RKM8g@mail.gmail.com>
 <CAL0kPAUU+3BnU3s7_j2DmeY3odyrZZ6bniEsOi2KtNr3TKm1-g@mail.gmail.com>
 <CAP1=2W5ZfOaqfapcLa+ReHzA7qNiYfsMJz-Q_JGm=15HWPe=zg@mail.gmail.com>
 <CAExdVN=me3Ov+JyEVoQjnhgqTuB6B6VRTG60QXQYsSd=nJ_Xxg@mail.gmail.com>
Message-ID: <CAP7h-xYwOU_b8-T0fs_LN5DEFYXEm5g3+Lo4WfmaB=x64pirQA@mail.gmail.com>

On Mon, Jul 27, 2015 at 5:13 PM, Tim Peters <tim.peters at gmail.com> wrote:

> [Brett Cannon <brett at python.org>]
> \> Alexander and Tim, you okay with moving this conversation to a
> datetime-sig
> > if we got one created?
>
> Fine by me!
>

+1

Didn't  datetime-sig exist some 12 years ago?  It would be nice to get some
continuity from that effort.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/5ba30a38/attachment.html>

From ischwabacher at wisc.edu  Tue Jul 28 00:38:34 2015
From: ischwabacher at wisc.edu (ISAAC J SCHWABACHER)
Date: Mon, 27 Jul 2015 22:38:34 +0000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
References: <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
Message-ID: <SN1PR06MB1824D3A91BB742D6622ED1F2B68E0@SN1PR06MB1824.namprd06.prod.outlook.com>

Responses to several partial messages follow.

[Lennart Regebro]
> Then we can't implement timezones in a reasonable way with the current
> API, but have to have something like pytz's normalize() function or
> similar.
>
> I'm sorry I've wasted everyones time with this PEP.

[ijs]
I think that integrating pytz into the stdlib, which is what the PEP proposes, would be valuable even without changing datetime arithmetic. But I see ways to accomplish the latter without breaking backward compatibility. The dream ain't dead! See below.

[Paul Moore]
> 2. Arithmetic within a complex timezone. Theoretically, this is simple
> enough (convert to UTC, do the calculation naively, and convert back).
> But in practice, that approach doesn't always match user expectations.
> So you have 2 mutually incompatible semantic options - 1 day after 4pm
> is 3pm the following day, or adding 1 day adds 25 hours - either is a
> viable choice, and either will confuse *some* set of users. This, I
> think, is the one where all the debate is occurring, and the one that
> makes my head explode.

> It seems to me that the problem is that for this latter issue, it's
> the *timedelta* object that's not rich enough.

[ijs]
Yes! This is the heart of the matter. We can solve *almost* all the problems by having multiple competing timedelta classes-- which we already have. Do you care about what will happen after a fixed amount of elapsed time? Use `numpy.timedelta64` or `pandas.Timedelta`. Want this time tomorrow, come hell, high water, or DST transition? Use `dateutil.relativedelta.relativedelta` or `mx.DateTime.RelativeDateTime`. As long as the timedelta objects we're using are rich enough, we can make `dt + delta` say what we mean. There's no reason we can't have both naive and aware arithmetic in the stdlib at once.

All the stdlib needs is an added timedelta class that represents elapsed atomic clock time, and voila!

The biggest problem that this can't solve is subtraction. Which timedelta type do you get by subtracting two datetimes? Sure, you can have a `datetime.elapsed_since(self, other: datetime, **kwargs) -> some_timedelta_type` that determines what you want from the kwargs, but `datetime.__sub__` doesn't have that luxury. I think the right answer is that subtraction should yield the elapsed atomic clock time, but that would be a backward-incompatible change so I don't put a high probability on it happening any time soon. See the last message (below) for more on this.

> You can't say "add 1
> day, and by 1 day I mean keep the same time tomorrow" as opposed to
> "add 1 day, and by that I mean 24 hours"[1]. In some ways, it's
> actually no different from the issue of adding 1 month to a date
> (which is equally ill-defined, but people "know what they mean" to
> just as great an extent). Python bypasses the latter by not having a
> timedelta for "a month". C (and the time module) bypasses the former
> by limiting all time offsets to numbers of seconds - datetime gave us
> a richer timedelta object and hence has extra problems.

Because of the limits on the values of its members, `datetime.timedelta` is effectively just a counter of microseconds. It can't distinguish between 1 day, 24 hours, 1440 minutes or 86400 seconds. They're all normalized to the same value. So it's not actually richer; it only appears so.

> I don't have any solutions to this final issue. But hopefully the
> above analysis (assuming it's accurate!) helps clarify what the actual
> debate is about, for those bystanders like me who are interested in
> following the discussion. With luck, maybe it also gives the experts
> an alternative perspective from which to think about the problem - who
> knows?
>
> Paul
>
> [1] Well, you can, actually - you say that a timedelta of "1 day"
> means "the same time tomorrow" and if you want 24 hours, you say "24
> hours" not "1 day". So timedelta(days=1) != timedelta(hours=24) even
> though they give the same result for every case except arithmetic
> involving complex timezones. Is that what Lennart has been trying to
> say in his posts?

I thought for a long time that this would be sufficient, and I still think it's a good spelling that makes it clear what the user wants most of the time, but I have wanted things like "the first time the clock shows 1 hour later than it shows right now" enough times that I no longer think this is quite sufficient. (I *think* you can do that with `dt + dateutil.relativedelta.relativedelta(hour=dt.hour+1, minute=0, second=0, microsecond=0)`, but I'm not sure.)

[Tim Peters]
> Ah, but it already happens that way - because the builtin datetime
> arithmetic is "naive".  The docs have always promised this:
>
> """
> datetime2 = datetime1 + timedelta (1)
> datetime2 = datetime1 - timedelta (2)
>
> 1) datetime2 is a duration of timedelta removed from datetime1, moving
> forward in time if timedelta.days > 0, or backward if timedelta.days <
> 0. The result has the same tzinfo attribute as the input datetime, and
> datetime2 - datetime1 == timedelta after. OverflowError is raised if
> datetime2.year would be smaller than MINYEAR or larger than MAXYEAR.
> Note that no time zone adjustments are done even if the input is an
> aware object.
>
> 2) Computes the datetime2 such that datetime2 + timedelta ==
> datetime1. As for addition, the result has the same tzinfo attribute
> as the input datetime, and no time zone adjustments are done even if
> the input is aware. This isn?t quite equivalent to datetime1 +
> (-timedelta), because -timedelta in isolation can overflow in cases
> where datetime1 - timedelta does not.
> """

[ijs]
Once we add the is_dst bit, this becomes a problem. You can't have this and have equality be a congruence (i.e., dt1 == dt2 implies dt1+td == dt2+td) unless you're willing to have the is_dst bit always be significant to equality, even when a time isn't ambiguous. Practically, this means that equality stops being a congruence, but failing to obey that invariant causes a lot of trouble.


I have been remiss in not pointing this out, but it's wrong to assume that scientists use exclusively UTC. I got dragged into this mess because I was writing a piece of software to analyze circadian patterns of physical activity in our research subjects, which meant that in several cases we had a continuous record of data that crossed a DST boundary and we needed absolute durations between different times while caring about the local times between which those durations arose. The program started in ruby using ActiveSupport/Time (Rails's time bits) and got ported into python because ruby didn't have good enough support for scientific applications. I was able to get the program working using pandas's Timestamp class, which I think is more or less what Lennart wants to implement (minus all the cruft where it tries to interoperate with both datetime.datetime and numpy.datetime64), and which AFAICT seems to be the de facto standard for people in the science and finance worlds who need to deal with local times, absolute durations and relative durations all at the same time.

ijs

From v+python at g.nevcal.com  Tue Jul 28 00:40:31 2015
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Mon, 27 Jul 2015 15:40:31 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAX5Rc6CO8RQu6Ja9ynR0KWA0cd52yNWx97FJMMwR24D2g@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B68AC7.3080501@stoneleaf.us>
 <CAL0kPAX5Rc6CO8RQu6Ja9ynR0KWA0cd52yNWx97FJMMwR24D2g@mail.gmail.com>
Message-ID: <55B6B35F.9070306@g.nevcal.com>

On 7/27/2015 1:42 PM, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 07/27/2015 07:46 AM, Lennart Regebro wrote:
>>> Well, OK, let's propose these wordings: It looks like a date
>>> operation, ie, add one to the date, but in reality it's a time
>>> operation, ie add 86400 seconds to the time. These things sound
>>> similar but are very different.
>> I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be at
>> work at 8am I don't care exactly how many seconds have passed, that alarm
>> better go off at 7am local time.
> Right. And then adding 86400 seconds to it is not the right thing to do.

It is the right thing to do... but one also adds/subtracts 3600 seconds 
from it before going to bed 2 days a year, due to government 
interference, unless it is an atomic clock or cell-phone, which do those 
updates automatically.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/878a1774/attachment.html>

From chris.barker at noaa.gov  Tue Jul 28 01:24:36 2015
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 27 Jul 2015 16:24:36 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <55B68AC7.3080501@stoneleaf.us>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B68AC7.3080501@stoneleaf.us>
Message-ID: <CALGmxEKQs06W_6Et9tnwgzGFiqA8as8TWUWncLpY-=e3Sm2Sig@mail.gmail.com>

On Mon, Jul 27, 2015 at 12:47 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> To me, Paul's example is a datetime operation: you start with a datetime
>>> (7am today), perform arithmetic on it by adding a period of time (one
>>> day), and get a datetime as the result (7am tomorrow).
>>>
>>
>> Well, OK, let's propose these wordings: It looks like a date
>> operation, ie, add one to the date, but in reality it's a time
>> operation, ie add 86400 seconds to the time. These things sound
>> similar but are very different.
>>
>
> I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be
> at work at 8am I don't care exactly how many seconds have passed, that
> alarm better go off at 7am local time.
>

sure, but that is very much a Calendar operation -- "7am tomorrow", On the
other hand, if you wanted to sleep a particular length of time,t hen you
might want your alarm to go off "in 8 hours" -- that is a different
operation.

Calendar operations are very, very useful, but not on the table in this
discussion, are they?

-CHB



-- 

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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/e2c2b7cc/attachment-0001.html>

From chris.barker at noaa.gov  Tue Jul 28 01:28:48 2015
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 27 Jul 2015 16:28:48 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkqgfOkPmHnzZeiXac3jDbU8XNzj7fmbtkGQ9xLcbg4rQ@mail.gmail.com>
References: <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <20150727101553.GO28550@unequivocal.co.uk>
 <CAExdVNkqgfOkPmHnzZeiXac3jDbU8XNzj7fmbtkGQ9xLcbg4rQ@mail.gmail.com>
Message-ID: <CALGmxEK8DRq_XbEzKN3GnFibKZC2rCEXYkgU5Hv68ap4+ty2zw@mail.gmail.com>

> The only other thing I found
> > really weird about datetime is how Python 2 had no implementation of
> > a UTC tzinfo class, despite this being utterly trivial -


Huh? it is either so trivial that there is no point -- simiply say that
your datetimes are UTC, and you are done.

Or it's not the least bit trivial -- the only difference between a UTC
datetime and a "naive" datetime is that one can be converted to (or
interact with) other time zones. Except that, as we know from this
conversation, is very, very non-trivial!

(Also, technically, UTC would use leap-seconds...)

-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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/ea4ae665/attachment.html>

From bcannon at gmail.com  Tue Jul 28 00:33:32 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Mon, 27 Jul 2015 22:33:32 +0000
Subject: [Python-Dev] Please create the datetime-sig mailing list
Message-ID: <CAP1=2W4LS97t3u8Jxe5a7Cd+3BvNukn6SL-U4yUVx+KeUzHCpQ@mail.gmail.com>

[bcc'ed python-dev]

Initial admin can be me and I will be in charge of finding more suitable
admins to manage the list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/6fa07bd9/attachment.html>

From chris.barker at noaa.gov  Tue Jul 28 01:53:21 2015
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 27 Jul 2015 16:53:21 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNniaJpSeV+8P0GvfPNJbn0KSEJ7WVScZ-89cJuHx7GATw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
 <CAExdVNniaJpSeV+8P0GvfPNJbn0KSEJ7WVScZ-89cJuHx7GATw@mail.gmail.com>
Message-ID: <CALGmxEL-XHRVKt8eDDZ9FyFGkPRpSZkfG1cRwD=5tqwjjLnMRA@mail.gmail.com>

On Mon, Jul 27, 2015 at 2:10 PM, Tim Peters <tim.peters at gmail.com> wrote:


> Guido will never allow any aspect of "leap seconds" into the core,
>

really? that is a shame (and odd) -- it's a trick, because we don't know
what leap seconds will be needed in the future, but other than that, it's
not really any different than leap years, and required for "proper"
conversion to/from calendar description of time (at least for UTC, the GPS
folks have their own ideas about all this).

But leap seconds are the big red herring -- darn few people need them! It's
pretty rare, indeed, to be expressing your time in gregorian dates, and
also care about accuracy down to the seconds over centuries....

> 2. If you're only working in a single timezone that's defined as UTC
> > or a fixed offset from UTC, naive arithmetic is basically all there
> > is.
>
> Yup!
>

and remarkably useful!


> > 5. The problems all arise *only* with timezones whose UTC offset
> > varies depending on the actual time (e.g., timezones that include the
> > transition to DST and back).
>
> Yup.
>

which is a good reason to "store" your datetime in UTC, and do all the math
there.


> > Are we OK to this point? This much comprises what I would class as a
> > "naive" (i.e. 99% of the population ;-)) understanding of datetimes.
> >
> > The stdlib datetime module handles naive datetime values, and
> > fixed-offset timezones, fine, as far as I can see.
>
> It ignores the possibility called #3 above (that some bureaucrat
> changed the name of a fixed-offset time zone despite that the offset
> didn't change).


Should the code ever care about a time zone's name? it seems that two
tzinfo objects should only be considered the same if they ar the same
instance. period. so not sure what the real issue is with (3)

> 2. Arithmetic within a complex timezone. Theoretically, this is simple
> > enough (convert to UTC, do the calculation naively, and convert back).
> > But in practice, that approach doesn't always match user expectations.
>

what reasonable expectation does this not match?


> > So you have 2 mutually incompatible semantic options - 1 day after 4pm
> > is 3pm the following day, or adding 1 day adds 25 hours - either is a
> > viable choice, and either will confuse *some* set of users. This, I
> > think, is the one where all the debate is occurring, and the one that
> > makes my head explode.
>

This is what I"ve been calling (is there a standard name for it?) a
Calendar operation:

" this time the next day" -- that could be 23, 24, or 25 hours, if you are
bridging a DST transition -- but that kind of operation should not be in
the stdlib -- unless, of course, an entire "work with calendar time" lib is
added -- but that's a whole other story.

for a datetime.timedelta -- a day is 24 hours is a day. period, always.

So you can compute "one day from now", which is the same as "24 hours from
now" or 1440 minutes from now, or ...., but you can't compute "this time
tomorrow" -- not with a timedelta, anyway.

Python picked one to make dead easy
> ("naive"), and intended to make the other _possible_ via longer-winded
> (but conceptually straightforward) code.
>

exactly -- you can extract the year, month, day -- add one to the day, and
then go back. But then you'll need to do all the "30 days hath September"
stuff - and leap years, and ...

which is why all that is another ball of wax. And by the way -- doesn't
dateutil have all that?

>  datetime gave us
> > a richer timedelta object and hence has extra problems.
>

it's only a little richer, and doesn't really add problems, just doesn't
solve some common problems...

There's more to it than that.  "Naive time" also wants, e.g.,
> "01:45:00 tomorrow minus 01:45:00 today" to return 24 hours.  Maybe
> the same thing in disguise, though.
>

I think so -- but it's not a "problem" because the datetime module doesn't
have any way to express "tomorrow" anyway.


> > [1] Well, you can, actually - you say that a timedelta of "1 day"
> > means "the same time tomorrow" and if you want 24 hours, you say "24
> > hours" not "1 day". So timedelta(days=1) != timedelta(hours=24) even
> > though they give the same result for every case except arithmetic
> > involving complex timezones.
>

they always give the same result -- even with complex time zones. I don't
think timedelta evey needs to know about timezones at all. timedelta, is
actually really, really simple, all it needs to know is how to translate
various units into its internal representation (days, seconds, microseconds
?)

-CHB


-- 

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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/59df8d7a/attachment.html>

From tseaver at palladion.com  Tue Jul 28 02:58:46 2015
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 27 Jul 2015 20:58:46 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
Message-ID: <55B6D3C6.80106@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/27/2015 06:03 PM, Tim Peters wrote:

> Even if days weren't a distinguished unit for timedelta, I'd still 
> much rather write, e.g.,
> 
> timedelta(days=5, hours=3)
> 
> than
> 
> timedelta(hours=123)
> 
> or
> 
> timedelta(hours=5*24 + 3)
> 
> etc.  The intent of the first spelling is obvious at a glance.

- From a human's perspective, "a day from now" is always potentially
unambigous, just like "a month from now" or "a year from now", whereas
"24 hours from now" is never so.  In a given application, a user who
doesn't care can always write a helper function to generate hours;  in an
applicatino whose developer who *does* care, the 'days' argument to
timedelta in its current does *not* help achieve her goal:  it is an
attractive nuisance she will have to learn to avoid.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVttPGAAoJEPKpaDSJE9HY0N4QAMQ+Q1/m6Dgg97aS1fRFrMA1
gi7lrWEuW0II0V9bOvB+j0IkASBahreauYb+MBnXXSy1JEDRpVQX7h4SHzLMQ+TF
YSKnxCCY1UktpegkriZF7FoN8Rhv3egA01qWPO0RjHUkZym7/W2zN5cXhRTeij8N
dbAcoT5y4gdii55T+edWjYNJDFihgKNEuh2KMPmMH37tYqOKCFsz1ojX2ox7e4dC
2yEACVz8G+bmUQQ/WXRKsM4pvMf616U9qkMcEYCVzqV+4smX+/z6c7gs244UVcr4
b4m6Du6UTNAtZpSkToYZvN9R2WbDmbG4FnUrF9eso7m1S2BjdlNyxJS7zGmp+Ttj
XxmPeptC/INx8EaILYlB70gDDVztU+QBeolP9lfmfpY3srhI1a2uIGH2LhhOuy+F
xcRoGaOIg3+JFyPa8ye6OAg6Vka9h+e02ZWaAAxfRhZgnnNduUnTaomuTKi8sCAa
s3AHG4E5dOTJdLGxhgVEOSl9nqIJNmVxLxxb2utcS7W5G28KHYLzgV6w2r/fOkYf
FvN5Lj6qQuQTPKdN807/7cl1fqOGPg4P74GMojVA816aNtjh4hTw/2AXqZ0Q0LTq
QzhatRaDY+cu1SSZV9aDuCxvm4chjITucb6g7/dvR1xSY4Y+oxFgt3/KO2N5jJSY
jBlJGbgGp9kukkwO2ret
=Aw0Q
-----END PGP SIGNATURE-----


From tseaver at palladion.com  Tue Jul 28 03:13:01 2015
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 27 Jul 2015 21:13:01 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
Message-ID: <mp6kv0$85l$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/27/2015 06:11 PM, Ronald Oussoren wrote:

> Treating time as UTC with conversions at the application edge might
> be "cleaner" in some sense, but can make code harder to read for 
> application domain experts.
> 
> It might be nice to have time zone aware datetime objects with the 
> right(TM) semantics, but those can and should not replace the naive 
> objects we know and love.

Interesting.  My experience is exactly the opposite:  the datetimes which
"application domain experts" cared about *always* needed to be non-naive
(zone captured explicitly or from the user's machine and converted to
UTC/GMT for storage).  As with encoded bytes, allowing a naive instance
inside the borders the system was always a time-bomb bug (stuff would
blow up at a point far removed from which it was introduced).

The instances which could have safely been naive were all
logging-related, where the zone was implied by the system's timezone
(nearly always UTC).  I guess the difference is that I'm usually writing
apps whose users can't be presumed to be in any one timezone.  Even in
those cases, having the logged datetimes be incomparable to user-facing
ones would make them less useful.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVttcdAAoJEPKpaDSJE9HYSlEP/0b7A9swT3m0uImdmzSZNJCW
EShQuxkclKlADP0Qqvshbiew1lsdqSPTZQ5QOUnqxeo+F0C1pCSABgFmXA3Jjzon
lxbwOGFFDhBburJ/F5zAO3XnawvL2p/M4dV+3Zea2inO0X+iNUuHvNjwx/e/qR4i
XdC8IyyJZtsFFL+l5KAv7xOT6SaCOB7OrVTZySHrhmfeziClzeBC8GWI00zYIQjj
BYQJB+lLhSBdb3b4u2fqhGtbrFtTHDDHEPC/mWdWAvzJN98YaeOtiTOAqiIg5Xai
TssJwAvonxOy5P8f5XdW03kbaKqmslWVk/0xIT7svjJnfPXVFzHoFJZZAJMEt34s
uZXu79g5ype8gyIJceXZV9/iS6GKHhfUlNTRvemJZb1aiq1QJ26otv2n97yqFbdo
PYfbjSU5EhK7h42138QYCM1JmKmIEIBbb+RN5O5ZaJqWEs1IstaMI1K7rM/Gt9dj
+Du0wV85Vi0ydgrZ2w8z2ZCL3bnl5wW7y8mBiSNWx1OEK7zRn/tq7/+nd9bFi1L0
8KIY8xJn5t0SU+5BSpisxTSAdX8JD6bAPy3wZlNDP8FFfB9zUyCrhRE58cDsvPdO
BQYteyWrpGQJxf2i5UQTLruW2JK3i1lL0en4spucQnBI/eHs7VVHMbfpOpdXhcIl
TR7c9fNwV0kn7EggTajx
=nRMI
-----END PGP SIGNATURE-----


From breamoreboy at yahoo.co.uk  Tue Jul 28 03:22:12 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 28 Jul 2015 02:22:12 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <55B6D3C6.80106@palladion.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com>
Message-ID: <mp6lg7$fui$1@ger.gmane.org>

On 28/07/2015 01:58, Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/27/2015 06:03 PM, Tim Peters wrote:
>
>> Even if days weren't a distinguished unit for timedelta, I'd still
>> much rather write, e.g.,
>>
>> timedelta(days=5, hours=3)
>>
>> than
>>
>> timedelta(hours=123)
>>
>> or
>>
>> timedelta(hours=5*24 + 3)
>>
>> etc.  The intent of the first spelling is obvious at a glance.
>
> - From a human's perspective, "a day from now" is always potentially
> unambigous, just like "a month from now" or "a year from now", whereas
> "24 hours from now" is never so.  In a given application, a user who
> doesn't care can always write a helper function to generate hours;  in an
> applicatino whose developer who *does* care, the 'days' argument to
> timedelta in its current does *not* help achieve her goal:  it is an
> attractive nuisance she will have to learn to avoid.
>

To me a day is precisely 24 hours, no more, no less.  I have no interest 
in messing about with daylight savings of 30 minutes, one hour, two 
hours or any other variant that I've not heard about.

In my mission critical code, which I use to predict my cashflow, I use 
code such as.

timedelta(days=14)

Is somebody now going to tell me that this isn't actually two weeks?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From tim.peters at gmail.com  Tue Jul 28 03:36:35 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 20:36:35 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp6kv0$85l$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com> <mp6kv0$85l$1@ger.gmane.org>
Message-ID: <CAExdVNkphsG78gGo5oHu4S4WDp1C+bBBejDDT8xvJso7_tOntg@mail.gmail.com>

[Ronald Oussoren]
>> Treating time as UTC with conversions at the application edge might
>> be "cleaner" in some sense, but can make code harder to read for
>> application domain experts.
>>
>> It might be nice to have time zone aware datetime objects with the
>> right(TM) semantics, but those can and should not replace the naive
>> objects we know and love.

[Tres Seaver <tseaver at palladion.com>]
> Interesting.  My experience is exactly the opposite:  the datetimes which
> "application domain experts" cared about *always* needed to be non-naive
> (zone captured explicitly or from the user's machine and converted to
> UTC/GMT for storage).  As with encoded bytes, allowing a naive instance
> inside the borders the system was always a time-bomb bug (stuff would
> blow up at a point far removed from which it was introduced).

I strongly suspect that by "naive objects" here Ronald was really
talking about "naive _arithmetic_":  the current behavior where adding
24 hours (or 1 day - exactly the same thing for a timedelta) to an
aware datetime yields a new datetime with the same tzinfo member and
the same local time components, but where the day (and possibly month,
and possibly year) components have moved forward by a day (in the
plain English meaning of "a day").

That behavior has been discussed approximately infinitely often so far
in this thread, and was the overriding context in the message from
which Ronald's quote was pulled.

> The instances which could have safely been naive were all
> logging-related, where the zone was implied by the system's timezone
> (nearly always UTC).  I guess the difference is that I'm usually writing
> apps whose users can't be presumed to be in any one timezone.  Even in
> those cases, having the logged datetimes be incomparable to user-facing
> ones would make them less useful.

I bet the same is true for Ronald in some of his apps.

So what do _you_ do with datetime arithmetic, Tres?  Do you do
datetime calculations at all, or just store/retrieve values as-is?  If
the former, are you disturbed that adding timedelta(hours=24) to an
aware datetime object never changes the time components (only the day,
and possibly also month, and possibly also year)?  If that has
disturbed you, did you find a way to accomplish what you wanted
instead - or are you still stuck? ;-)

From tim.peters at gmail.com  Tue Jul 28 04:15:41 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 21:15:41 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp6lg7$fui$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
Message-ID: <CAExdVNn41jF6GGG28PVC9Ng3RWqqEEJUU2v_1NVf34bp8_o=7A@mail.gmail.com>

[Mark Lawrence <breamoreboy at yahoo.co.uk>]
> To me a day is precisely 24 hours, no more, no less.  I have no interest in
> messing about with daylight savings of 30 minutes, one hour, two hours or
> any other variant that I've not heard about.
>
> In my mission critical code, which I use to predict my cashflow, I use code
> such as.
>
> timedelta(days=14)
>
> Is somebody now going to tell me that this isn't actually two weeks?

Precisely define what "two weeks" means, and then someone can answer.

The timedelta in question represents precisely 14 24-hours days, and
ignores the possibility that some day in there may suffer a leap
second.

If you add that timedelta to a datetime object, the result may not be
exactly 14*24 hours in the future as measured by civil time (which
includes things like DST transitions).  The result will have the same
local time on the same day of the week two weeks forward.  For
example, if you started with Monday the 6th at 3:45pm, the result will
be Monday the 20th at 3:45;pm.  Period.  The time zone (if any is
attached) is wholly ignored throughout.  If a DST transition occurs
across that period, then it's impossible to say how far removed (as
measured by. say, an independent stopwatch) Monday the 20th at 3:45pm
is from Monday the 6th at 3:45pm without also knowing the month, the
year, and the exact local time zone rules in effect across the period.

It remains unclear to me which of those outcomes _you_ consider to be
"actually 14 days".  But my bet is that you like what Python already
does here (because "tz-naive arithmetic" is exactly what _I_ want in
all my financial code).

From stephen at xemacs.org  Tue Jul 28 06:15:45 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 28 Jul 2015 13:15:45 +0900
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CACac1F_V+cdjzxPi=eS8mTOHGVdBV9fU2NUqTZ9TRNnzYMqgkw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com>
 <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com>
 <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CACac1F_V+cdjzxPi=eS8mTOHGVdBV9fU2NUqTZ9TRNnzYMqgkw@mail.gmail.com>
Message-ID: <876154ex3i.fsf@uwakimon.sk.tsukuba.ac.jp>

Paul Moore writes:

 > On 27 July 2015 at 15:57, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
 > > IMHO ?+ 1 days? and ?+ 24 hours? are two different things.  Date
 > > arithmetic is full of messy things like that.  ?+ 1 month? is another
 > > example of that (which the datetime module punts completely
 > > and can be a source of endless bikeshidding).
 > 
 > Precisely.

Er, to be exact, it's an accurate statement of imprecision (although
when talking about time and computation, both "accuracy" and
"precision" are ambiguous).  Fortunately, there's a "tim" in "time"!



From ben+python at benfinney.id.au  Tue Jul 28 06:18:41 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 28 Jul 2015 14:18:41 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
	core development process?
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
Message-ID: <858ua0ncda.fsf_-_@benfinney.id.au>

Robert Collins <robertc at robertcollins.net> writes:

> On 21 July 2015 at 00:34, Ben Finney <ben+python at benfinney.id.au> wrote:
> > Paul Moore <p.f.moore at gmail.com> writes:
> >
> >> Again, I'm sorry to pick on one sentence out of context, but it cut
> >> straight to my biggest fear when doing a commit (on any project) -
> >> what if, after all the worrying and consideration I put into doing
> >> this commit, people disagree with me (or worse still, I made a
> >> mistake)? Will I be able to justify what I decided?
> >
> > That seems quite healthy to me. On a collaborative project with
> > effects far beyond oneself, yes, any change *should* be able to be
> > justified when challenged.
>
> Depending on what you mean by justification , this leaves no leeway
> for hunches, feelings, intuition, or grey area changes.

This doesn't address what I've said; or, I've misunderstood what you've
said.

I'm well aware that *most* of the changes we actually work on and
introduce will be based on hunches, feelings, intuition, grey areas,
etc. That can't be expected to disappear.

Indeed, these non-rational ways of reaching a decision are essential to
allow us to act with any kind of speed. Non-rational decision making is
much faster, and necessarily will form the great majority of our
decision making. Good!

What I'm making explicit is: those can't serve as *justification* for
introducing a change. When a change is challenged (by someone to whom we
are answerable), claiming that it just ?felt right? is not enough.

I'm not proposing to block every change based on those non-rational
impulses. Those impulses reflect our internalised lessons that we've
learned from experience.

When someone's non-rational decisions prove reliably good *when
challenged* by rational third-party interrogation, we correctly trust
them to make more such decisions.

That's not advocating subjecting a *person* to interrogation, with the
connotations of moral judgement. Be clear: I'm talking only about
interrogating the rational justification for a code change, separate
from judgement of the person.

So: we will inevitably make most of our decisions non-rationally, which
means, among other things, *faster* than explicitly rational decision
making. I don't propose to change that, and our trusted core developers
are not expected to be any exception to this human truth.

It has to be recognised, though, that there must be some third-party
scrutiny, and if no *rational* justification can be presented for a
change ? whether tha justification is composed ahead of the change, or
some time afterward, or even at the time of the challenge ? then that
change is rather likely to be a poor one.

Again, this is *not* a call to subject every, or even most, changes to
rigorous scrutiny. That would be an intolerably slow and oppressive
environment, which I don't advocate.

What I am rejectiong is the idea, expressed several times in this
thread, that requesting rational justification for a change can be
dismissed out of hand. That's abdicating any accountability, and I was
quite concerned to see that attitute expressed.

No one need feel accountable to me especially, or any other arbitrary
member. Rather, I think it's healthy that core developers feel
accountable to the principle that any change *should* be justifiable,
when challenged by someone with sufficient authority; and that such an
authoritative request is not answered by ?it felt right to me?.

> It's also a terrible way to treat people that are contributing their
> own time and effort: assume good faith is a much better starting
> point.

Agreed, we should assume good faith. Most decisions will be reached
non-rationally, and we have no option but to trust some people to make
many non-rational decisions.

Simultaneously, when entrusted with such decisions, we must assume that
any changes we make which can't be justified *when later challenged*
should fall away.

What we mustn't assume is that just because we have made good
non-rational decisions in the past, the next one we make will also be
well-justified.

Especially, we should assume that anyone who *asks* for that rational
justification is also acting in good faith.

-- 
 \          ?The only tyrant I accept in this world is the still voice |
  `\                                      within.? ?Mohandas K. Gandhi |
_o__)                                                                  |
Ben Finney


From ben+python at benfinney.id.au  Tue Jul 28 06:24:57 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 28 Jul 2015 14:24:57 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
	core development process? (was Re: How far to go with
	user-friendliness)
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <87pp3ldjel.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <854mkonc2u.fsf@benfinney.id.au>

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> [?] The "meta" of "special cases aren't special enough to break the
> rules" is that no design decision that violates it should be dismissed
> as "minor".

Thank you. That dismissal was very upsetting; essentially telling Python
users that their concerns for a clean API in the standard library aren't
worth much to the Python core developers.

> In context of a mailing list, doing so is going to be taken by readers
> as "I know what I'm doing, and you don't know what you're talking
> about, so STFU."

That may not have been the intent. It certainly was how it was received
by some of us here.

> *Both* roles in this comedy of errors are natural, they are inherent
> in human cognition (citations on request), and nobody is to be blamed.

Since it can't seem to be said enough, I agree with what Stephen's
saying here wholeheartedly: the above explications are not intended as
blame, but an explanation of why calls to ?stop talking about this, it's
minor? had precisely the opposite effect.

-- 
 \       ?Remember: every member of your ?target audience? also owns a |
  `\   broadcasting station. These ?targets? can shoot back.? ?Michael |
_o__)               Rathbun to advertisers, news.admin.net-abuse.email |
Ben Finney


From tim.peters at gmail.com  Tue Jul 28 06:26:01 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 27 Jul 2015 23:26:01 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CALGmxEL-XHRVKt8eDDZ9FyFGkPRpSZkfG1cRwD=5tqwjjLnMRA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
 <CAExdVNniaJpSeV+8P0GvfPNJbn0KSEJ7WVScZ-89cJuHx7GATw@mail.gmail.com>
 <CALGmxEL-XHRVKt8eDDZ9FyFGkPRpSZkfG1cRwD=5tqwjjLnMRA@mail.gmail.com>
Message-ID: <CAExdVNkoSf4rnrVYyw=VEopcSstJ0OonqTROM4UmBXxXEpEN_Q@mail.gmail.com>

[Paul Moore]
>>>

[Tim]
>> Guido will never allow any aspect of "leap seconds" into the core,

[Chris Barker <chris.barker at noaa.gov]
> really? that is a shame (and odd) -- it's a trick, because we don't know
> what leap seconds will be needed in the future, but other than that, it's
> not really any different than leap years,

It couldn't be _more_ different in three key respects:

1) The leap year rules are algorithmic, while leap seconds are added
at unpredictable times by decree.  That means any attempt to support
them across dozens of platforms also needs to find a way to distribute
& synchronize leap-second info across all the platforms too, over &
over & over again.  Few want to volunteer for yet another never-ending
new task.

2) Leap years visibly effect everyone on the planet who uses a
calendar.  Leap seconds don't.  To the contrary, civil authorities do
all they can to keep leap seconds "out of sight, out of mind".

3) If adding leap seconds had any visible semantic effect in Python,
99.99% of Python users would complain about being bothered with them.
In contrast, removing leap-year support would cause 32.6% of Python
users to complain -  eventually ;-)

> ...
> But leap seconds are the big red herring -- darn few people need them!

Do you?  If not, put your energy instead into something you _do_ need
;-)  But if you do need them, write a patch and try to sneak it by
Guido.

> It's pretty rare, indeed, to be expressing your time in gregorian dates, and also
> care about accuracy down to the seconds over centuries....

Python's datetime supports microsecond precision.  Mere seconds are
for wimps ;-)

...

>>> 5. The problems all arise *only* with timezones whose UTC offset
>>> varies depending on the actual time (e.g., timezones that include the
>>> transition to DST and back).

> which is a good reason to "store" your datetime in UTC, and do all the math
> there.

As mentioned earlier, uniform patterns in local time can be -
typically because of DST transitions - "lumpy" in UTC.  Like "every
Friday at 3pm in time zone T" is trivial to deal with _in_ T using
"naive" datetime arithmetic, but the corresponding datetimes in UTC
are irregular (the number of hours between successive corresponding
UTC times can slobber around between 167 and 169)..  There are no
one-size-fits-all solutions here.

....

>> It ignores the possibility called #3 above (that some bureaucrat
>> changed the name of a fixed-offset time zone despite that the offset
>> didn't change).

> Should the code ever care about a time zone's name? it seems that two tzinfo
> objects should only be considered the same if they ar the same instance.
> period. so not sure what the real issue is with (3)

_Users_ care.  That's why the tzname() method exists.  When they
display it, it's at best confusing if the name they see doesn't match
the name they expect.

But I'm not sure _how_ the name can get out of synch.  Upon
reflection, the specific case I had in mind was actually caused by
incorrect coding of a tzinfo subclass.  Maybe that's the only way a
wrong name can be returned (apart from incorrect names in the base
zoneinfo data files).


>>> 2. Arithmetic within a complex timezone. Theoretically, this is simple
>>> enough (convert to UTC, do the calculation naively, and convert back).
>>> But in practice, that approach doesn't always match user expectations.

> what reasonable expectation does this not match?

The "every Friday at 3pm in time zone T" example comes to mind:
trying to do _that_ arithmetic in UTC is an irregular mess.

More generally, as mentioned before, the current fromutc()
implementation can't deal reliably with a time zone changing its
standard UTC offset (if it isn't clear, fromutc() is used in
astimezone(), which latter is used for time zone conversions).

Paul, do you have something else in mind for this one?


> ...
> " this time the next day" -- that could be 23, 24, or 25 hours, if you are
> bridging a DST transition -- but that kind of operation should not be in the
> stdlib -- unless, of course, an entire "work with calendar time" lib is
> added -- but that's a whole other story.
>
> for a datetime.timedelta -- a day is 24 hours is a day. period, always.

But in "naive time", the difference between 3pm one day and 3pm the
next day is also always 24 hours, period, always.

> So you can compute "one day from now", which is the same as "24 hours from
> now" or 1440 minutes from now, or ...., but you can't compute "this time
> tomorrow" -- not with a timedelta, anyway.

To the contrary, for a dozen years "+ timedelta(days=1)" HAS computed
"this time tomorrow", and exactly the same as "+ timedelta(hours=24)".
  Those have never done anything other in Python.


>> Python picked one to make dead easy
>> ("naive"), and intended to make the other _possible_ via longer-winded
>> (but conceptually straightforward) code.

> exactly -- you can extract the year, month, day -- add one to the day, and
> then go back. But then you'll need to do all the "30 days hath September"
> stuff - and leap years, and ...

It sounds like you believe Python made the choice it didn't make:  It
made the "same time tomorrow" choice.  The conceptually
straightforward way to implement the other choice is to convert to
UTC, do arithmetic in UTC, then convert back to the original time
zone.  Or, better when it applies, stick to UTC all the time, only
converting to some other time zone for display purposes (if needed at
all).

>>>  datetime gave us
>>> a richer timedelta object and hence has extra problems.

> it's only a little richer, and doesn't really add problems, just doesn't
> solve some common problems...

Indeed, all timedelta really does is represent an integer number of
microseconds, with a bunch of ways in the constructor to spare the
user from having to remember how to convert from other duration units.
That's just, in effect, syntactic sugar.  Under the covers it's just a
big integer (spelled in a weird mixed-radix system).


>> There's more to it than that.  "Naive time" also wants, e.g.,
>> "01:45:00 tomorrow minus 01:45:00 today" to return 24 hours.  Maybe
>> the same thing in disguise, though.

> I think so -- but it's not a "problem" because the datetime module doesn't
> have any way to express "tomorrow" anyway.

See above.  Expressing "tomorrow" _is_ built in.  Ditto "same time in
N weeks", "one hour beyond the same time 113 days earlier", etc.

> ... even with complex time zones. I don't
> think timedelta evey needs to know about timezones at all. timedelta, is
> actually really, really simple, all it needs to know is how to translate
> various units into its internal representation (days, seconds, microseconds
> ?)

timedelta indeed knows nothing about time zones.  People who hate
Python's "naive single-zone arithmetic" should realize that's entirely
about how datetime's arithmetic operators are implemented, nothing
about how timedelta is implemented.

From regebro at gmail.com  Tue Jul 28 07:03:59 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 07:03:59 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
Message-ID: <CAL0kPAVrkvw1js=sf2BZG-snuL29Hy-VcLiVy_szUQkinTSe-A@mail.gmail.com>

On Tue, Jul 28, 2015 at 12:03 AM, Tim Peters <tim.peters at gmail.com> wrote:
> timedelta objects only store days, seconds, and microseconds,

Except that they don't actually store days. They store 24 hour
periods, which, because of timezones changing, is not the same thing.
This is also clearly intended, for example timedelta allows floats,
and will convert the fraction into seconds. And as you have repeated
many times now, the datetime module's arithmetic is "naive" ie, it
assumes that one day is always 24 hours. The problem with that
assumption is that it isn't true.

From regebro at gmail.com  Tue Jul 28 07:08:41 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 07:08:41 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
Message-ID: <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>

On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
> I totally agree with that, having worked on applications that had to deal with time a lot and including some where the end of a day was at 4am the following day.  That app never had to deal with DST because not only are the transitions at night, the are also during the weekend.

If you don't have to deal with DST, then you don't have to have
tzinfo's in your date objects. You can have just truly naive objects
without DST information, and this will work just fine.
I think most people's expectations are that datetime's that *are* time
zone aware, should actually deal correctly with those time zones.

> It might be nice to have time zone aware datetime objects with the right(TM) semantics, but those can and should not replace the naive objects we know and love.

Yes, they most certainly should.
I will try to shut up now, but let me be clear on that the time zone
support as it stands now is intentionally broken. Not naive, *broken*.
All the usecases people have here for supporting "naive" objects would
work just as well if they actually used naive objects, ie datetimes
with no timezone info. If you explicitly do NOT want the
datetimeobject to care about timezones, then you should not add a
timezone to the object.

From regebro at gmail.com  Tue Jul 28 07:21:57 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 07:21:57 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp6lg7$fui$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
Message-ID: <CAL0kPAU7PO4ykt3=0a8h5A8msj3BQDH7Ut=2QHAVp5SsxEqS9w@mail.gmail.com>

On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> To me a day is precisely 24 hours, no more, no less.

OK.

> In my mission critical code, which I use to predict my cashflow, I use code
> such as.
>
> timedelta(days=14)
>
> Is somebody now going to tell me that this isn't actually two weeks?

Yes, I'm telling you that, now.

The two claims "One day is always precisely 24 hours" and "14 days is
two weeks" are not both true. You have to choose one.

//Lennart

From ethan at stoneleaf.us  Tue Jul 28 07:27:52 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 27 Jul 2015 22:27:52 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
 <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>
Message-ID: <55B712D8.6010309@stoneleaf.us>

On 07/27/2015 10:08 PM, Lennart Regebro wrote:
> On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren wrote:

>> It might be nice to have time zone aware datetime objects with the right(TM)
>>  semantics, but those can and should not replace the naive objects we know
>>  and love.
>
> Yes, they most certainly should.
> I will try to shut up now, but let me be clear on that the time zone
> support as it stands now is intentionally broken. Not naive, *broken*.
> All the usecases people have here for supporting "naive" objects would
> work just as well if they actually used naive objects, ie datetimes
> with no timezone info. If you explicitly do NOT want the
> datetimeobject to care about timezones, then you should not add a
> timezone to the object.

Lennart, are you saying you would leave naive objects alone, and "fix" the tz-aware objects only?

--
~Ethan~

From regebro at gmail.com  Tue Jul 28 07:47:47 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 07:47:47 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <55B712D8.6010309@stoneleaf.us>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
 <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>
 <55B712D8.6010309@stoneleaf.us>
Message-ID: <CAL0kPAVTU2_v5KYuwzgVG0OE6+pNvNPVedOPvkDxR7sSJhziDw@mail.gmail.com>

On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> Lennart, are you saying you would leave naive objects alone, and "fix" the
> tz-aware objects only?

Naive objects are not broken, so they can't be fixed. Which I guess
means "yes". :-)

//Lennart

From ethan at stoneleaf.us  Tue Jul 28 07:58:22 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 27 Jul 2015 22:58:22 -0700
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVTU2_v5KYuwzgVG0OE6+pNvNPVedOPvkDxR7sSJhziDw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
 <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>
 <55B712D8.6010309@stoneleaf.us>
 <CAL0kPAVTU2_v5KYuwzgVG0OE6+pNvNPVedOPvkDxR7sSJhziDw@mail.gmail.com>
Message-ID: <55B719FE.5010300@stoneleaf.us>

On 07/27/2015 10:47 PM, Lennart Regebro wrote:
> On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman wrote:

>> Lennart, are you saying you would leave naive objects alone, and "fix" the
>> tz-aware objects only?
>
> Naive objects are not broken, so they can't be fixed. Which I guess
> means "yes". :-)

Ah, cool!  I'm on board with that!

So the next question is how much of the current tz-aware datetime's behavior can be changed?

--
~Ethan~

From tim.peters at gmail.com  Tue Jul 28 08:11:35 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 28 Jul 2015 01:11:35 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVrkvw1js=sf2BZG-snuL29Hy-VcLiVy_szUQkinTSe-A@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <CAL0kPAVrkvw1js=sf2BZG-snuL29Hy-VcLiVy_szUQkinTSe-A@mail.gmail.com>
Message-ID: <CAExdVNmERv6wh2Yw91FGpbPHdKgLRkzR5hS0EhpyHbgPK3igLw@mail.gmail.com>

[Tim]
>> timedelta objects only store days, seconds, and microseconds,

[Lennart Regebro <regebro at gmail.com>]
> Except that they don't actually store days. They store 24 hour
> periods,

Not really.  A timedelta is truly an integer number of microseconds,
and that's all.  The internal division into days, seconds and
microseconds is a mixed-radix scheme designed to make extracting some
common units of duration more efficient than by using division on a
single long integer all the time.  That's an implementation detail,
although one that is exposed.

> which, because of timezones changing, is not the same thing.

24 hours is 24 hours at any time in _any_ time zone, ignoring leap
seconds.  timedeltas are durations, not points in time.  "time zones"
make no sense applied to durations.

> This is also clearly intended, for example timedelta allows floats,
> and will convert the fraction into seconds.

I suspect I'm missing your meaning here.  Have a specific example to
illustrate it?  For example, are you talking about things like this?

>>> timedelta(weeks=0.5)
datetime.timedelta(3, 43200)

If so, what of it?  A week is _defined_ to be 7 days in timedelta,
where a day is in turn defined to be 24 hours, where ... until you
finally get down to microseconds.  None of this has anything to do
with points in time or time zones.  It's entirely about duration.  In
the example, a week turns out to be 604800000000 microseconds.  Half
of that is 302400000000 microseconds.  Convert that into mixed-radix
days-seconds-microseconds representation, and you're left with 3 days
and 43200 seconds (with 0 microseconds left over).  I don't see
anything remarkable about any of that - perhaps you just object to the
use of the _word_ "day" in this context?  It's just a word, and
there's nothing remarkable either about viewing a duration of "a day"
as being a duration of "24 hours".  It's a timedelta - a duration.
UTC offsets of any kind have nothing to do with pure durations, they
only have to do with points in time.  Calling "a day" 24 hours _in the
context_ of a timedelta is not only unobjectionable, calling a day
anything else in this entirely zone-free context would be insane ;-)

> And as you have repeated many times now, the datetime module's
> arithmetic is "naive"

But only when staying within a single time zone.  For example, if dt1
and dt2 have different tzinfo members, dt1 - dt2 acts as if both were
converted to UTC first before doing subtraction.  "Naive time" doesn't
come into play _across_ time zones, only _within_ a time zone.  When
mixing time zones, there's no plausible justification for ignoring
either of 'em.  So they're not ignored then.

> ie, it assumes that one day is always 24 hours.

That's really not what it's doing, although the analogy is sometimes
used in explanations.  What somedatetime+timedelta really does is
simpler than that:  it adds the number of microseconds represented by
the timedelta to somedatetime, being careful with carries across the
assorted time and date components.  That's all.  There are no
assumptions about what any of it "means".  What it _doesn't_ do is
consult the tzinfo member about anything, and _that's_ the true source
of your complaints.  It so happens that, yes, naive datetime
arithmetic does always treat "a day" as 24 hours (and "a week" as 7
days, and "a minute" as 60 seconds, and so on), but not really because
it's assuming anything about what days, weeks, etc "mean".  It's
working with microseconds, and it's giving the result you'd get from
working on somedatetime.replace(tzinfo=None) instead, except it
doesn't actually remove the tzinfo member.

> The problem with that assumption is that it isn't true.

There isn't really an assumption here.  "Naive time" has no concept of
"time zone", which isn't "an assumption" so much as a _requirement_ of
the design.  You can legitimately object that this requirement is at
odds with reality in some cases.  And that's true:  it is.  But that's
also been known since the start.  It's _intentionally_ at odds with
reality in some cases, because it was believed that a simpler
approximation to reality would be most useful most often to most
applications and programmers.  And you've heard from some of them
here.

Note that the same principle is at work in other aspects of datetime's
design.  For example, the proleptic Gregorian calendar is itself a
simplified approximation to reality.  In historical terms it's a
relatively recent invention, and even now it's not used in much of the
world.  So what?  It does little harm to most applications to pretend
that, e.g., 3 March 1012 is a valid Gregorian date, but simplifies
their lives, although some obsessed calendar wonk may be outraged by
such a bold fiction ;-)

It's all a "practicality beats purity" thing, but weaker than many
such things, because in this case _sometimes_ naive arithmetic is
_not_ the most practical thing.  It has been in every dateime
application I ever wrote, but I recognize that's not the universal
experience.

From regebro at gmail.com  Tue Jul 28 08:54:58 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 08:54:58 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmERv6wh2Yw91FGpbPHdKgLRkzR5hS0EhpyHbgPK3igLw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <CAL0kPAVrkvw1js=sf2BZG-snuL29Hy-VcLiVy_szUQkinTSe-A@mail.gmail.com>
 <CAExdVNmERv6wh2Yw91FGpbPHdKgLRkzR5hS0EhpyHbgPK3igLw@mail.gmail.com>
Message-ID: <CAL0kPAU5sdd6t+QAKUbteULWfBU1sq+JdwzsHqARQRHBE+pXjw@mail.gmail.com>

On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters <tim.peters at gmail.com> wrote:
> [Tim]
>>> timedelta objects only store days, seconds, and microseconds,
>
> [Lennart Regebro <regebro at gmail.com>]
>> Except that they don't actually store days. They store 24 hour
>> periods,
>
> Not really.  A timedelta is truly an integer number of microseconds,
> and that's all.

That's what I said. Timedeltas, internally assume that 1 day is 24
hours. Or 86400000 microseconds. That's the assumption internally in
the timedelta object.

The problem with that being that in the real world that's not true.

> 24 hours is 24 hours at any time in _any_ time zone, ignoring leap
> seconds.  timedeltas are durations, not points in time.  "time zones"
> make no sense applied to durations.

My point exactly.

And should not then adding 86400000 microseconds to a datetime
actually result in a datetime that happens 86400000 microseconds
later?

>> ie, it assumes that one day is always 24 hours.
>
> That's really not what it's doing

That is really exactly what the timedelta is doing, as you yourself,
just a few lines above say.

> used in explanations.  What somedatetime+timedelta really does is
> simpler than that:  it adds the number of microseconds represented by
> the timedelta to somedatetime,

No it doesn't.

From tim.peters at gmail.com  Tue Jul 28 09:00:35 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 28 Jul 2015 02:00:35 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
 <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>
Message-ID: <CAExdVNkuNQ4N6rAvyp0HWkvQfXkxt-RriUO+yD+fFBt-CXoekA@mail.gmail.com>

[Ronald Oussoren]
>> I totally agree with that, having worked on applications
> that had to deal with time a lot and including some where the
> end of a day was at 4am the following day.  That app never
> had to deal with DST because not only are the transitions at
> night, the are also during the weekend.

[Lennart Regebro]
> If you don't have to deal with DST, then you don't have to have
> tzinfo's in your date objects.

There are no tzinfos on date objects.  I assume Ronald is talking
about datetime objects.

> You can have just truly naive objects without DST information,
> and this will work just fine.

I suspect not at all:  Ronald pretty obviously wants to mirror the
local clock, he just doesn't care about what happens in the tiny
number of cases adjacent to a DST transition buondary, because those
boundaries occur "at night ... during the weekend", times his app
predictably never needed to worry about.

> I think most people's expectations are that datetime's that *are* time
> zone aware, should actually deal correctly with those time zones.

They "almost always" do, you know ;-)  You want perfection in every
case.  Others are delighted to trade off perfection in "twice a year
wee hour on a weekend" cases for straightforward "move N units in
local time" local-time arithmetic

>> It might be nice to have time zone aware datetime objects with the right(TM) semantics, but
>> those can and should not replace the naive objects we know and love.

> Yes, they most certainly should.

They can't, at least not before Python 4.  Nobody can break over a
decade's worth of user code for something so objectively minor.  Even
in Python 4, you'd still need to get Guido's approval to reject his
design, and I doubt he'd be willing (but, of course, I may be wrong
about that).

There are other, backward-compatible, ways to get what you want
(although I don't really see a need:  it's a one-line Python function
for each kind of tz-perfection-in-all-cases arithmetic you favor).
For example, I offhandedly suggested adding a new magic attribute to
tzinfo objects; if present, datetime would compute "the other" kind of
arithmetic.  Another idea I saw last night was to create a new
timedelta-like class, then change datetime's arithmetic to act
differently when asked to use an instance of that new class in
arithmetic (although, unlike the magic tzinfo attribute, that couldn't
affect the behavior of datetime-datetime subtraction).

> I will try to shut up now, but let me be clear on that the time zone
> support as it stands now is intentionally broken. Not naive, *broken*.

It does indeed intentionally deviate from reality in some cases.

> All the usecases people have here for supporting "naive" objects would
> work just as well if they actually used naive objects, ie datetimes
> with no timezone info. If you explicitly do NOT want the
> datetimeobject to care about timezones, then you should not add a
> timezone to the object.

As at the start, I'm sure Ronald does/did care about mirroring local
time, including DST.  He just doesn't care about what happens at the
relative handful of "problem times".

Lots of apps are similar.  Someone yesterday asked for an example of
_how_ he could code a cross-timezone app to schedule remote meetings
with his students.  They need to occur at the same local time (for the
student) once per week, and he wanted a 5-minute (something like that)
warning before the meeting started in his own time zone.  I'm not sure
whether anyone answered him yet.

This is almost certainly another case where nobody cares what happens
_near_ DST transition boundaries (these are humans, so neither side
would agree to meet routinely at wee hours on a weekend).  So it's all
easy to do with Python as it exists:  "naive arithmetic" is exactly
what he needs to schedule a series of meetings at the same local times
separated by (naive) local weeks.

    first_meeting_time = datetime(Y, M, D, H, tzinfo=student_timezone)
    student_times = [first_meeting_time + timedelta(weeks=i) for i in
range(NUM_MEETINGS)]
    my_times = [student_time.astimezone(my_timezone) for student_time
in student_times]

DST transitions are vital to track on both sides, but no time in use
will appear near a transition boundary - "naive time" is a perfectly
adequate approximation, because it agrees with reality at every time
the app cares about.  And "naive datetime arithmetic" is the only kind
of arithmetic of use here.

From regebro at gmail.com  Tue Jul 28 09:11:05 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 09:11:05 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkuNQ4N6rAvyp0HWkvQfXkxt-RriUO+yD+fFBt-CXoekA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
 <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>
 <CAExdVNkuNQ4N6rAvyp0HWkvQfXkxt-RriUO+yD+fFBt-CXoekA@mail.gmail.com>
Message-ID: <CAL0kPAXrn9jSenvD7YfUmVNkzP_=t2kaocVbjRymHBZ=REu9kA@mail.gmail.com>

On Tue, Jul 28, 2015 at 9:00 AM, Tim Peters <tim.peters at gmail.com> wrote:
> [Lennart Regebro]
>> If you don't have to deal with DST, then you don't have to have
>> tzinfo's in your date objects.
>
> There are no tzinfos on date objects.  I assume Ronald is talking
> about datetime objects.

Of course, I meant datetime objects.
In everything else, I stand by my original claim. If you want naive
datetime obejcts, you should use naive datetime objects.
My opinion is and remains that intentionally breaking datetime
arithmetic to make non-naive objects behave in a naive way was a
mistake.

//Lennart

From tim.peters at gmail.com  Tue Jul 28 09:27:53 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 28 Jul 2015 02:27:53 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAU5sdd6t+QAKUbteULWfBU1sq+JdwzsHqARQRHBE+pXjw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <CAL0kPAVrkvw1js=sf2BZG-snuL29Hy-VcLiVy_szUQkinTSe-A@mail.gmail.com>
 <CAExdVNmERv6wh2Yw91FGpbPHdKgLRkzR5hS0EhpyHbgPK3igLw@mail.gmail.com>
 <CAL0kPAU5sdd6t+QAKUbteULWfBU1sq+JdwzsHqARQRHBE+pXjw@mail.gmail.com>
Message-ID: <CAExdVNncdPAJUwc_nWjOdiJxW-hjWUCKcOD7fzwJbdcNROdMEw@mail.gmail.com>

[delightful new insight elided, all summarized by what remains ;-) ]

[Tim]
>> What somedatetime+timedelta really does is simpler than that:  it
>> adds the number of microseconds represented by the timedelta to
>> somedatetime,

[Lennart]]
> No it doesn't.

Lennart, I wrote the code.  Both the Python and C datetime
implementations.  I know exactly what it does, and these repetitive
denials can't change that.  Well, maybe they can.  I really am just
assuming they can't ;-)

Here's, e.g., the Python code for datetime.__add__:

    def __add__(self, other):
        "Add a datetime and a timedelta."
        if not isinstance(other, timedelta):
            return NotImplemented
        delta = timedelta(self.toordinal(),
                          hours=self._hour,
                          minutes=self._minute,
                          seconds=self._second,
                          microseconds=self._microsecond)
        delta += other
        hour, rem = divmod(delta.seconds, 3600)
        minute, second = divmod(rem, 60)
        if 0 < delta.days <= _MAXORDINAL:
            return datetime.combine(date.fromordinal(delta.days),
                                    time(hour, minute, second,
                                         delta.microseconds,
                                         tzinfo=self._tzinfo))
        raise OverflowError("result out of range")

There's not much to it.  Apart from the year, month and date parts of
`self` (which are converted to an integer number of days), all the
rest is just adding integer microseconds expressed in two distinct
mixed-radix systems.

What part of that inspires your "No it doesn't"?  It quite obviously
does, if you understand the code.

Your real objection (whether you realize it or not) is that it's not
converting to UTC at the start and back to self._tzinfo after.

But what does it matter?  I'm done with this line.  You can get what
you want, but it has to (according to me) be done in a
backward-compatible way (and see other msgs for ideas in that
direction).

From stephen at xemacs.org  Tue Jul 28 09:44:02 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 28 Jul 2015 16:44:02 +0900
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp5t9b$eb0$1@ger.gmane.org>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B64C61.20701@mrabarnett.plus.com> <mp5t9b$eb0$1@ger.gmane.org>
Message-ID: <874mkoengd.fsf@uwakimon.sk.tsukuba.ac.jp>

Terry Reedy writes:
 > On 7/27/2015 11:21 AM, MRAB wrote:
 > 
 > > Also, if you "add one year" to 29 February 2016, what date do you get?
 > 
 > I believe the 'conventional' answer is 1 March 2017.  That is also 1 Mar 
 > 2016 + 1 year.  1 March 2017 - 1 year would be 1 Mar 2016.  Leap days 
 > get cheated.

I doubt there is a *single* "conventional" answer.  With respect to
*calendar* years, I suspect that more children born on February 29
celebrate their birthdays on February 28 than on March 1.

Another angle: I would imagine that a "real" conversation would go
something like "A: Let's meet one year from today."  "B: Today's the
29th, you know.  How about the 28th?"  If it wasn't mentioned, and one
arrived on the 28th, and another on the 1st, we'd consider that a
comedy, not one person's error of calculation according to
"conventional" rules.

I suspect that what you are calling "conventional" is actually due to
observing the cognitive bias called "substitution" (of a solvable
problem for an insoluble one).  That is, the problem of "computing the
date 1 timedelta year later" is substituted for the problem of
"computing the calendar date 1 year later".

But that's inappropriate, because these are two different use cases.
Calendar time is for coordination, such as birthday parties, and
timedelta time is for process control, such as venting nuclear
reactors.  Of course timedelta can be considered as a calendar by
assigning a place and an epoch, and it's convenient to assign one more
or less consistent with the "consensus calendar" in some "reasonable"
place.  Eg, UTC as a calendar is approximately the calendar in London.
But this is fundamentally arbitrary.  Consider the events that define
"Easter Sunday".

In this framework, I suppose one could characterize datetimes as
allowing "simple calculations with time intervals suitable for people
who don't hold meetings at 1:30am and who don't have birthdays or
wedding anniversaries on Feb 29, and are not separated from important
events by astronomical distances, nor likely to move at speeds greater
than 0.01% of the speed of light before the event happens".  Ie,
almost all of us almost all of the time.

I'm completely satisfied by Tim's answers and think "almost all" is
good enough for the stdlib for now.  If a separate module that
actually succeeds in eliminating the discrepancies between datetime
and calendar time as required by "coordinating process control time"
with human requirements for "simultaneous presence at meetings", I'd
be for including that calendar module in the stdlib, and deprecating
datetime.  But *elimination* is a high bar, and I think the stdlib
would have to be backward-compatible if it fails that criterion
(probably by including both modules).


From tim.peters at gmail.com  Tue Jul 28 09:56:29 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 28 Jul 2015 02:56:29 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAXrn9jSenvD7YfUmVNkzP_=t2kaocVbjRymHBZ=REu9kA@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <7620b290d7acb.5527f9af@wiscmail.wisc.edu>
 <7530a93fd12e8.5527f9eb@wiscmail.wisc.edu>
 <74409ce3d674f.5527fa27@wiscmail.wisc.edu>
 <74f0db36d7d6e.5527fa64@wiscmail.wisc.edu>
 <74e0b8a4d65a3.5527faa0@wiscmail.wisc.edu>
 <74d0872fd5f5c.5527fadc@wiscmail.wisc.edu>
 <74d0c93cd5dfa.5527fb19@wiscmail.wisc.edu>
 <7440a9edd18fd.5527fb91@wiscmail.wisc.edu>
 <7620e95ed61ae.5527fbce@wiscmail.wisc.edu>
 <7470e6d9d3a54.5527fc0a@wiscmail.wisc.edu>
 <74f0ef60d15b6.5527fc46@wiscmail.wisc.edu>
 <77909799d6c93.5527fc83@wiscmail.wisc.edu>
 <74d0f69bd796c.5527fcbf@wiscmail.wisc.edu>
 <75308783d3c84.5527fcfb@wiscmail.wisc.edu>
 <7530ba90d0977.5527fd74@wiscmail.wisc.edu>
 <7790a931d1c08.5527b74a@wiscmail.wisc.edu>
 <87bnipp2cc.fsf@gmail.com> <7100c8e6119092.552ecb25@wiscmail.wisc.edu>
 <74b09ad111d439.552ecb61@wiscmail.wisc.edu>
 <74b0db7f11dbfe.552e8531@wiscmail.wisc.edu>
 <87vbgxnia3.fsf@gmail.com> <7740b12311d16c.552ee6bc@wiscmail.wisc.edu>
 <7450994e11f719.552ee6f9@wiscmail.wisc.edu>
 <7150bb6211f4ae.552ee735@wiscmail.wisc.edu>
 <7460ca7211e63f.552ee771@wiscmail.wisc.edu>
 <76b0faaa11ddf7.552ee7e9@wiscmail.wisc.edu>
 <7150dae811ea69.552ea1b2@wiscmail.wisc.edu>
 <CAP7+vJKCL6XYVaHcjKDW59NbTGJO+7-vNqdO8wFLvb3kbySF8Q@mail.gmail.com>
 <CAL0kPAUs+XORH3AM7+XVcac=NXE7ekR7khuuGk+nuaQxSk+TuQ@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com>
 <CAL0kPAUx648CP8NRawr=bUczifH-DqfHkZF=+E+auO+F6w0SfA@mail.gmail.com>
 <CAExdVNkuNQ4N6rAvyp0HWkvQfXkxt-RriUO+yD+fFBt-CXoekA@mail.gmail.com>
 <CAL0kPAXrn9jSenvD7YfUmVNkzP_=t2kaocVbjRymHBZ=REu9kA@mail.gmail.com>
Message-ID: <CAExdVNkaCyUO79gDs9=8Yi-M2pcNOSLa1XgyqzYTt-rW7KVNoQ@mail.gmail.com>

[Lennart Regebro <regebro at gmail.com>]
> Of course, I meant datetime objects.
> In everything else, I stand by my original claim. If you want naive
> datetime obejcts, you should use naive datetime objects.

That's tautological ("if you want X, you should use X").  I'm not sure
what you intended to say.  But it's a fact that some apps do need
DST-aware datetime objects, and also need naive datetime arithmetic on
those objects.  The point isn't that there's no way to get the latter
if Python datetime arithmetic changed; the point is that it _already
works_ for them, and has for 12 years.  You can't break apps without
overwhelmingly compelling reason(s).  Please move on to think about
backward-compatible ways to get what you want instead.

In the meantime, writing little functions to do the
convert/arithmetic/convert dance is "the obvious" way to get what you
want.

> My opinion is and remains that intentionally breaking datetime
> arithmetic to make non-naive objects behave in a naive way was a
> mistake.

While other people think it was a fine and useful compromise.  It's
certainly fortunate that repetition changes minds ;-)  Regardless,
that decision is ancient history now.

From p.f.moore at gmail.com  Tue Jul 28 10:04:09 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 28 Jul 2015 09:04:09 +0100
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <858ua0ncda.fsf_-_@benfinney.id.au>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
Message-ID: <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>

On 28 July 2015 at 05:18, Ben Finney <ben+python at benfinney.id.au> wrote:
>
> Indeed, these non-rational ways of reaching a decision are essential to
> allow us to act with any kind of speed. Non-rational decision making is
> much faster, and necessarily will form the great majority of our
> decision making. Good!
>
> What I'm making explicit is: those can't serve as *justification* for
> introducing a change. When a change is challenged (by someone to whom we
> are answerable), claiming that it just ?felt right? is not enough.

But isn't the whole *point* of a non-rational decision (as you
describe it) that you *can't* articulate your reasons for making that
decision.

You can't have your cake and eat it - are core devs allowed to make
"non-rational" judgements or not? (In your view - in mine, they
clearly are, and being required to justify those decisions after the
fact is *not* acceptable).

Paul

From lrekucki at gmail.com  Tue Jul 28 10:25:28 2015
From: lrekucki at gmail.com (=?UTF-8?Q?=C5=81ukasz_Rekucki?=)
Date: Tue, 28 Jul 2015 10:25:28 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <874mkoengd.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B64C61.20701@mrabarnett.plus.com> <mp5t9b$eb0$1@ger.gmane.org>
 <874mkoengd.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAEZs-E+t_Bdkejq_1NzAYfSvaJWHnH-VUAhbB06aiN_Ey-UZ7w@mail.gmail.com>

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

From stephen at xemacs.org  Tue Jul 28 10:36:44 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 28 Jul 2015 17:36:44 +0900
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <55B6D3C6.80106@palladion.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com>
Message-ID: <873808el0j.fsf@uwakimon.sk.tsukuba.ac.jp>

Tres Seaver writes:

 > - From a human's perspective, "a day from now" is always potentially
 > unambigous, just like "a month from now" or "a year from now", whereas
 > "24 hours from now" is never so.

I gather you've never been a prof who told a student with aggravated
"writer's block" she had 24 hours to produce a draft, and have her
walk in 45 minutes early, apologizing profusely for being 15 minutes
late!

Humans always have a use case in mind.  In *my* mind, I *meant* 24
hours or 84600 seconds (estimating process allocations of 2 hours
inadvertant sleeping, 3 hours writing, and 19 hours fussing and/or
panicking ;-), while the *student* *interpreted* it as "be here with a
stack of paper at the same time tomorrow".

You can say "that's just wordplay" (or more precisely, "that's a
communication problem").  AFAICS, one way to view Tim's point (or
Guido's point in the original decision) is that it's *always* a
communication problem, and that Python should refuse to guess.  Since
communicating sufficiently accurate information about the mapping from
any local time to time in any civil system is always difficult (and
impossible in the case of civil times one legislative session or more
in the future), Python chose naive time arithmetic and naive time
classes to represent it (FVO "naive" equivalent to "what Tim said").

In other words, datetime and timedelta implement the only calculations
it was feasible to "just get it right" at the time (and I would say
that because of the communication problem the alternative use case is
*still* an application problem, not a library problem).

Steve

From regebro at gmail.com  Tue Jul 28 11:04:10 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 11:04:10 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAEZs-E+t_Bdkejq_1NzAYfSvaJWHnH-VUAhbB06aiN_Ey-UZ7w@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B64C61.20701@mrabarnett.plus.com> <mp5t9b$eb0$1@ger.gmane.org>
 <874mkoengd.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAEZs-E+t_Bdkejq_1NzAYfSvaJWHnH-VUAhbB06aiN_Ey-UZ7w@mail.gmail.com>
Message-ID: <CAL0kPAWQangAcKBP2+kOPK_LdZpQZLtFfMc3WxHuZbqfUW2bPg@mail.gmail.com>

On Tue, Jul 28, 2015 at 10:25 AM, ?ukasz Rekucki <lrekucki at gmail.com> wrote:
> 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?

Well, the separation is pretty clear already. Tim wants to have naive
timezone aware objects, ie datetime objects that have a time zone but
ignores the time zone, except when converting to other time zones. I
have yet to see a use case for that.

//Lennart

From guido at python.org  Tue Jul 28 11:10:05 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 28 Jul 2015 11:10:05 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <873808el0j.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAP7h-xab7a6VWBx0uweLMEprUMtHCevdpTXPcdCEpg6urfYpgw@mail.gmail.com>
 <SN1PR06MB18245D340C3529723E0A2ABFB6810@SN1PR06MB1824.namprd06.prod.outlook.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <873808el0j.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAP7+vJLGHCqnfcoQzXrTewZCF26CvqdX-9VLgvg7p4oiFyOB=w@mail.gmail.com>

I was going to jump in and explain the rationale for the original design
and why we shouldn't change it, but I just realized that Tim Peters has
been explaining this position already, and instead I am going to mute this
thread. Please switch to python-ideas or to the new datetime-specific list
(if it's ever created -- personally I think it's a waste) and change the
subject if you need me to chime in.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150728/d177a85d/attachment.html>

From jon+python-dev at unequivocal.co.uk  Tue Jul 28 11:35:20 2015
From: jon+python-dev at unequivocal.co.uk (Jon Ribbens)
Date: Tue, 28 Jul 2015 10:35:20 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CALGmxEK8DRq_XbEzKN3GnFibKZC2rCEXYkgU5Hv68ap4+ty2zw@mail.gmail.com>
References: <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <20150727101553.GO28550@unequivocal.co.uk>
 <CAExdVNkqgfOkPmHnzZeiXac3jDbU8XNzj7fmbtkGQ9xLcbg4rQ@mail.gmail.com>
 <CALGmxEK8DRq_XbEzKN3GnFibKZC2rCEXYkgU5Hv68ap4+ty2zw@mail.gmail.com>
Message-ID: <20150728093520.GQ28550@unequivocal.co.uk>

On Mon, Jul 27, 2015 at 04:28:48PM -0700, Chris Barker wrote:
>      > The only other thing I found
>      > really weird about datetime is how Python 2 had no implementation of
>      > a UTC tzinfo class, despite this being utterly trivial -
> 
>    Huh? it is either so trivial that there is no point -- simiply say that
>    your datetimes are UTC, and you are done.
>    Or it's not the least bit trivial -- the only difference between a UTC
>    datetime and a "naive" datetime is that one can be converted to (or
>    interact with) other time zones. Except that, as we know from this
>    conversation, is very, very non-trivial!

No, it has nothing to do with conversions. The difference between a
naive timezone and a UTC one is that the UTC one explicitly specifies
that it's UTC and not "local time" or some other assumed or unknown
timezone. This can make a big difference when passing datetime
objects to third-party libraries, such as database interfaces.

From breamoreboy at yahoo.co.uk  Tue Jul 28 13:55:38 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 28 Jul 2015 12:55:38 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNn41jF6GGG28PVC9Ng3RWqqEEJUU2v_1NVf34bp8_o=7A@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAExdVNn41jF6GGG28PVC9Ng3RWqqEEJUU2v_1NVf34bp8_o=7A@mail.gmail.com>
Message-ID: <mp7qju$6jg$1@ger.gmane.org>

On 28/07/2015 03:15, Tim Peters wrote:
> [Mark Lawrence <breamoreboy at yahoo.co.uk>]
>> To me a day is precisely 24 hours, no more, no less.  I have no interest in
>> messing about with daylight savings of 30 minutes, one hour, two hours or
>> any other variant that I've not heard about.
>>
>> In my mission critical code, which I use to predict my cashflow, I use code
>> such as.
>>
>> timedelta(days=14)
>>
>> Is somebody now going to tell me that this isn't actually two weeks?
>
> Precisely define what "two weeks" means, and then someone can answer.

One week == 7 days == 7 * 24 hours
Two weeks = 2 * (one week)

>
> The timedelta in question represents precisely 14 24-hours days, and
> ignores the possibility that some day in there may suffer a leap
> second.

As I've said elsewhere I've no interest in DST, at least right here, 
right now, let alone leap seconds. When I run my cashflow forecast the 
balance in my bank account one year from today isn't going to be 
influenced by UK clocks falling back to GMT at the end of October and on 
to BST at the end of next March.

>
> It remains unclear to me which of those outcomes _you_ consider to be
> "actually 14 days".  But my bet is that you like what Python already
> does here (because "tz-naive arithmetic" is exactly what _I_ want in
> all my financial code).
>

Correct.  What I would like to know is how many people are in my 
position, how many people are in the situation of needing every possible 
combination of dates, times, daylight saving, local time zone rules and 
anything else you can think of under the sun, and how many are on the 
scale somewhere in between these two extremes.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From tseaver at palladion.com  Tue Jul 28 14:06:03 2015
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 28 Jul 2015 08:06:03 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkphsG78gGo5oHu4S4WDp1C+bBBejDDT8xvJso7_tOntg@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com> <mp6kv0$85l$1@ger.gmane.org>
 <CAExdVNkphsG78gGo5oHu4S4WDp1C+bBBejDDT8xvJso7_tOntg@mail.gmail.com>
Message-ID: <55B7702B.5000300@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/27/2015 09:36 PM, Tim Peters wrote:
> So what do _you_ do with datetime arithmetic, Tres?  Do you do 
> datetime calculations at all, or just store/retrieve values as-is?
> If the former, are you disturbed that adding timedelta(hours=24) to
> an aware datetime object never changes the time components (only the
> day, and possibly also month, and possibly also year)?  If that has 
> disturbed you, did you find a way to accomplish what you wanted 
> instead - or are you still stuck? ;-)

Sample use cases:

- - Embargo a pre-prepared story until 8:00 AM US/Central next Monday.

- - Likewise, but allow it to run for three weeks.

- - Create a recurring event which occurs from 7:00 - 9:00 PM US/Eastern on
  the last Thursday of each month.

- - Issue a bid for a commodity lot N days before its expiration date;
  update that bid (if another bid has occurred) at the same time each
  day until expiration.

- - Mark messages published on a distributed event channel to allow clients
  to sequence them unambiguously.

- - For a given sequence of events:  if no subsequent matching event occurs
  within five calendar days of the last event in the sequence, issue a
  "resolved" event, terminating the sequence.

- - The same, except define the interval using "business days" (including
  applying a user-defined holiday calendar).

- - Measure / bucket widgets produced across multiple production lines by
  quarter / month / day / shift / hour, and generate reports comparing
  results week-over-week, quarter-over-quarter, etc.

In none of those cases involving "days" was the "one day is 24 hours,
exactly" a sufficient approximation, and none of them could tolerate naive
datetimes.  Typically, the application used a "date interval" object (or a
recurrence object) which generated date offsets without assuming that a
"day" was 86400 seconds.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVt3ArAAoJEPKpaDSJE9HYfCcP/07RNZY6Vp5wfcR8wnv3Zk/Z
3SgaEWPIG7s8ysqUhcxT/E6pMdgrLDwSm681Ceh8SDFKdvmXIgSO4UXdsHz6X9Ja
gffUk1p5m/A1p0GFdcIMN9EHI1Ligtrf/s0gYJ+b0TqiDUW9mpD1xOmQaNK2/eE4
xf3iYSdFgvcqNMlIzQ+AyzP53M9npv78zCqr/LI18mRczMOHENb98jXeWycIMHyV
TbHL/cZ///Uj1IqAmydezj4K0biPwUeMsNeqzzuMbDsiVFdZn+rql9N+V4BuzINZ
ivmvdEIFdBqFoRcJJyoWsuqaR8GX0i/2LTVgj4Xcustj1Wnh2Aq+2yUNi0DQvjxh
Y79QbVPtPyjkzFUh/dZG5hLSAEWxXtbaFsinq1eN+hraBXHAN4sTdUeL1zGV7Pz5
SSQXwe2cabqALzjbpSiLN8gZ3s7DbcVn4uDLsS3L7iyoC5Y51puZut6ui+TmdbgK
fG2zvkRNayOyiRa1vymNZsjiM9XYrNABVhuVdM+xgqCe62q+bcUKKVKRIZY1JWq4
Fh0hy9MVPeT51oFuaIAPQJfPKleSLf8xElHZ9M0Gm4PbJDvmr04AjZ7MHWicXsqR
pbhlbfIDO8c2Pt7JfjLPGY/0UZi0ZVeJV8bD5EaM3xcn80DLKW9UL+8Yg4h9br59
RURP7/N6S66jAEHfcUFo
=3LBp
-----END PGP SIGNATURE-----


From breamoreboy at yahoo.co.uk  Tue Jul 28 14:06:50 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 28 Jul 2015 13:06:50 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAU7PO4ykt3=0a8h5A8msj3BQDH7Ut=2QHAVp5SsxEqS9w@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAL0kPAU7PO4ykt3=0a8h5A8msj3BQDH7Ut=2QHAVp5SsxEqS9w@mail.gmail.com>
Message-ID: <mp7r8u$f6e$1@ger.gmane.org>

On 28/07/2015 06:21, Lennart Regebro wrote:
> On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>> To me a day is precisely 24 hours, no more, no less.
>
> OK.
>
>> In my mission critical code, which I use to predict my cashflow, I use code
>> such as.
>>
>> timedelta(days=14)
>>
>> Is somebody now going to tell me that this isn't actually two weeks?
>
> Yes, I'm telling you that, now.
>
> The two claims "One day is always precisely 24 hours" and "14 days is
> two weeks" are not both true. You have to choose one.
>
> //Lennart
>

You can tell me, but as far as I'm concerned in my application both are 
true, so I don't have to choose one.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From breamoreboy at yahoo.co.uk  Tue Jul 28 14:12:19 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 28 Jul 2015 13:12:19 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAU5sdd6t+QAKUbteULWfBU1sq+JdwzsHqARQRHBE+pXjw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <CAL0kPAVrkvw1js=sf2BZG-snuL29Hy-VcLiVy_szUQkinTSe-A@mail.gmail.com>
 <CAExdVNmERv6wh2Yw91FGpbPHdKgLRkzR5hS0EhpyHbgPK3igLw@mail.gmail.com>
 <CAL0kPAU5sdd6t+QAKUbteULWfBU1sq+JdwzsHqARQRHBE+pXjw@mail.gmail.com>
Message-ID: <mp7rj7$n2p$1@ger.gmane.org>

On 28/07/2015 07:54, Lennart Regebro wrote:
> On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters <tim.peters at gmail.com> wrote:
>> [Tim]
>>>> timedelta objects only store days, seconds, and microseconds,
>>
>> [Lennart Regebro <regebro at gmail.com>]
>>> Except that they don't actually store days. They store 24 hour
>>> periods,
>>
>> Not really.  A timedelta is truly an integer number of microseconds,
>> and that's all.
>
> That's what I said. Timedeltas, internally assume that 1 day is 24
> hours. Or 86400000 microseconds. That's the assumption internally in
> the timedelta object.
>
> The problem with that being that in the real world that's not true.
>

In my real world it is.  We clearly have parallel worlds.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From breamoreboy at yahoo.co.uk  Tue Jul 28 14:23:09 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 28 Jul 2015 13:23:09 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNkoSf4rnrVYyw=VEopcSstJ0OonqTROM4UmBXxXEpEN_Q@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <20150727140000.75AA7B14150@webabinitio.net>
 <CACac1F9FLBj6n_u2rNSTPoN32Yhj-GVNJBgLmq9V1Cw=p2VA0g@mail.gmail.com>
 <CAExdVNniaJpSeV+8P0GvfPNJbn0KSEJ7WVScZ-89cJuHx7GATw@mail.gmail.com>
 <CALGmxEL-XHRVKt8eDDZ9FyFGkPRpSZkfG1cRwD=5tqwjjLnMRA@mail.gmail.com>
 <CAExdVNkoSf4rnrVYyw=VEopcSstJ0OonqTROM4UmBXxXEpEN_Q@mail.gmail.com>
Message-ID: <mp7s7h$2cs$1@ger.gmane.org>

On 28/07/2015 05:26, Tim Peters wrote:

>
> Python's datetime supports microsecond precision.  Mere seconds are
> for wimps ;-)
>

Microseconds are for wimps https://bugs.python.org/issue22117 :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From regebro at gmail.com  Tue Jul 28 14:35:22 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 14:35:22 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp7qju$6jg$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAExdVNn41jF6GGG28PVC9Ng3RWqqEEJUU2v_1NVf34bp8_o=7A@mail.gmail.com>
 <mp7qju$6jg$1@ger.gmane.org>
Message-ID: <CAL0kPAVUcgEaAVKCUoyBy-kga50rqh3ovw0uM9sxucwe1SP_Zw@mail.gmail.com>

On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> One week == 7 days == 7 * 24 hours
> Two weeks = 2 * (one week)

Right, and that of course is not true in actual reality. I know you
are not interested in DST, but with a timezone that has DST, two times
a year, the above statement is wrong.

> As I've said elsewhere I've no interest in DST, at least right here, right
> now, let alone leap seconds. When I run my cashflow forecast the balance in
> my bank account one year from today isn't going to be influenced by UK
> clocks falling back to GMT at the end of October and on to BST at the end of
> next March.

And then you should not use timezoned datetimes, but use naive ones.
If you don't care about the timezone, then don't use it. Problem solved.

It should be noted here that Python is one of the few languages that
actually lets you do that. It's not very common to support time zone
naive datetimes.

> Correct.  What I would like to know is how many people are in my position,
> how many people are in the situation of needing every possible combination
> of dates, times, daylight saving, local time zone rules and anything else
> you can think of under the sun, and how many are on the scale somewhere in
> between these two extremes.

There are a few positions.

1. Not caring. datetime supports that as of today. This is probably
the most common case. That certainly is the case for me most of the
time I need to do something with datetimes. It's usually measuring a
few seconds of time or calculating dates.

2. Caring about time zones including DST's. IMO, this is the most
common case once you care about time zones. You have several time
zones, and you want conversion between them to work, and if you say
one hour, you mean one hour. Datetime as of today does not support
this, and Tim has declared that it never will, at least not before
Python 4 (which amounts to much the same thing).

3. The position of Tim and Guido, which is "I want my time zone aware
datetimes to ignore the time zone, except when converting to other
time zones". I have yet to see a use case for that, and hence I am
still not convinced that this position is useful, I think it is only
based on misunderstanding.

4. ? Are there more positions, something I have missed?

//Lennart

From ben+python at benfinney.id.au  Tue Jul 28 14:35:55 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 28 Jul 2015 22:35:55 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
	core development process?
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
 <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>
Message-ID: <85zj2glas4.fsf@benfinney.id.au>

Paul Moore <p.f.moore at gmail.com> writes:

> But isn't the whole *point* of a non-rational decision (as you
> describe it) that you *can't* articulate your reasons for making that
> decision.

You've conflated the process used to make a decision, with the
justifications that support that decision.

Those are separate. When I decide to avoid travelling a particular route
to work one day, my decision could very likely be made non-rationally.

Yet when challenged to say why it's a good choice, the non-rational
processes I used to make the decision would rightly be dismissed. I can
either present rationally compelling justification for choosing the
route I used, or the challenger can rightly dismiss my choice as
insufficiently justified.

> You can't have your cake and eat it - are core devs allowed to make
> "non-rational" judgements or not?

All humans, core developers included, can and must continue to make most
of our decisions in a non-rational manner. That's not the issue.

> (In your view - in mine, they clearly are, and being required to
> justify those decisions after the fact is *not* acceptable).

I'm unsure what the objection is. The challenge is not to the person to
justify themselves; it is to the change made, and what justification
there is for it. This distinction is subtle but crucial.

What do you imagine is the alternative? That changes which lack rational
support should be allowed merely because of the person who made them?

People can, do, and probably must make many decisions through
non-rational processes. I don't propose to change that.

Choices can be made that, when challenged, lack compelling rational
justification. I do propose that such a challenge should be taken as a
healthy desire to improve Python, not a personal attack.

Challenging ideas can be misunderstood as challenging a person's
character. That's a mistaken conflation, and I try hard to avoid it; I'd
love for all of us to do the same.

-- 
 \       ?If you don't know what your program is supposed to do, you'd |
  `\                 better not start writing it.? ?Edsger W. Dijkstra |
_o__)                                                                  |
Ben Finney


From regebro at gmail.com  Tue Jul 28 14:47:58 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 14:47:58 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp7qju$6jg$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAExdVNn41jF6GGG28PVC9Ng3RWqqEEJUU2v_1NVf34bp8_o=7A@mail.gmail.com>
 <mp7qju$6jg$1@ger.gmane.org>
Message-ID: <CAL0kPAVc_vTWFHxrmHwuSvLmVkNti0_GoiVkjiWatt=K77iK7A@mail.gmail.com>

On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> Correct.  What I would like to know is how many people are in my position,
> how many people are in the situation of needing every possible combination
> of dates, times, daylight saving, local time zone rules and anything else
> you can think of under the sun, and how many are on the scale somewhere in
> between these two extremes.

I should also point out that this is not about supporting "everything
under the sun" in any form at all. It's about whether the arithmetic
on a *time zone aware* date time should use that time zone
information, or if the time zone aware datetime should ignore the
attached time zone.

//Lennart

From p.f.moore at gmail.com  Tue Jul 28 14:57:28 2015
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 28 Jul 2015 13:57:28 +0100
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <85zj2glas4.fsf@benfinney.id.au>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
 <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>
 <85zj2glas4.fsf@benfinney.id.au>
Message-ID: <CACac1F_iEvt_pmpGsCtm-g6Su1cCybzir6kVpQPYBPBc7_KzDQ@mail.gmail.com>

On 28 July 2015 at 13:35, Ben Finney <ben+python at benfinney.id.au> wrote:
> People can, do, and probably must make many decisions through
> non-rational processes. I don't propose to change that.

Good.

> Choices can be made that, when challenged, lack compelling rational
> justification. I do propose that such a challenge should be taken as a
> healthy desire to improve Python, not a personal attack.

While that is fine, you appear unwilling to accept the possibility
that people may not have the time/energy to develop a detailed
rational justification for a change that they have made, and demanding
that they do so when they are offering the time they do give on a
volunteer basis, is what I claim is unacceptable.

> Those are separate. When I decide to avoid travelling a particular route
> to work one day, my decision could very likely be made non-rationally.

Would you be happy if someone insisted, when you arrive at work, that
you rigorously justify your choice, down to the smallest detail? "Why
didn't you avoid road A, as there's a bridge over that road and when
you go that way you risk the bridge collapsing and killing you?
There's no way it makes sense to take such a significant risk when by
going down road B you could avoid it, for no more than 10 minutes'
delay".

As a further point, even if your challenge is from a desire to ensure
the best possible outcome for Python, you may not know the subject
area as well as the core dev involved (that's pretty much by
definition for these mailing list debates). In order to explain the
decision, the core dev may need to give you a lot of information that
they already know, from experience. Your demand for explanation has
now turned into a demand for free education. Is that still acceptable?
Must Steve Dower or I explain all of the relevant intricacies of
Windows to you just so that you can understand our explanation of why
we made a particular Windows-related change?

The issue is not one of your motives in asking for explanations - it's
the implication that you are entitled to require others to *provide*
those explanations, to whatever level of detail *you* require.

I hope that clarifies my position. In the spirit of what I've said
above, I hope you won't take it the wrong way if I point out that this
discussion has become a drain on my limited personal time, and I am no
longer finding it of interest. As a result, I'm not going to follow up
further. If what I've said doesn't justify my position sufficiently,
we'll simply have to agree to differ.

Paul

From breamoreboy at yahoo.co.uk  Tue Jul 28 15:17:41 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 28 Jul 2015 14:17:41 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAVUcgEaAVKCUoyBy-kga50rqh3ovw0uM9sxucwe1SP_Zw@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAExdVNn41jF6GGG28PVC9Ng3RWqqEEJUU2v_1NVf34bp8_o=7A@mail.gmail.com>
 <mp7qju$6jg$1@ger.gmane.org>
 <CAL0kPAVUcgEaAVKCUoyBy-kga50rqh3ovw0uM9sxucwe1SP_Zw@mail.gmail.com>
Message-ID: <mp7vdp$oqg$1@ger.gmane.org>

On 28/07/2015 13:35, Lennart Regebro wrote:
> On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>> One week == 7 days == 7 * 24 hours
>> Two weeks = 2 * (one week)
>
> Right, and that of course is not true in actual reality. I know you
> are not interested in DST, but with a timezone that has DST, two times
> a year, the above statement is wrong.
>

Tim asked for my definition of two weeks so I've given it.  With respect 
to that in reality this is true, for me, with my application, making my 
statement above correct.  For my application we could go from GMT to BST 
and back on successive days throughout the year and it wouldn't make any 
difference.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From ben+python at benfinney.id.au  Tue Jul 28 16:17:38 2015
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 29 Jul 2015 00:17:38 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
	core development process?
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
 <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>
 <85zj2glas4.fsf@benfinney.id.au>
 <CACac1F_iEvt_pmpGsCtm-g6Su1cCybzir6kVpQPYBPBc7_KzDQ@mail.gmail.com>
Message-ID: <85vbd4l62l.fsf@benfinney.id.au>

Paul Moore <p.f.moore at gmail.com> writes:

> On 28 July 2015 at 13:35, Ben Finney <ben+python at benfinney.id.au> wrote:
> > People can, do, and probably must make many decisions through
> > non-rational processes. I don't propose to change that.
>
> Good.
>
> > Choices can be made that, when challenged, lack compelling rational
> > justification. I do propose that such a challenge should be taken as a
> > healthy desire to improve Python, not a personal attack.
>
> While that is fine, you appear unwilling to accept the possibility
> that people may not have the time/energy to develop a detailed
> rational justification for a change that they have made, and demanding
> that they do so when they are offering the time they do give on a
> volunteer basis, is what I claim is unacceptable.

I've said many times now that's not what I'm advocating.

I've made a clear distinction between the need to *be able to* justify a
change, versus arbitrary demands to do so by arbitrary members.

The latter is what you're arguing against, and of course I agree. I've
never advocated that.

> The issue is not one of your motives in asking for explanations - it's
> the implication that you are entitled to require others to *provide*
> those explanations, to whatever level of detail *you* require.

Hopefully this repetition is enough: I do not claim any such entitlement.

> I hope that clarifies my position.

Likewise. Thanks for engaging.

-- 
 \               ?? correct code is great, code that crashes could use |
  `\           improvement, but incorrect code that doesn?t crash is a |
_o__)                    horrible nightmare.? ?Chris Smith, 2008-08-22 |
Ben Finney


From regebro at gmail.com  Tue Jul 28 17:31:17 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2015 17:31:17 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp7vdp$oqg$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAExdVNn41jF6GGG28PVC9Ng3RWqqEEJUU2v_1NVf34bp8_o=7A@mail.gmail.com>
 <mp7qju$6jg$1@ger.gmane.org>
 <CAL0kPAVUcgEaAVKCUoyBy-kga50rqh3ovw0uM9sxucwe1SP_Zw@mail.gmail.com>
 <mp7vdp$oqg$1@ger.gmane.org>
Message-ID: <CAL0kPAU-p6HZ1f0hahiPnGircQ9vMixyOOZizEJZbWs7ac7gZA@mail.gmail.com>

On Tue, Jul 28, 2015 at 3:17 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> Tim asked for my definition of two weeks so I've given it.  With respect to
> that in reality this is true, for me, with my application, making my
> statement above correct.  For my application we could go from GMT to BST and
> back on successive days throughout the year and it wouldn't make any
> difference.

Right. You want a timezone naive datetime. Your usecase is covered, no problemo.

//Lennart

From keeely3 at gmail.com  Tue Jul 28 17:46:44 2015
From: keeely3 at gmail.com (Mark Kelley)
Date: Tue, 28 Jul 2015 16:46:44 +0100
Subject: [Python-Dev] Building python 2.7.10 for Windows from source
In-Reply-To: <mp5v6a$e4e$1@ger.gmane.org>
References: <CAGZwN724kDq5KVaRFhiE2HUZbmqPz2b8oYrc24C2wVrjAKHFSg@mail.gmail.com>
 <CAKJDb-PAHFRXqTsV-KpJrYLThjmmyQwEGz4jPdRXQispOKAcWQ@mail.gmail.com>
 <CAGZwN721G-jQe2aBXX7vVcPADcDDdJuksueL_t0LZuRg5C+1eA@mail.gmail.com>
 <mp5v6a$e4e$1@ger.gmane.org>
Message-ID: <CAGZwN71dCDW15Mrks8bFGLoZ3WeM48Jrp-=b17Bz9XjW_qWcbA@mail.gmail.com>

I got my MSI built, after numerous modifications to the various build
scripts. the installed file set bears little resemblance to the
official release for the same version, which is a bit of a fail for
the Open-source principle, but it seems nobody cares, so I'll split.

From rosuav at gmail.com  Tue Jul 28 17:47:47 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 29 Jul 2015 01:47:47 +1000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp7r8u$f6e$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAExdVNkgtY+0AD1uWCLtm_eAgL0TWx1H9BhZPUkYxh49iueYOg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAL0kPAU7PO4ykt3=0a8h5A8msj3BQDH7Ut=2QHAVp5SsxEqS9w@mail.gmail.com>
 <mp7r8u$f6e$1@ger.gmane.org>
Message-ID: <CAPTjJmrHXg2eZBDkojqXn9sC7qsFUSH2axthMJsHJ1JQ-6a49w@mail.gmail.com>

On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> On 28/07/2015 06:21, Lennart Regebro wrote:
>>
>> On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence <breamoreboy at yahoo.co.uk>
>> wrote:
>>>
>>> To me a day is precisely 24 hours, no more, no less.
>>> In my mission critical code, which I use to predict my cashflow, I use
>>> code such as.
>>>
>>> timedelta(days=14)
>>>
>>> Is somebody now going to tell me that this isn't actually two weeks?
>>
>>
>> Yes, I'm telling you that, now.
>>
>> The two claims "One day is always precisely 24 hours" and "14 days is
>> two weeks" are not both true. You have to choose one.
>
> You can tell me, but as far as I'm concerned in my application both are
> true, so I don't have to choose one.
(and subsequently)
> Tim asked for my definition of two weeks so I've given it.  With respect
> to that in reality this is true, for me, with my application, making my
> statement above correct.  For my application we could go from GMT
> to BST and back on successive days throughout the year and it
> wouldn't make any difference.

When your clocks go from winter time to summer time, there are two
possibilities:

1) Your application says "days=14" and actually gets 167 or 169 hours
2) Your application says "days=14" and ends up with the time changing

(Or equivalently if you say "days=1" or "hours=24" or whatever.)

A naive declaration of "two weeks later" could conceivably mean
either. When I schedule my weekly Dungeons & Dragons sessions, they
are officially based on UTC [1], which means that one session starts
168 hours after the previous one. Currently, they happen when my local
clock reads noon; in summer, my local clock will read 1PM. Was it
still "a week later" when it was noon once and 1PM the next time?

Conversely, my (also weekly) Thinkful open sessions are scheduled
every week at 8AM US Eastern time (America/New_York). For anyone on
the Atlantic coast of the US, they will occur every Wednesday and the
clock will read 08:00 every time. Sometimes, one will happen 167 hours
after the previous one, or 169 hours afterwards. Is that "a week
later"?

Your application has to make a choice between these two
interpretations. This is a fundamental choice that MUST be made.
Trying to pretend that your application doesn't care is like trying to
say that Code Page 437 is good enough for all your work, and you can
safely assume that one byte is one character is one byte.

ChrisA

[1] Leap seconds aren't significant, as people are often several
minutes early or late, so UTC/UT1/GMT/TIA are all effectively
equivalent.

From ronaldoussoren at mac.com  Tue Jul 28 16:09:44 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 28 Jul 2015 16:09:44 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp6kv0$85l$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com> <mp6kv0$85l$1@ger.gmane.org>
Message-ID: <0C08F002-9439-487F-9173-6FEF1F9544B7@mac.com>


> On 28 Jul 2015, at 03:13, Tres Seaver <tseaver at palladion.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/27/2015 06:11 PM, Ronald Oussoren wrote:
> 
>> Treating time as UTC with conversions at the application edge might
>> be "cleaner" in some sense, but can make code harder to read for 
>> application domain experts.
>> 
>> It might be nice to have time zone aware datetime objects with the 
>> right(TM) semantics, but those can and should not replace the naive 
>> objects we know and love.
> 
> Interesting.  My experience is exactly the opposite:  the datetimes which
> "application domain experts" cared about *always* needed to be non-naive
> (zone captured explicitly or from the user's machine and converted to
> UTC/GMT for storage).  As with encoded bytes, allowing a naive instance
> inside the borders the system was always a time-bomb bug (stuff would
> blow up at a point far removed from which it was introduced).
> 
> The instances which could have safely been naive were all
> logging-related, where the zone was implied by the system's timezone
> (nearly always UTC).  I guess the difference is that I'm usually writing
> apps whose users can't be presumed to be in any one timezone.  Even in
> those cases, having the logged datetimes be incomparable to user-facing
> ones would make them less useful.

I usually write application used by local users where the timezone is completely
irrelevant, including DST.  Stuff needs to be done at (say) 8PM, ands that?s
8PM local time. Switching to and from UTC just adds complications. 

I?m lucky enough that most datetime calculations happen within one work week
and therefore never have to cross DST transitions.  For longer periods I usually
only care about dates, and almost never about the number of seconds between
two datetime instances.   That makes the naive datetime from the stdlib a 
very convenient programming model.

And I?m in a country that?s small enough to have only one timezone.

IMHO Unicode is different in that regard, there the application logic can clearly
be expressed as text and the encoding to/from bytes can safely be hidden in
the I/O layer. Often the users I deal with can follow the application logic w.r.t.
text handling, but have no idea about encodings (but do care about accented
characters). With some luck they can provide a sample file that allows me to 
deduce the encoding that should be used, and most applications are moving 
to UTF-8.

BTW. Note that I?m not saying that a timezone aware datetime is bad, just
that they are not always necessary.

Ronald

From breamoreboy at yahoo.co.uk  Tue Jul 28 19:01:26 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 28 Jul 2015 18:01:26 +0100
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAPTjJmrHXg2eZBDkojqXn9sC7qsFUSH2axthMJsHJ1JQ-6a49w@mail.gmail.com>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAL0kPAU7PO4ykt3=0a8h5A8msj3BQDH7Ut=2QHAVp5SsxEqS9w@mail.gmail.com>
 <mp7r8u$f6e$1@ger.gmane.org>
 <CAPTjJmrHXg2eZBDkojqXn9sC7qsFUSH2axthMJsHJ1JQ-6a49w@mail.gmail.com>
Message-ID: <mp8ch9$76t$1@ger.gmane.org>

On 28/07/2015 16:47, Chris Angelico wrote:
> On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>> On 28/07/2015 06:21, Lennart Regebro wrote:
>>>
>>> On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence <breamoreboy at yahoo.co.uk>
>>> wrote:
>>>>
>>>> To me a day is precisely 24 hours, no more, no less.
>>>> In my mission critical code, which I use to predict my cashflow, I use
>>>> code such as.
>>>>
>>>> timedelta(days=14)
>>>>
>>>> Is somebody now going to tell me that this isn't actually two weeks?
>>>
>>>
>>> Yes, I'm telling you that, now.
>>>
>>> The two claims "One day is always precisely 24 hours" and "14 days is
>>> two weeks" are not both true. You have to choose one.
>>
>> You can tell me, but as far as I'm concerned in my application both are
>> true, so I don't have to choose one.
> (and subsequently)
>> Tim asked for my definition of two weeks so I've given it.  With respect
>> to that in reality this is true, for me, with my application, making my
>> statement above correct.  For my application we could go from GMT
>> to BST and back on successive days throughout the year and it
>> wouldn't make any difference.
>
> When your clocks go from winter time to summer time, there are two
> possibilities:
>
> 1) Your application says "days=14" and actually gets 167 or 169 hours
> 2) Your application says "days=14" and ends up with the time changing

My cashflow forecast doesn't give two hoots how many hours there are in 
two weeks, which I've defined elsewhere.  It doesn't care if the time 
changes.  Neither does it care how many days there are in a month for 
that matter.  It can even cater with plotting data with a tick on the 
29th of each month when we have a leap year and February is included in 
the plot, thanks to the dateutils rrule.

>
> (Or equivalently if you say "days=1" or "hours=24" or whatever.)
>
> A naive declaration of "two weeks later" could conceivably mean
> either. When I schedule my weekly Dungeons & Dragons sessions, they
> are officially based on UTC [1], which means that one session starts
> 168 hours after the previous one. Currently, they happen when my local
> clock reads noon; in summer, my local clock will read 1PM. Was it
> still "a week later" when it was noon once and 1PM the next time?

Don't know and don't care, your application is not working in the same 
way that mine does.

>
> Conversely, my (also weekly) Thinkful open sessions are scheduled
> every week at 8AM US Eastern time (America/New_York). For anyone on
> the Atlantic coast of the US, they will occur every Wednesday and the
> clock will read 08:00 every time. Sometimes, one will happen 167 hours
> after the previous one, or 169 hours afterwards. Is that "a week
> later"?

Ditto my above remark.

>
> Your application has to make a choice between these two
> interpretations. This is a fundamental choice that MUST be made.
> Trying to pretend that your application doesn't care is like trying to
> say that Code Page 437 is good enough for all your work, and you can
> safely assume that one byte is one character is one byte.
>

No.

> ChrisA
>
> [1] Leap seconds aren't significant, as people are often several
> minutes early or late, so UTC/UT1/GMT/TIA are all effectively
> equivalent.
>

Precisely my point.  For me hours are not significant, days are.
-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From rosuav at gmail.com  Tue Jul 28 19:25:57 2015
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 29 Jul 2015 03:25:57 +1000
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp8ch9$76t$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CAExdVNmEzdBJG9xGbRHmq=h3UM10sns7PiRRCrj8ZXv_v=AzZg@mail.gmail.com>
 <mp684v$676$1@ger.gmane.org>
 <CAExdVNn_bw_ATgiQ9jLeAEBgOE1gADGW8Dh=0mNXMc6Ov0HQtg@mail.gmail.com>
 <55B6D3C6.80106@palladion.com> <mp6lg7$fui$1@ger.gmane.org>
 <CAL0kPAU7PO4ykt3=0a8h5A8msj3BQDH7Ut=2QHAVp5SsxEqS9w@mail.gmail.com>
 <mp7r8u$f6e$1@ger.gmane.org>
 <CAPTjJmrHXg2eZBDkojqXn9sC7qsFUSH2axthMJsHJ1JQ-6a49w@mail.gmail.com>
 <mp8ch9$76t$1@ger.gmane.org>
Message-ID: <CAPTjJmo8UM1C+J1T7LJt631eCaZrgU46eYer=mLFTPU16GwJNw@mail.gmail.com>

> On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> To me a day is precisely 24 hours, no more, no less.

Start with this line. Then proceed:

On Wed, Jul 29, 2015 at 3:01 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> My cashflow forecast doesn't give two hoots how many hours there are in two
> weeks, which I've defined elsewhere.  It doesn't care if the time changes.
> Neither does it care how many days there are in a month for that matter.  It
> can even cater with plotting data with a tick on the 29th of each month when
> we have a leap year and February is included in the plot, thanks to the
> dateutils rrule.

Okay. So you do *not* care that a day be, or not be, 24 hours. Your
code cares about days, and does not care if one of them happens to be
23 or 25 hours long. That's what's going on. To you, a day is *one
day*, and has no correlation to 24 hours, 86400 seconds, 86,400,000
milliseconds, or the radiation period of caesium. That's a perfectly
acceptable standpoint, but you MUST acknowledge that this is
incompatible with the equally-acceptable standpoint that "1 day" ==
"24 hours". You cannot have both.

ChrisA

From bcannon at gmail.com  Tue Jul 28 21:26:36 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 28 Jul 2015 19:26:36 +0000
Subject: [Python-Dev] Datetime SIG created
Message-ID: <CAP1=2W6FHPUuHmhkphy2cmKiK7Y3Nb1o_+hrQZ0DjbcVVamjfA@mail.gmail.com>

https://mail.python.org/mailman/listinfo/datetime-sig

In the future feel free to redirect date- and time-related discussions to
the SIG since datetime stuff requires such a specific domain knowledge that
most of us have.

I am also looking for people to be admins of the list. If you're willing to
admin the list please let me know and I will add you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150728/0bde675d/attachment.html>

From victor.stinner at gmail.com  Tue Jul 28 21:53:35 2015
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 28 Jul 2015 21:53:35 +0200
Subject: [Python-Dev] Datetime SIG created
In-Reply-To: <CAP1=2W6FHPUuHmhkphy2cmKiK7Y3Nb1o_+hrQZ0DjbcVVamjfA@mail.gmail.com>
References: <CAP1=2W6FHPUuHmhkphy2cmKiK7Y3Nb1o_+hrQZ0DjbcVVamjfA@mail.gmail.com>
Message-ID: <CAMpsgwat615U5_TBk+HHoFhfVupaoV2RXR7E=kua=RncRsZeSw@mail.gmail.com>

Thanks Brett :-) I agree that a dedicated mailing list is a good idea.

Please stop flooding python-dev and move open discussions to the new
mailing list. By the way, I suggest to open multiple threads since
multiple topics were discussed in the same thread. So it became
difficult to follow the discussion.

Victotr

2015-07-28 21:26 GMT+02:00 Brett Cannon <bcannon at gmail.com>:
> https://mail.python.org/mailman/listinfo/datetime-sig
>
> In the future feel free to redirect date- and time-related discussions to
> the SIG since datetime stuff requires such a specific domain knowledge that
> most of us have.
>
> I am also looking for people to be admins of the list. If you're willing to
> admin the list please let me know and I will add you.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>

From tim.peters at gmail.com  Tue Jul 28 22:26:57 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 28 Jul 2015 15:26:57 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAWQangAcKBP2+kOPK_LdZpQZLtFfMc3WxHuZbqfUW2bPg@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B64C61.20701@mrabarnett.plus.com> <mp5t9b$eb0$1@ger.gmane.org>
 <874mkoengd.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAEZs-E+t_Bdkejq_1NzAYfSvaJWHnH-VUAhbB06aiN_Ey-UZ7w@mail.gmail.com>
 <CAL0kPAWQangAcKBP2+kOPK_LdZpQZLtFfMc3WxHuZbqfUW2bPg@mail.gmail.com>
Message-ID: <CAExdVNmGH2hZyTaCC2MR9QWgSPPRGPKb04uBsUNVnHuz3TTDcg@mail.gmail.com>

[?ukasz Rekucki <lrekucki at gmail.com>]
>> 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?

[Lennart Regebro <regebro at gmail.com>]
> Well, the separation is pretty clear already.

I preemptively ;-) agreed with Lukasz on this:  it's downright strange
that we have datetime objects the docs call "aware" that nevertheless
_act_ as if they were "naive" in some cases of arithmetic.  That was
the intended design, but it is strange in that respect.  So it goes.

> Tim wants to have naive timezone aware objects, ie datetime objects that have
> a time zone but ignores the time zone, except when converting to other time zones.

That's not about what I want.  It's what Python _does_.  We can't wish
away how the language already works.  Guido designed it that way (with
an enormous amount of public input & debate), and I did the vast bulk
of the implementations.  It so happens I like Guido's design, but none
of that ever depended on what Tim wanted datetime to do (except in
minor respects, like adding the .replace() and .fromutc() methods,
which weren't part of the original design - I made those up based on
painful experience with many iterations of ever-changing prototypes -
but my role in arithmetic was just to implement the design specs).

> I have yet to see a use case for that.

Of course you have.  When you address them, you usually dismiss them
as "calendar operations" (IIRC).  In some of those cases, you
correctly pointed out that the user could have done as well (based on
all they explicitly revealed about their app's requirements) with a
naive datetime object.  In other cases, you made the same claim but
seemingly incorrectly (like any app that needs to track the local
clocks across multiple timezones with inter-zone conversions, and also
needs to do "calendar operations" in those timezones, and -
unsurprisingly! - uses Python's datetime arithmetic to implement such
operations.  It's unsurprising they do so because that was always the
intended and documented way to do so - and it has always worked for
these purposes).

But it doesn't matter whether you _call_ them "calendar operations",
or anything else.  What they're called doesn't change any of the
high-order bits:  they are use cases, they already work, they have
worked that way for a dozen years (an eternity in "computer time"),
they were always intended to work that way, and the docs have always
said they work that way.

I do think you're missing my fundamental objection:  no matter what
intended and documented thing datetime (or any other module) has done
all along, and regardless of whether I loved it or hated it, I'd be
just as annoying about insisting we cannot intentionally break
existing code using that thing in non-trivial ways without a
justification so compelling that I can't recall a case of it ever
happening.

If Python had been doing "Lennart arithmetic" all along, and Guido
proposed changing to "Guido arithmetic" in Python 2 and/or Python 3,
I'd be equally opposed to his proposal (& despite that I prefer
Guido's vision of how datetime arithmetic should work - "tough luck -
it's too late". And he'd eventually agree.  Be like Guido ;-) ).

Given Guido's brief message, I'll cut the weasel words, confident that
I'm still channeling his intent in this area:  major
backward-incompatible changes (like altering the meaning of arithmetic
using already-existing objects and operations) are not going to
happen.   It's clear now that he'd even remain opposed to such a
change in a hypothetical everything-can-change Python 4, because he
still likes his original design.

So please move on.  New objects, new operations, new functions, new
methods, new optional arguments on existing methods, even new modules
... all remain on the table.  Changing the meaning of code that some
users are perfectly happy with was never really _on_ the table (which
would have been made clear before if the PEP had spelled out that
changes to the results of arithmetic wouldn't be restricted to a tiny
number of annoying-to-everyone-regardless edge cases).

Even convincing _everyone_ that "it's broken" (which will never happen
either) wouldn't change one jot of this.  Look:

>>> 0.1 + 0.1 + 0.1 == 0.3
False

That will remain "broken" forever too (except, perhaps, until Python
4). and despite that it's one of the most frequent of all user
complaints.

So at worst you're in good company ;-)

From ncoghlan at gmail.com  Wed Jul 29 04:50:24 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 29 Jul 2015 12:50:24 +1000
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <85vbd4l62l.fsf@benfinney.id.au>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
 <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>
 <85zj2glas4.fsf@benfinney.id.au>
 <CACac1F_iEvt_pmpGsCtm-g6Su1cCybzir6kVpQPYBPBc7_KzDQ@mail.gmail.com>
 <85vbd4l62l.fsf@benfinney.id.au>
Message-ID: <CADiSq7dFziv_Srh-O3MmnEQ6TEzSiDd5P9nEoy-U5DNdFvYpEg@mail.gmail.com>

On 29 July 2015 at 00:17, Ben Finney <ben+python at benfinney.id.au> wrote:
> I've made a clear distinction between the need to *be able to* justify a
> change, versus arbitrary demands to do so by arbitrary members.
>
> The latter is what you're arguing against, and of course I agree. I've
> never advocated that.

The thing we work toward as core developers, and aspiring core
developers, is good design intuition that aligns with the Zen of
Python. That doesn't mean we're all going to be able to perfectly
*articulate* that intuition in every case, and even when we can, those
explanations are themselves generally going to be backed by intuition
rather than rigorous scientific research.

Perhaps we need a new initialism to summarise these kinds of cases in
a way that isn't dismissive of the concerns of folks that still have
doubts about a decision: LTIASHIG (Let's Try It And See How It Goes)

It's important to remember that *having* good design intuition is a
*separate* skill from *explaining* design intuition well. The former
involves being able to bring personal experience to bear on a design
task, and produce a result that a non-trivial subset of people enjoy
using. The latter involves things like learning a lot more about human
cognition, and why certain concepts cause the human brain to get
jammed up, and how the way a programming language models a particular
domain relates to how folks learn about that domain in the first
place.

One of the best engineers I ever worked for (my first full-time boss)
had *brilliant* design instincts, but was substantially weaker when it
came to explaining the rationale for his decisions. Spending a few
years figuring out why the software architecture he designed was such
a good one turned out to be one of the most valuable learning
experiences of my life (and, not coincidentally, was my original
exposure to the "communicating sequential processes" approach to
concurrency and parallelism).

CPython core developers have *real authority* as *individuals* over a
language ecosystem used by millions of people. That's a large part of
why we're relatively cautious about handing out commit bits - it's not
just about the technical aspects, it's about developers' design
judgment, and intuitions on when things should be escalated for wider
discussion *before* making a decision. Sometimes that intuition is
going to tell us "this change is worth the risk, even though I can't
fully explain why I think that, and hearing further opinions without
supporting evidence isn't going to change my mind" . Having someone
willing to make that kind of call is one of the big reasons modules
with an active lead maintainer can more readily evolve than the
collectively maintained modules that don't have an authoritative voice
guiding their API design.

And when we make genuine design mistakes (as we inevitably will)?
That's one of the things the deprecation process is for: if a mistake
is actively causing problems for folks attempting to use a feature,
then we have options to deal with it, rather than having to carry it
forever. In many cases, we can even go with a better approach, where
changing our minds later involves making a *backwards compatible API
change*, reducing the practical long term design risk of postponing a
particular aspect of a decision to near zero.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From stephen at xemacs.org  Wed Jul 29 05:41:08 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 29 Jul 2015 12:41:08 +0900
Subject: [Python-Dev] How do we tell if we're helping or hindering
	the	core development process?
In-Reply-To: <85vbd4l62l.fsf@benfinney.id.au>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
 <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>
 <85zj2glas4.fsf@benfinney.id.au>
 <CACac1F_iEvt_pmpGsCtm-g6Su1cCybzir6kVpQPYBPBc7_KzDQ@mail.gmail.com>
 <85vbd4l62l.fsf@benfinney.id.au>
Message-ID: <87y4hzd417.fsf@uwakimon.sk.tsukuba.ac.jp>

Ben Finney writes:

 > I've made a clear distinction between the need to *be able to*
 > justify a change, versus arbitrary demands to do so by arbitrary
 > members.
 > 
 > The latter is what you're arguing against, and of course I agree. I've
 > never advocated that.

Sure, but the former, when stated as a rule rather than induced from
past cases, is also an unacceptably high bar.  It's unnecessarily
high, because this is open source.  No mistake is irrecoverable, even
if it happens in a public release.  One can always keep using the last
release one liked.<wink/>  Or maintain a local fork.  Or switch to a
different language.  Or <gasp/> live with the misfeature.

The other face is that it's impossibly high.  Some decisions can't be
justified rationally, because the theory isn't developed until later,
typically based on experience with an intuitively-approved feature.
In the end, some decisions really do come down to somebody's "gut
feeling".

As I've already said, in the case of "assret" I *personally* think the
demands of accountability were higher than the mere repetition of
"it's a minor design decision" could satisfy.  Nevertheless, I
wouldn't try to enunciate a rule.

Steve


From regebro at gmail.com  Wed Jul 29 06:26:44 2015
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 29 Jul 2015 06:26:44 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAExdVNmGH2hZyTaCC2MR9QWgSPPRGPKb04uBsUNVnHuz3TTDcg@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B64C61.20701@mrabarnett.plus.com> <mp5t9b$eb0$1@ger.gmane.org>
 <874mkoengd.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAEZs-E+t_Bdkejq_1NzAYfSvaJWHnH-VUAhbB06aiN_Ey-UZ7w@mail.gmail.com>
 <CAL0kPAWQangAcKBP2+kOPK_LdZpQZLtFfMc3WxHuZbqfUW2bPg@mail.gmail.com>
 <CAExdVNmGH2hZyTaCC2MR9QWgSPPRGPKb04uBsUNVnHuz3TTDcg@mail.gmail.com>
Message-ID: <CAL0kPAUjLkP-OLEd=-yvgiH81qty7PSV0_XwWGjSFNwOAKZqCQ@mail.gmail.com>

On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters <tim.peters at gmail.com> wrote:
>> I have yet to see a use case for that.
>
> Of course you have.  When you address them, you usually dismiss them
> as "calendar operations" (IIRC).

Those are not usecases for this broken behaviour.

I agree there is a usecase for where you want to add one day to an 8am
datetime, and get 8am the next day. Calling them "date operations" or
"calendar operations" is not dismissing them. I got into this whole
mess because I implemented calendars. That use case is the main
usecase for those operations.

But that usecase is easily handled in several ways. Already today in
how datetime works, you have two solutions: The first is to use a time
zone naive datetime. This is what most people who want to ignore time
zones should use. The other is to separate the datetime into date and
time objects and add a day to the date object.

But most importantly, there are better ways to solve this that
datetime today doesn't support at all:

1. You can use something like dateutil.rrule for repeating events.
(works today, but requires a third-party module).
2. timedelta could not incorrectly pretend that one day is always 24
hours, but actually handle days separately, and always increase the
days when a day is given. (This would however mean we no longer can
support fractional days).
3. There could be a datetelta() object that makes operations on dates,
leaving hours, minuts, seconds and microseconds alone, or something
like Lubridates Perod and Delta objects, where a Period() essentially
operates on wall time, and a Duration() operates on real time.

So that's not the usecase I'm asking for. I am specifically asking for
a usecase where I want an object that is timezone aware, but ignores
the timezone for everything other than conversion to other timezones.
Because that's what datetime implements. That's what I want a usecase
for. "I want the same time next day" is not such a usecase.

And I don't want that use case for you to convince me that we
shouldn't change datetime. You say it breaks too much. OK, if you say
so. I don't know.
I want to know if that use case actually exists, because I don't think it does.

> But it doesn't matter whether you _call_ them "calendar operations",
> or anything else.  What they're called doesn't change any of the
> high-order bits:  they are use cases, they already work, they have
> worked that way for a dozen years (an eternity in "computer time"),
> they were always intended to work that way, and the docs have always
> said they work that way.

They only work like that because people have adapted to how datetime
does things. If datetime had done this properly from the start, it
would have worked even better.

> I do think you're missing my fundamental objection:  no matter what
> intended and documented thing datetime (or any other module) has done
> all along, and regardless of whether I loved it or hated it, I'd be
> just as annoying about insisting we cannot intentionally break
> existing code

I stopped arguying for changing datetime two days ago. I've also
mentioned that several times.

> using that thing in non-trivial ways without a
> justification so compelling that I can't recall a case of it ever
> happening.

Well, I've seen several of those on Stackoverflow.

//Lennart

From ronaldoussoren at mac.com  Wed Jul 29 09:07:31 2015
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 29 Jul 2015 09:07:31 +0200
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <mp6kv0$85l$1@ger.gmane.org>
References: <CAL0kPAU5oKHpFYaS7K09hiV-880tN0Gc+ChYnjEL4Y=Yy6P0Hg@mail.gmail.com>
 <CAL0kPAWHnNct7vX9Z88tpPW+c8eM-9xyPt0K+Ot4hg24VVik=A@mail.gmail.com>
 <CAExdVNmB8cAUA6a02ovn55fQyXVB3gzg7Bq74RrniohN2soyhA@mail.gmail.com>
 <CAL0kPAWKEy1k_uffgTG9pCdJNwKiW+cda=qfSs2GJyX_XPDDgA@mail.gmail.com>
 <CAExdVNm15nTzAhhr=zyStKQn0gL8voiZCRTBXf0muADDe-zutw@mail.gmail.com>
 <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAExdVNmyxNtHa0gGXQGrYWq3f1vALePoX76qVKsa5Eid+87SJw@mail.gmail.com>
 <6B6882FC-D9D4-4A9D-B1DD-5A00836ADB78@mac.com>
 <CAExdVNn=3qZwx8uWa1N0=i+Kr0RNb5sj4Fg6VW98vJ7pqhzokg@mail.gmail.com>
 <E176B273-0237-4687-A007-27C7CDC75C73@mac.com> <mp6kv0$85l$1@ger.gmane.org>
Message-ID: <EC9DA0EF-1ECE-4CC2-8FA5-F495C1AE105E@mac.com>


> On 28 Jul 2015, at 03:13, Tres Seaver <tseaver at palladion.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/27/2015 06:11 PM, Ronald Oussoren wrote:
> 
>> Treating time as UTC with conversions at the application edge might
>> be "cleaner" in some sense, but can make code harder to read for 
>> application domain experts.
>> 
>> It might be nice to have time zone aware datetime objects with the 
>> right(TM) semantics, but those can and should not replace the naive 
>> objects we know and love.
> 
> Interesting.  My experience is exactly the opposite:  the datetimes which
> "application domain experts" cared about *always* needed to be non-naive
> (zone captured explicitly or from the user's machine and converted to
> UTC/GMT for storage).  As with encoded bytes, allowing a naive instance
> inside the borders the system was always a time-bomb bug (stuff would
> blow up at a point far removed from which it was introduced).
> 
> The instances which could have safely been naive were all
> logging-related, where the zone was implied by the system's timezone
> (nearly always UTC).  I guess the difference is that I'm usually writing
> apps whose users can't be presumed to be in any one timezone.  Even in
> those cases, having the logged datetimes be incomparable to user-facing
> ones would make them less useful.

I usually write application used by local users where the timezone is completely
irrelevant, including DST.  Stuff needs to be done at (say) 8PM, ands that?s
8PM local time. Switching to and from UTC just adds complications. 

I?m lucky enough that most datetime calculations happen within one work week
and therefore never have to cross DST transitions.  For longer periods I usually
only care about dates, and almost never about the number of seconds between
two datetime instances.   That makes the naive datetime from the stdlib a 
very convenient programming model.

And I?m in a country that?s small enough to have only one timezone.

IMHO Unicode is different in that regard, there the application logic can clearly
be expressed as text and the encoding to/from bytes can safely be hidden in
the I/O layer. Often the users I deal with can follow the application logic w.r.t.
text handling, but have no idea about encodings (but do care about accented
characters). With some luck they can provide a sample file that allows me to 
deduce the encoding that should be used, and most applications are moving 
to UTF-8.

BTW. Note that I?m not saying that a timezone aware datetime is bad, just
that they are not always necessary.

Ronald

From rdmurray at bitdance.com  Wed Jul 29 17:04:06 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 29 Jul 2015 11:04:06 -0400
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUjLkP-OLEd=-yvgiH81qty7PSV0_XwWGjSFNwOAKZqCQ@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B64C61.20701@mrabarnett.plus.com> <mp5t9b$eb0$1@ger.gmane.org>
 <874mkoengd.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAEZs-E+t_Bdkejq_1NzAYfSvaJWHnH-VUAhbB06aiN_Ey-UZ7w@mail.gmail.com> <CAL0
 kPAWQangAcKBP2+kOPK_LdZpQZLtFfMc3WxHuZbqfUW2bPg@mail.gmail.com>
 <CAExdVNmGH2hZyTaCC2MR9QWgSPPRGPKb04uBsUNVnHuz3TTDcg@mail.gmail.com>
 <CAL0kPAUjLkP-OLEd=-yvgiH81qty7PSV0_XwWGjSFNwOAKZqCQ@mail.gmail.com>
Message-ID: <20150729150406.B9653250EA9@webabinitio.net>

On Wed, 29 Jul 2015 06:26:44 +0200, Lennart Regebro <regebro at gmail.com> wrote:
> On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters <tim.peters at gmail.com> wrote:
> >> I have yet to see a use case for that.
> >
> > Of course you have.  When you address them, you usually dismiss them
> > as "calendar operations" (IIRC).
> 
> Those are not usecases for this broken behaviour.
> 
> I agree there is a usecase for where you want to add one day to an 8am
> datetime, and get 8am the next day. Calling them "date operations" or
> "calendar operations" is not dismissing them. I got into this whole
> mess because I implemented calendars. That use case is the main
> usecase for those operations.
> 
> But that usecase is easily handled in several ways. Already today in
> how datetime works, you have two solutions: The first is to use a time
> zone naive datetime. This is what most people who want to ignore time
> zones should use. The other is to separate the datetime into date and
> time objects and add a day to the date object.

I said I was done commenting, and this is supposed to move to the
datetime-sig, but this "lack of use cases" keeps coming up, so I'm going
to make one more comment, repeating something I said earlier.

What *I* want aware datetimes to do is give me the correct timezone
label when I format them, given the date and time information they hold.
The naive arithmetic is perfect, the conversion between timezones is
fine, the only thing missing from my point of view is a timezone
database such that if I tell a datetime it is in zone X, it will print
the correct offset and/or timezone label when I format it as a string.

That's my use case; and it is, I would venture to guess, *the* most
common use case that datetime does not currently support, and I was very
disappointed to find that pytz didn't support it either (except via
'normalize' calls, but why should I have to call normalize every
time I do datetime arithmetic?  It should just *do* it.)

Anything more would be gravy from my point of view.

Now, maybe tzinfo can't actually support this, but I haven't heard Tim
say that it can't.  Since the datetime is always passed to tzinfo,
I think it can.

--David

PS: annoying story: I scheduled an event six months in advance on my
tablet's calendar, and it scheduled it using what was my *current* GMT
offset (it calls it a time zone) even though it knew what date I was
scheduling it on.  Which meant the alarm in my calendar was off by an
hour.  I hope they have fixed this bug.  I relay this because it is
exactly the same problem I find to be present in pytz.  If the calendar
had been using aware datetimes and naive arithmetic as I describe above,
the alarm would not have been off by an hour.

From wes.turner at gmail.com  Wed Jul 29 18:18:57 2015
From: wes.turner at gmail.com (Wes Turner)
Date: Wed, 29 Jul 2015 11:18:57 -0500
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <87y4hzd417.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
 <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>
 <85zj2glas4.fsf@benfinney.id.au>
 <CACac1F_iEvt_pmpGsCtm-g6Su1cCybzir6kVpQPYBPBc7_KzDQ@mail.gmail.com>
 <85vbd4l62l.fsf@benfinney.id.au>
 <87y4hzd417.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CACfEFw-meQC2XjdGOiwwJ8A9VNc61zgNiNocxhR2aSRF65iM_g@mail.gmail.com>

On Jul 28, 2015 10:41 PM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>
> Ben Finney writes:
>
>  > I've made a clear distinction between the need to *be able to*
>  > justify a change, versus arbitrary demands to do so by arbitrary
>  > members.
>  >
>  > The latter is what you're arguing against, and of course I agree. I've
>  > never advocated that.
>
> Sure, but the former, when stated as a rule rather than induced from
> past cases, is also an unacceptably high bar.  It's unnecessarily
> high, because this is open source.  No mistake is irrecoverable, even
> if it happens in a public release.  One can always keep using the last
> release one liked.<wink/>  Or maintain a local fork.  Or switch to a
> different language.  Or <gasp/> live with the misfeature.
>
> The other face is that it's impossibly high.  Some decisions can't be
> justified rationally, because the theory isn't developed until later,
> typically based on experience with an intuitively-approved feature.
> In the end, some decisions really do come down to somebody's "gut
> feeling".
>
> As I've already said, in the case of "assret" I *personally* think the
> demands of accountability were higher than the mere repetition of
> "it's a minor design decision" could satisfy.  Nevertheless, I
> wouldn't try to enunciate a rule.

* sorry, I haven't the context for this: would -m compileall or an AST
preprocess help catch speling mistakes as well as syntax highlighting?
* If the constraints are ill-defined, there are not enough tests; "Fearless
Refactoring"

>
> Steve
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150729/48080d0c/attachment.html>

From ethan at stoneleaf.us  Wed Jul 29 18:34:09 2015
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 29 Jul 2015 09:34:09 -0700
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <CACfEFw-meQC2XjdGOiwwJ8A9VNc61zgNiNocxhR2aSRF65iM_g@mail.gmail.com>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
 <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>
 <85zj2glas4.fsf@benfinney.id.au>
 <CACac1F_iEvt_pmpGsCtm-g6Su1cCybzir6kVpQPYBPBc7_KzDQ@mail.gmail.com>
 <85vbd4l62l.fsf@benfinney.id.au> <87y4hzd417.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CACfEFw-meQC2XjdGOiwwJ8A9VNc61zgNiNocxhR2aSRF65iM_g@mail.gmail.com>
Message-ID: <55B90081.7010900@stoneleaf.us>

On 07/29/2015 09:18 AM, Wes Turner wrote:

> sorry, I haven't the context for this

tl;dr -- Mock objects now protect against accidentally accessing wrong assert methods by raising an attribute error;  this is different than past behavior in that any attribute that didn't exist 
simply returned a new Mock.  Besides guarding against incorrect "assert*" attributes, it also guards against "assret*" attributes.


For the complete history:

   https://mail.python.org/pipermail/python-dev/2015-July/140720.html

Please keep in mind that this has been discussed enough.

--
~Ethan~

From catalin.gabriel.manciu at intel.com  Wed Jul 29 16:52:15 2015
From: catalin.gabriel.manciu at intel.com (Catalin G. Manciu)
Date: Wed, 29 Jul 2015 14:52:15 +0000 (UTC)
Subject: [Python-Dev] Benchmark Results for Python Default 2015-07-24
References: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>
 <55B243CD.50501@gmail.com>
 <CADiSq7dU_aL=vpshkxYv8DY0FRyyTN+rf3SsWc2PX_WPWbgGCQ@mail.gmail.com>
 <CAP1=2W4qC8yAJ+s23sV3GCyoFDj+uwnypbk6G-q6ZPPOmv2M+A@mail.gmail.com>
Message-ID: <loom.20150729T164813-570@post.gmane.org>

Brett Cannon <brett <at> python.org> writes:

> 
> 
> Should we discuss of these are the benchmarks we want daily reports on 
(you can see what the benchmark suite has at 
https://hg.python.org/benchmarks/file/2979f5ce6a0c/perf.py#l2243 )? I 
personally would prefer dropping pybench and replacing it with a startup 
measurement.
> 
> On Fri, Jul 24, 2015, 07:23?Nick Coghlan <ncoghlan <at> gmail.com> wrote:
> 
> On 24 July 2015 at 23:55, Serhiy Storchaka <storchaka <at> gmail.com> 
wrote:
> > On 24.07.15 15:34, lp_benchmark_robot wrote:
> >> The community's feedback is very important for us. For any questions,
> >> comments or suggestions you can also contact us on our mailing list
> >> lp <at> lists.01.org. You can also check our website: 
https://www.01.org/lp
> >
> > It is cool! Thank you, it whats we need.
> Indeed!
> > But perhaps it would be better to post these reports on
> > python-checkins <at> python.org instead of Python-Dev list, with Reply-
To set to
> > python-dev <at> python.org.
> Aye, python-checkins is a better option for automated daily posts.
> Cheers,
> Nick.
> --
> Nick Coghlan? ?|? ?ncoghlan <at> gmail.com? ?|? ?Brisbane, Australia
> _______________________________________________
> Python-Dev mailing listPython-Dev <at> 
python.orghttps://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-
dev/brett%40python.org
> 
> 
> 
> 
> <div>
> <p dir="ltr">Should we discuss of these are the benchmarks we want daily 
reports on (you can see what the benchmark suite has at <br><a 
href="https://hg.python.org/benchmarks/file/2979f5ce6a0c/perf.py#l2243">http
s://hg.python.org/benchmarks/file/2979f5ce6a0c/perf.py#l2243</a> )? I 
personally would prefer dropping pybench and replacing it with a startup 
measurement.</p>
> <br><div class="gmail_quote">
> <div dir="ltr">On Fri, Jul 24, 2015, 07:23?Nick Coghlan <<a 
href="mailto:ncoghlan <at> gmail.com">ncoghlan <at> gmail.com</a>> wrote:
<br>
> </div>
> <blockquote class="gmail_quote">On 24 July 2015 at 23:55, Serhiy Storchaka 
<<a href="mailto:storchaka <at> gmail.com" target="_blank">storchaka <at> 
gmail.com</a>> wrote:<br>
> > On 24.07.15 15:34, lp_benchmark_robot wrote:<br>
> >> The community's feedback is very important for us. For any 
questions,<br>
> >> comments or suggestions you can also contact us on our mailing 
list<br>
> >> <a href="mailto:lp <at> lists.01.org" target="_blank">lp <at> 
lists.01.org</a>. You can also check our website: <a 
href="https://www.01.org/lp" rel="noreferrer" 
target="_blank">https://www.01.org/lp</a><br>
> ><br>
> > It is cool! Thank you, it whats we need.<br><br>
> Indeed!<br><br>
> > But perhaps it would be better to post these reports on<br>
> > <a href="mailto:python-checkins <at> python.org" 
target="_blank">python-checkins <at> python.org</a> instead of Python-Dev 
list, with Reply-To set to<br>
> > <a href="mailto:python-dev <at> python.org" target="_blank">python-
dev <at> python.org</a>.<br><br>
> Aye, python-checkins is a better option for automated daily posts.<br><br>
> Cheers,<br>
> Nick.<br><br>
> --<br>
> Nick Coghlan? ?|? ?<a href="mailto:ncoghlan <at> 
gmail.com" target="_blank">ncoghlan <at> gmail.com</a>? ?|? 
?Brisbane, Australia<br>
> _______________________________________________<br>
> Python-Dev mailing list<br><a href="mailto:Python-Dev <at> python.org" 
target="_blank">Python-Dev <at> python.org</a><br><a 
href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" 
target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-
dev/brett%40python.org" rel="noreferrer" 
target="_blank">https://mail.python.org/mailman/options/python-
dev/brett%40python.org</a><br>
> </blockquote>
> </div>
> </div>
> 


Thank you for your feedback! We value the community?s input and we would 
like to provide the most relevant results in our automatic measurements. 
Regarding the startup benchmarks, could you tell us which one you think is 
the most useful to be included in the daily report ("normal_startup", 
"startup_nosite")?

Regards !

From brett at python.org  Wed Jul 29 18:44:23 2015
From: brett at python.org (Brett Cannon)
Date: Wed, 29 Jul 2015 16:44:23 +0000
Subject: [Python-Dev] Benchmark Results for Python Default 2015-07-24
In-Reply-To: <loom.20150729T164813-570@post.gmane.org>
References: <C76A91C7CA77874297AEA8FB0BA10F891757E7E1@IRSMSX101.ger.corp.intel.com>
 <55B243CD.50501@gmail.com>
 <CADiSq7dU_aL=vpshkxYv8DY0FRyyTN+rf3SsWc2PX_WPWbgGCQ@mail.gmail.com>
 <CAP1=2W4qC8yAJ+s23sV3GCyoFDj+uwnypbk6G-q6ZPPOmv2M+A@mail.gmail.com>
 <loom.20150729T164813-570@post.gmane.org>
Message-ID: <CAP1=2W7spRR8+9pWSO0FP7Z9d-W+Fk692ysnRr=xO3Q=iL=etw@mail.gmail.com>

On Wed, Jul 29, 2015 at 9:40 AM Catalin G. Manciu <
catalin.gabriel.manciu at intel.com>
[SNIP -- stuff came back as visible HTML; hopefully I didn't miss something]

>
>
> Thank you for your feedback! We value the community?s input and we would
> like to provide the most relevant results in our automatic measurements.
> Regarding the startup benchmarks, could you tell us which one you think is
> the most useful to be included in the daily report ("normal_startup",
> "startup_nosite")?
>

I personally think normal_startup is best as that's how people probably
typically launch Python.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150729/ccf866e2/attachment.html>

From robertc at robertcollins.net  Wed Jul 29 18:54:54 2015
From: robertc at robertcollins.net (Robert Collins)
Date: Thu, 30 Jul 2015 04:54:54 +1200
Subject: [Python-Dev] How do we tell if we're helping or hindering the
 core development process?
In-Reply-To: <85vbd4l62l.fsf@benfinney.id.au>
References: <CADiSq7fOdWRC25n2es+JTVmyYysiEEMtAyoQcKcvFkyJo_DUag@mail.gmail.com>
 <85twsxomir.fsf@benfinney.id.au>
 <CACac1F_gEz1GdX6TYH1vQE78inSUhn+w5Cq3igO1j=e053An0A@mail.gmail.com>
 <CADiSq7eegRCJdsz7ysVgTNoWy0Qr+xbQK9XrLZD9TSNt6Z4TOQ@mail.gmail.com>
 <CAJ3HoZ1gcKwZk5zuR-sQFKRRDZQUd7D1w5r+AEFtfFd=r4Acrw@mail.gmail.com>
 <858ua0ncda.fsf_-_@benfinney.id.au>
 <CACac1F-Q-A=v8-WJxt6NyfU-GCmQZPiYPMa1HDcHJR-Ss71ymg@mail.gmail.com>
 <85zj2glas4.fsf@benfinney.id.au>
 <CACac1F_iEvt_pmpGsCtm-g6Su1cCybzir6kVpQPYBPBc7_KzDQ@mail.gmail.com>
 <85vbd4l62l.fsf@benfinney.id.au>
Message-ID: <CAJ3HoZ0caFsz2BabkODrV_LUN=0UzF_fj0KDSow6vNCqTAzQaA@mail.gmail.com>

On 29 July 2015 at 02:17, Ben Finney <ben+python at benfinney.id.au> wrote:
> Paul Moore <p.f.moore at gmail.com> writes:
>
>> On 28 July 2015 at 13:35, Ben Finney <ben+python at benfinney.id.au> wrote:
>> > People can, do, and probably must make many decisions through
>> > non-rational processes. I don't propose to change that.
>>
>> Good.
>>
>> > Choices can be made that, when challenged, lack compelling rational
>> > justification. I do propose that such a challenge should be taken as a
>> > healthy desire to improve Python, not a personal attack.
>>
>> While that is fine, you appear unwilling to accept the possibility
>> that people may not have the time/energy to develop a detailed
>> rational justification for a change that they have made, and demanding
>> that they do so when they are offering the time they do give on a
>> volunteer basis, is what I claim is unacceptable.
>
> I've said many times now that's not what I'm advocating.
>
> I've made a clear distinction between the need to *be able to* justify a
> change, versus arbitrary demands to do so by arbitrary members.
>
> The latter is what you're arguing against, and of course I agree. I've
> never advocated that.

I'm arguing against the former. Being able to survive a crowd sourced
grilling on any arbitrary change would be quite the chilling effect,
and its a level of backpressure that the committers who engaged in
this discussion have rejected. Some have rejected contributing *at
all* as a result of the discussion. Others, like me, are telling you
that you're wrong, that we don't accept that we can be called up for
any odd commit and asked to justify it to anyone.

There is a social contract around our commits - and it does permit
enquiry and discussion, but not with the degree of heat or antagonism
that was present in this thread.

AND

Not by uninformed folk: If you're going to second guess the onus is on
you to educate yourself about the issue first. This particular one,
for instance, requires going back through the history of mock right to
its founding in 2007, and walking forward through the merge into the
stdlib in Python 3,3 (because its popular) and finally the realisation
that large chunks of peoples code were silently not testing what was
desired and the fixing of that. Discussing the thing we discussed *in
that context* is a very different discussion to what we had, where
every second message was someone misunderstanding what the issue is
and chiming in to say that this is surprising and unPythonic and
against the Zen and oh my.

>> The issue is not one of your motives in asking for explanations - it's
>> the implication that you are entitled to require others to *provide*
>> those explanations, to whatever level of detail *you* require.
>
> Hopefully this repetition is enough: I do not claim any such entitlement.

If you don't claim such entitlement, who does? Whose entitlement are
you arguing for? If its Guido's, I think we can stop arguing - sure,
he is entitled to ask for a lot, but I don't want to argue about what
entitlements someone else has: they can argue on their own.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

From tim.peters at gmail.com  Thu Jul 30 02:03:46 2015
From: tim.peters at gmail.com (Tim Peters)
Date: Wed, 29 Jul 2015 19:03:46 -0500
Subject: [Python-Dev] Status on PEP-431 Timezones
In-Reply-To: <CAL0kPAUjLkP-OLEd=-yvgiH81qty7PSV0_XwWGjSFNwOAKZqCQ@mail.gmail.com>
References: <CAL0kPAXF_2owtSSBY_pm_UwgT+8YdKLj+WY4D7TqsAP7nAmcpw@mail.gmail.com>
 <CAExdVNk_+B15LV3Z3+nb3=vF=h6CNMoknR-DpFSwvvO1JHjLqg@mail.gmail.com>
 <CAL0kPAUPtEdwHDioKYaPhgKpsJSmAC1C_LM75z99AMyyRnpu5Q@mail.gmail.com>
 <CADiSq7degoypz=FD3fzrUfCJaxx1C-8_5MaV+K30J_Wzezoy+w@mail.gmail.com>
 <CACac1F_NthtX8v=ixt_SkcLY=99RAArD03UMD-vTexrQdKzeqQ@mail.gmail.com>
 <CAL0kPAVv1_cDfsYgF8eiWZh0n_rmVfHcHvUOSP-=V5KxiUG0-Q@mail.gmail.com>
 <CAExdVNmj34zKyoetjrcN0kbqj9yoH=QVkVKr7cWicWnE9QmEnA@mail.gmail.com>
 <CAL0kPAUnwfPt6Y342nJ8ebrQ9_1GUObz0YsHWtr2A9qU=_Eb2A@mail.gmail.com>
 <CACac1F_TfiVTaX+3yn6nJtTSzYi0fjT+CG_xXc_mXj_GuWWUFQ@mail.gmail.com>
 <CAL0kPAVYszZJuGc5EBmeJePGjw8TDAOn0NmjjpzaY0PCa9LMnA@mail.gmail.com>
 <20150727141316.GA25179@ando.pearwood.info>
 <CAL0kPAVzNF-u7zZty=ugMRM0VW_P7_NHT2o7z25=XH4mj1pQ1A@mail.gmail.com>
 <55B64C61.20701@mrabarnett.plus.com> <mp5t9b$eb0$1@ger.gmane.org>
 <874mkoengd.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAEZs-E+t_Bdkejq_1NzAYfSvaJWHnH-VUAhbB06aiN_Ey-UZ7w@mail.gmail.com>
 <CAL0kPAWQangAcKBP2+kOPK_LdZpQZLtFfMc3WxHuZbqfUW2bPg@mail.gmail.com>
 <CAExdVNmGH2hZyTaCC2MR9QWgSPPRGPKb04uBsUNVnHuz3TTDcg@mail.gmail.com>
 <CAL0kPAUjLkP-OLEd=-yvgiH81qty7PSV0_XwWGjSFNwOAKZqCQ@mail.gmail.com>
Message-ID: <CAExdVNmiEwNoNXywomqE7D=ZWJL=tnREC+-AmrX2B9279V5-Cw@mail.gmail.com>

[Lennart Regebro]
\>>> I have yet to see a use case for that.

[Tim]
>> Of course you have.  When you address them, you usually dismiss them
>> as "calendar operations" (IIRC).

'[Lennart]

> Those are not usecases for this broken behaviour.
>
> I agree there is a usecase for where you want to add one day to an 8am
> datetime, and get 8am the next day. Calling them "date operations" or
> "calendar operations" is not dismissing them. I got into this whole
> mess because I implemented calendars. That use case is the main
> usecase for those operations.
>
> But that usecase is easily handled in several ways. Already today in
> how datetime works, you have two solutions: The first is to use a time
> zone naive datetime. This is what most people who want to ignore time
> zones should use. The other is to separate the datetime into date and
> time objects and add a day to the date object.
>
> But most importantly, there are better ways to solve this that
> datetime today doesn't support at all:
>
> 1. You can use something like dateutil.rrule for repeating events.
> (works today, but requires a third-party module).
> 2. timedelta could not incorrectly pretend that one day is always 24
> hours, but actually handle days separately, and always increase the
> days when a day is given. (This would however mean we no longer can
> support fractional days).
> 3. There could be a datetelta() object that makes operations on dates,
> leaving hours, minuts, seconds and microseconds alone, or something
> like Lubridates Perod and Delta objects, where a Period() essentially
> operates on wall time, and a Duration() operates on real time.
>
> So that's not the usecase I'm asking for. I am specifically asking for
> a usecase where I want an object that is timezone aware, but ignores
> the timezone for everything other than conversion to other timezones.
> Because that's what datetime implements. That's what I want a usecase
> for. "I want the same time next day" is not such a usecase.
>
> And I don't want that use case for you to convince me that we
> shouldn't change datetime. You say it breaks too much. OK, if you say
> so. I don't know.
> I want to know if that use case actually exists, because I don't think it does.
>
>> But it doesn't matter whether you _call_ them "calendar operations",
>> or anything else.  What they're called doesn't change any of the
>> high-order bits:  they are use cases, they already work, they have
>> worked that way for a dozen years (an eternity in "computer time"),
>> they were always intended to work that way, and the docs have always
>> said they work that way.
>
> They only work like that because people have adapted to how datetime
> does things. If datetime had done this properly from the start, it
> would have worked even better.
>
>> I do think you're missing my fundamental objection:  no matter what
>> intended and documented thing datetime (or any other module) has done
>> all along, and regardless of whether I loved it or hated it, I'd be
>> just as annoying about insisting we cannot intentionally break
>> existing code
>
> I stopped arguying for changing datetime two days ago. I've also
> mentioned that several times.
>
>> using that thing in non-trivial ways without a
>> justification so compelling that I can't recall a case of it ever
>> happening.
>
> Well, I've seen several of those on Stackoverflow.
>
> //Lennart

From breamoreboy at yahoo.co.uk  Fri Jul 31 03:01:09 2015
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Fri, 31 Jul 2015 02:01:09 +0100
Subject: [Python-Dev] Issues not responded to.
Message-ID: <mpehcq$soi$1@ger.gmane.org>

There are over 400 issues on the bug tracker that have not had a 
response to the initial message, roughly half of these within the last 
eight months alone.  Is there a (relatively) simple way that we can 
share these out between us to sort those that are likely to need dealing 
with in the medium to longer term, from the simple short term ones, e.g 
very easy typo fixes?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


From brett at python.org  Fri Jul 31 03:21:10 2015
From: brett at python.org (Brett Cannon)
Date: Fri, 31 Jul 2015 01:21:10 +0000
Subject: [Python-Dev] Issues not responded to.
In-Reply-To: <mpehcq$soi$1@ger.gmane.org>
References: <mpehcq$soi$1@ger.gmane.org>
Message-ID: <CAP1=2W5DSjEtHqh=6wbNtq_0+fATQ3Hbj-y0g-7xLpMvGHSozA@mail.gmail.com>

On Thu, Jul 30, 2015 at 6:02 PM Mark Lawrence <breamoreboy at yahoo.co.uk>
wrote:

> There are over 400 issues on the bug tracker that have not had a
> response to the initial message, roughly half of these within the last
> eight months alone.  Is there a (relatively) simple way that we can
> share these out between us to sort those that are likely to need dealing
> with in the medium to longer term, from the simple short term ones, e.g
> very easy typo fixes?
>

Best thing I can think of is to post the Roundup search you did to find
those 400 so thoseof us who can help can just start whittling them away.
You could also share it with core-mentorship and explain we need help
evaluating these issues with the caveat we have no idea how difficult it is
to do the evaluation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150731/5b353316/attachment.html>

From Nikolaus at rath.org  Fri Jul 31 05:03:01 2015
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Thu, 30 Jul 2015 20:03:01 -0700
Subject: [Python-Dev] Issues not responded to.
In-Reply-To: <mpehcq$soi$1@ger.gmane.org> (Mark Lawrence's message of "Fri, 31
 Jul 2015 02:01:09 +0100")
References: <mpehcq$soi$1@ger.gmane.org>
Message-ID: <87r3npyqoq.fsf@vostro.rath.org>

On Jul 31 2015, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> There are over 400 issues on the bug tracker that have not had a
> response to the initial message, roughly half of these within the last
> eight months alone.  Is there a (relatively) simple way that we can
> share these out between us to sort those that are likely to need
> dealing with in the medium to longer term, from the simple short term
> ones, e.g very easy typo fixes?


Nick recently mentioned that the PSF might be able to help, but that the
initiative for that needs to come from the core developers. So why don't
you guys ask the PSF to e.g. sponsor some of the work that no one feels
motivated to do in their spare time?

To avoid issues with some people being paid for work that others
contribute in their free time one could introduce a new keyword in the
tracker (say "ugly"). Whenever a core developer sees an issue that he[1]
thinks should be worked on, but that he really does not want to do in
his free time, he tags it with "ugly" and the issue becomes available
for PSF-sponsored work.

Best,
-Nikolaus

[1] I first wanted to write he/she - but are there actually any female
    core contributors?

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From carl at oddbird.net  Fri Jul 31 06:07:09 2015
From: carl at oddbird.net (Carl Meyer)
Date: Thu, 30 Jul 2015 22:07:09 -0600
Subject: [Python-Dev] Issues not responded to.
In-Reply-To: <87r3npyqoq.fsf@vostro.rath.org>
References: <mpehcq$soi$1@ger.gmane.org> <87r3npyqoq.fsf@vostro.rath.org>
Message-ID: <55BAF46D.2090209@oddbird.net>

On 07/30/2015 09:03 PM, Nikolaus Rath wrote:
> Nick recently mentioned that the PSF might be able to help, but that the
> initiative for that needs to come from the core developers. So why don't
> you guys ask the PSF to e.g. sponsor some of the work that no one feels
> motivated to do in their spare time?
> 
> To avoid issues with some people being paid for work that others
> contribute in their free time one could introduce a new keyword in the
> tracker (say "ugly"). Whenever a core developer sees an issue that he[1]
> thinks should be worked on, but that he really does not want to do in
> his free time, he tags it with "ugly" and the issue becomes available
> for PSF-sponsored work.

I'm a Django core developer. For the last half-year or so, the Django
Software Foundation has (for the first time) paid a "Django Fellow" or
two (currently Tim Graham) to work on core Django. For me the experience
has been excellent. Having a Django Fellow significantly reduces the
guilt-burden of being part of the core team; it frees me to do the work
that I find most interesting, without needing to worry that other
necessary work won't get done. Releases are made on time, new tickets
are triaged, and security issues are attended to, whether I find the
time to do it myself or not, because someone is paid to ensure it
happens. I've never been the person on the core team who took on the
majority of that burden as a volunteer, but I _still_ (perhaps
especially?) feel the guilt-burden lifted. And having that burden lifted
hasn't decreased the overall amount of time I devote to Django; it's
increased it significantly, because spending time on Django has become
more fun.

Contributing to Django is also more fun now than it used to be (for core
developers and, I think, for everyone else) because Tim has been able to
devote significant chunks of time to infrastructure (the CI server and
the GitHub workflow, e.g. having the test suite and several other
automated code quality checks run automatically on every GitHub pull
request) that nobody ever found time to do as a volunteer.

So based on my experience with the transition to having a DSF-paid
Fellow on the Django core team, and having watched important python-dev
work (e.g. the core workflow stuff) linger due to lack of available
volunteer time, I'd recommend that python-dev run, not walk, to ask the
PSF board to fund a similar position for Python core.

Of course there may be differences between the culture of python-dev and
Django core that I'm not fully aware of that may make a difference in
how things work out. And finding the right person for the job is
critical, of course. I think the Django experience suggests that an
existing long-time contributor who is already known and trusted by the
core team is a good bet. Also that the Fellow needs to already have, or
quickly gain, commit privileges themselves.

For whatever it's worth,

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150730/e72c764b/attachment.sig>

From zachary.ware+pydev at gmail.com  Fri Jul 31 06:42:33 2015
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Thu, 30 Jul 2015 23:42:33 -0500
Subject: [Python-Dev] Issues not responded to.
In-Reply-To: <CAP1=2W5DSjEtHqh=6wbNtq_0+fATQ3Hbj-y0g-7xLpMvGHSozA@mail.gmail.com>
References: <mpehcq$soi$1@ger.gmane.org>
 <CAP1=2W5DSjEtHqh=6wbNtq_0+fATQ3Hbj-y0g-7xLpMvGHSozA@mail.gmail.com>
Message-ID: <CAKJDb-NTkZ=1pkHWQ66nYi2dkKC178oQkgFhcUha=0PLjJNoGQ@mail.gmail.com>

On Thu, Jul 30, 2015 at 8:21 PM, Brett Cannon <brett at python.org> wrote:
> Best thing I can think of is to post the Roundup search you did to find
> those 400 so thoseof us who can help can just start whittling them away. You
> could also share it with core-mentorship and explain we need help evaluating
> these issues with the caveat we have no idea how difficult it is to do the
> evaluation.

Here's a query:

https://bugs.python.org/issue?@action=search&@columns=title,id,creator,activity,actor,status&@sort=activity&status=-1,1,3,4&message_count=1

-- 
Zach

From stefan_ml at behnel.de  Fri Jul 31 09:02:24 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 31 Jul 2015 09:02:24 +0200
Subject: [Python-Dev] Issues not responded to.
In-Reply-To: <55BAF46D.2090209@oddbird.net>
References: <mpehcq$soi$1@ger.gmane.org> <87r3npyqoq.fsf@vostro.rath.org>
 <55BAF46D.2090209@oddbird.net>
Message-ID: <mpf6i2$6rb$1@ger.gmane.org>

Carl Meyer schrieb am 31.07.2015 um 06:07:
> So based on my experience with the transition to having a DSF-paid
> Fellow on the Django core team, and having watched important python-dev
> work (e.g. the core workflow stuff) linger due to lack of available
> volunteer time, I'd recommend that python-dev run, not walk, to ask the
> PSF board to fund a similar position for Python core.

Sounds good to me, too. There are already core developers and contributors
being paid for their work in one way or another, either directly or by
'just' being allowed to work on CPython during some of their paid working
hours. Guido's 50% are only the most prominent example. That has never been
a problem. At the end of the day, everyone has to make a living somehow in
order to find time at all to devote to CPython, so I don't see any room for
an envy debate here.

Getting a paid developer in for the background infrastructure work and the
"stuff that needs to get done but wouldn't" seems like a good way to solve
exactly these problems while making it more fun for the others to
concentrate on what they like doing.

Stefan



From xdegaye at gmail.com  Fri Jul 31 13:30:28 2015
From: xdegaye at gmail.com (Xavier de Gaye)
Date: Fri, 31 Jul 2015 13:30:28 +0200
Subject: [Python-Dev] Issues not responded to.
In-Reply-To: <CAKJDb-NTkZ=1pkHWQ66nYi2dkKC178oQkgFhcUha=0PLjJNoGQ@mail.gmail.com>
References: <mpehcq$soi$1@ger.gmane.org>
 <CAP1=2W5DSjEtHqh=6wbNtq_0+fATQ3Hbj-y0g-7xLpMvGHSozA@mail.gmail.com>
 <CAKJDb-NTkZ=1pkHWQ66nYi2dkKC178oQkgFhcUha=0PLjJNoGQ@mail.gmail.com>
Message-ID: <55BB5C54.9000707@gmail.com>



On 07/31/2015 06:42 AM, Zachary Ware wrote:
> On Thu, Jul 30, 2015 at 8:21 PM, Brett Cannon <brett at python.org> wrote:
>> Best thing I can think of is to post the Roundup search you did to find
>> those 400 so thoseof us who can help can just start whittling them away. You
>> could also share it with core-mentorship and explain we need help evaluating
>> these issues with the caveat we have no idea how difficult it is to do the
>> evaluation.
>
> Here's a query:
>
> https://bugs.python.org/issue?@action=search&@columns=title,id,creator,activity,actor,status&@sort=activity&status=-1,1,3,4&message_count=1
>

This is nice, thanks.
Note that this is missing the cases where more than one message was required, for example to send two attachments (a script as the use case, and a patch).

Xavier

From status at bugs.python.org  Fri Jul 31 18:08:26 2015
From: status at bugs.python.org (Python tracker)
Date: Fri, 31 Jul 2015 18:08:26 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20150731160826.9571E568C0@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2015-07-24 - 2015-07-31)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4961 ( +4)
  closed 31563 (+52)
  total  36524 (+56)

Open issues with patches: 2246 


Issues opened (36)
==================

#23447: Import fails when doing a circular import involving an `import
http://bugs.python.org/issue23447  reopened by rbcollins

#24476: Statically link vcruntime140.dll
http://bugs.python.org/issue24476  reopened by steve.dower

#24709: Unix build uses '-Wno-unused-result', which icc doesn't recogn
http://bugs.python.org/issue24709  opened by zach.ware

#24710: Class name hardcoded in TracebackException.from_exception()
http://bugs.python.org/issue24710  opened by berker.peksag

#24711: Document getpass.getpass behavior on ^C
http://bugs.python.org/issue24711  opened by untitaker

#24712: Docs page's sidebar vibrates on mouse wheel scroll on Chrome.
http://bugs.python.org/issue24712  opened by Biwin John

#24715: Sorting HOW TO: bad example for reverse sort stability
http://bugs.python.org/issue24715  opened by jwilk

#24718: Specify interpreter when running in IDLE
http://bugs.python.org/issue24718  opened by Daniel Pope

#24720: Python install help
http://bugs.python.org/issue24720  opened by node

#24724: Element.findall documentation misleading
http://bugs.python.org/issue24724  opened by Eric S

#24725: test_socket testFDPassEmpty fails on OS X 10.11 DP with "Canno
http://bugs.python.org/issue24725  opened by ned.deily

#24726: OrderedDict has strange behaviour when dict.__setitem__ is use
http://bugs.python.org/issue24726  opened by Mark.Shannon

#24727: Expand readline module
http://bugs.python.org/issue24727  opened by Barney Stratford

#24731: Incorrect assert in str_subtype_new
http://bugs.python.org/issue24731  opened by Kevin Modzelewski

#24732: 3.5.0b3 Windows accept() on unready non-blocking socket raises
http://bugs.python.org/issue24732  opened by bryangeneolson

#24733: Logically Dead Code
http://bugs.python.org/issue24733  opened by pankaj.s01

#24736: argparse add_mutually_exclusive_group do not print help
http://bugs.python.org/issue24736  opened by Alexandre.Badez

#24739: allow argparse.FileType to accept newline argument
http://bugs.python.org/issue24739  opened by garyp

#24740: make patchcheck doesn't detect changes if commit is done first
http://bugs.python.org/issue24740  opened by rbcollins

#24743: Make _PyTraceback_Add public
http://bugs.python.org/issue24743  opened by mic-e

#24744: Lack of type checks in pkgutil.walk_packages and friends
http://bugs.python.org/issue24744  opened by sleepycal

#24745: Better default font for editor
http://bugs.python.org/issue24745  opened by markroseman

#24746: doctest 'fancy diff' formats incorrectly strip trailing whites
http://bugs.python.org/issue24746  opened by r.david.murray

#24747: ctypes silently truncates ints larger than C int
http://bugs.python.org/issue24747  opened by encukou

#24748: Change of behavior for importlib between 3.4 and 3.5 with DLL 
http://bugs.python.org/issue24748  opened by ebfortin

#24750: IDLE: Cosmetic improvements for main window
http://bugs.python.org/issue24750  opened by markroseman

#24751: regrtest/buildbot: test run marked as failure even when re-run
http://bugs.python.org/issue24751  opened by zach.ware

#24752: SystemError when importing from a non-package directory
http://bugs.python.org/issue24752  opened by fossilet

#24754: argparse add_argument with action="store_true", type=bool shou
http://bugs.python.org/issue24754  opened by dbagnall

#24755: asyncio.wrap_future undocumented
http://bugs.python.org/issue24755  opened by wodny

#24756: doctest run_docstring_examples does have an obvious utility
http://bugs.python.org/issue24756  opened by r.david.murray

#24757: Installing Py on Windows: Need to restart or logout for path t
http://bugs.python.org/issue24757  opened by John Palermo

#24758: unittest.mock.Mock's new "unsafe" feature needs a better error
http://bugs.python.org/issue24758  opened by Randy Syring

#24760: IDLE settings dialog shouldn't be modal
http://bugs.python.org/issue24760  opened by markroseman

#24761: ERROR: test_dh_params (test.test_ssl.ThreadedTests)
http://bugs.python.org/issue24761  opened by cloud2han9

#24762: Branchless, vectorizable frozen set hash
http://bugs.python.org/issue24762  opened by rhettinger



Most recent 15 issues with no replies (15)
==========================================

#24762: Branchless, vectorizable frozen set hash
http://bugs.python.org/issue24762

#24761: ERROR: test_dh_params (test.test_ssl.ThreadedTests)
http://bugs.python.org/issue24761

#24755: asyncio.wrap_future undocumented
http://bugs.python.org/issue24755

#24746: doctest 'fancy diff' formats incorrectly strip trailing whites
http://bugs.python.org/issue24746

#24743: Make _PyTraceback_Add public
http://bugs.python.org/issue24743

#24740: make patchcheck doesn't detect changes if commit is done first
http://bugs.python.org/issue24740

#24739: allow argparse.FileType to accept newline argument
http://bugs.python.org/issue24739

#24736: argparse add_mutually_exclusive_group do not print help
http://bugs.python.org/issue24736

#24733: Logically Dead Code
http://bugs.python.org/issue24733

#24731: Incorrect assert in str_subtype_new
http://bugs.python.org/issue24731

#24727: Expand readline module
http://bugs.python.org/issue24727

#24718: Specify interpreter when running in IDLE
http://bugs.python.org/issue24718

#24715: Sorting HOW TO: bad example for reverse sort stability
http://bugs.python.org/issue24715

#24711: Document getpass.getpass behavior on ^C
http://bugs.python.org/issue24711

#24709: Unix build uses '-Wno-unused-result', which icc doesn't recogn
http://bugs.python.org/issue24709



Most recent 15 issues waiting for review (15)
=============================================

#24762: Branchless, vectorizable frozen set hash
http://bugs.python.org/issue24762

#24756: doctest run_docstring_examples does have an obvious utility
http://bugs.python.org/issue24756

#24751: regrtest/buildbot: test run marked as failure even when re-run
http://bugs.python.org/issue24751

#24750: IDLE: Cosmetic improvements for main window
http://bugs.python.org/issue24750

#24746: doctest 'fancy diff' formats incorrectly strip trailing whites
http://bugs.python.org/issue24746

#24733: Logically Dead Code
http://bugs.python.org/issue24733

#24724: Element.findall documentation misleading
http://bugs.python.org/issue24724

#24715: Sorting HOW TO: bad example for reverse sort stability
http://bugs.python.org/issue24715

#24710: Class name hardcoded in TracebackException.from_exception()
http://bugs.python.org/issue24710

#24698: get_externals.bat script fails
http://bugs.python.org/issue24698

#24693: zipfile: change RuntimeError to more appropriate exception typ
http://bugs.python.org/issue24693

#24692: types.coroutines() idempotence documentation
http://bugs.python.org/issue24692

#24682: Add Quick Start: Communications section to devguide
http://bugs.python.org/issue24682

#24674: pyclbr not recursively showing classes in packages
http://bugs.python.org/issue24674

#24673: distutils/_msvccompiler does not remove /DLL during link(CComp
http://bugs.python.org/issue24673



Top 10 most discussed issues (10)
=================================

#24667: OrderedDict.popitem()/__str__() raises KeyError
http://bugs.python.org/issue24667  14 msgs

#24748: Change of behavior for importlib between 3.4 and 3.5 with DLL 
http://bugs.python.org/issue24748  13 msgs

#24720: Python install help
http://bugs.python.org/issue24720  12 msgs

#24750: IDLE: Cosmetic improvements for main window
http://bugs.python.org/issue24750  12 msgs

#18378: locale.getdefaultlocale() fails on Mac OS X with default langu
http://bugs.python.org/issue18378   8 msgs

#19450: Bug in sqlite in Windows binaries
http://bugs.python.org/issue19450   7 msgs

#24732: 3.5.0b3 Windows accept() on unready non-blocking socket raises
http://bugs.python.org/issue24732   7 msgs

#20059: Inconsistent urlparse/urllib.parse handling of invalid port va
http://bugs.python.org/issue20059   6 msgs

#23496: Steps for Android Native Build of Python 3.4.2
http://bugs.python.org/issue23496   6 msgs

#24651: Mock.assert* API is in user namespace
http://bugs.python.org/issue24651   6 msgs



Issues closed (52)
==================

#2091: file accepts 'rU+' as a mode
http://bugs.python.org/issue2091  closed by rbcollins

#12160: codecs doc: what is StreamCodec?
http://bugs.python.org/issue12160  closed by berker.peksag

#13884: IDLE: Remove tear-off menu feature
http://bugs.python.org/issue13884  closed by terry.reedy

#17527: PATCH as valid request method in wsgiref.validator
http://bugs.python.org/issue17527  closed by rbcollins

#17991: ctypes.c_char gives a misleading error when passed a one-chara
http://bugs.python.org/issue17991  closed by Steven.Barker

#20051: PA-RISC buildbot: compiler cannot create executables
http://bugs.python.org/issue20051  closed by zach.ware

#20366: SQLite FTS (full text search)
http://bugs.python.org/issue20366  closed by mark

#20544: Use specific asserts in operator tests
http://bugs.python.org/issue20544  closed by python-dev

#20551: Use specific asserts in decimal tests
http://bugs.python.org/issue20551  closed by skrah

#21657: pip.get_installed_distributions() Does not return packages in 
http://bugs.python.org/issue21657  closed by zach.ware

#21697: shutil.copytree() handles symbolic directory incorrectly
http://bugs.python.org/issue21697  closed by berker.peksag

#21750: mock_open data is visible only once for the life of the class
http://bugs.python.org/issue21750  closed by rbcollins

#23254: Document how to close the TCPServer listening socket
http://bugs.python.org/issue23254  closed by rbcollins

#23319: Missing SWAP_INT??in I_set_sw
http://bugs.python.org/issue23319  closed by haypo

#23426: run_setup is broken in distutils
http://bugs.python.org/issue23426  closed by rbcollins

#23441: rlcompleter: tab on empty prefix => insert spaces
http://bugs.python.org/issue23441  closed by berker.peksag

#23589: Redundant sentence in FAQ
http://bugs.python.org/issue23589  closed by rbcollins

#23779: imaplib authenticate raises TypeError if authenticator tries t
http://bugs.python.org/issue23779  closed by rbcollins

#23899: HTTP regression in distutils uploads to chishop
http://bugs.python.org/issue23899  closed by jason.coombs

#23931: Update DevGuide link in Quickstart Step 1
http://bugs.python.org/issue23931  closed by berker.peksag

#24109: Documentation for difflib uses optparse
http://bugs.python.org/issue24109  closed by berker.peksag

#24279: Update test_base64 to use test.support.script_helper
http://bugs.python.org/issue24279  closed by berker.peksag

#24360: improve argparse.Namespace __repr__ for invalid identifiers.
http://bugs.python.org/issue24360  closed by berker.peksag

#24420: Documentation regressions from adding subprocess.run()
http://bugs.python.org/issue24420  closed by berker.peksag

#24603: Update OpenSSL to 1.0.2d in Windows and OS X installer
http://bugs.python.org/issue24603  closed by ned.deily

#24613: array.fromstring Use After Free
http://bugs.python.org/issue24613  closed by serhiy.storchaka

#24621: zipfile.BadZipFile: File is not a zip file
http://bugs.python.org/issue24621  closed by serhiy.storchaka

#24645: logging.handlers.QueueHandler should not lock when handling a 
http://bugs.python.org/issue24645  closed by vinay.sajip

#24681: Put most likely test first in set_add_entry()
http://bugs.python.org/issue24681  closed by rhettinger

#24683: Type confusion in json encoding
http://bugs.python.org/issue24683  closed by serhiy.storchaka

#24708: strop.replace Integer Overflow
http://bugs.python.org/issue24708  closed by python-dev

#24713: Import docs reference the deprecated imp.reload
http://bugs.python.org/issue24713  closed by berker.peksag

#24714: Crash with string_at(None)
http://bugs.python.org/issue24714  closed by haypo

#24716: Multiple fdopen() on mkstemp() descriptor crashes py27 interpr
http://bugs.python.org/issue24716  closed by Thomas Krijnen

#24717: python logging handler not used when added after a process is 
http://bugs.python.org/issue24717  closed by vinay.sajip

#24719: Resourc Leak in cPickle Module
http://bugs.python.org/issue24719  closed by python-dev

#24721: The result of calling dict.* methods on OrderedDict is undefin
http://bugs.python.org/issue24721  closed by rhettinger

#24722: Python install help
http://bugs.python.org/issue24722  closed by zach.ware

#24723: The new typing module is not documented :-(
http://bugs.python.org/issue24723  closed by berker.peksag

#24728: Build fails when threads are disabled
http://bugs.python.org/issue24728  closed by berker.peksag

#24729: Input and Output tutorial erroneously references default encod
http://bugs.python.org/issue24729  closed by jason.coombs

#24730: Returning a float via a method yields in an approximate value 
http://bugs.python.org/issue24730  closed by zach.ware

#24734: Dereferencing a null returning value
http://bugs.python.org/issue24734  closed by python-dev

#24735: Invalid access in combinations_with_replacement()
http://bugs.python.org/issue24735  closed by rhettinger

#24737: Doc issue: Python 3.6 doesn't compile on Visual Studio 2010 an
http://bugs.python.org/issue24737  closed by steve.dower

#24738: os.link() issues on Windows & ReFS
http://bugs.python.org/issue24738  closed by r.david.murray

#24741: Hangs and errors while testing on Ubuntu/Intel
http://bugs.python.org/issue24741  closed by r.david.murray

#24742: type(dict with docstring) returns set instead of dict
http://bugs.python.org/issue24742  closed by serhiy.storchaka

#24749: Which fastest python-mysql connector?
http://bugs.python.org/issue24749  closed by haypo

#24753: function to get completion install location for setup.py?
http://bugs.python.org/issue24753  closed by r.david.murray

#24759: Idle: require 8.5 / ttk
http://bugs.python.org/issue24759  closed by terry.reedy

#24763: asyncio.BaseSubprocessTransport triggers an unavoidable Resour
http://bugs.python.org/issue24763  closed by haypo

From tjreedy at udel.edu  Fri Jul 31 21:38:01 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 31 Jul 2015 15:38:01 -0400
Subject: [Python-Dev] Issues not responded to.
In-Reply-To: <55BB5C54.9000707@gmail.com>
References: <mpehcq$soi$1@ger.gmane.org>
 <CAP1=2W5DSjEtHqh=6wbNtq_0+fATQ3Hbj-y0g-7xLpMvGHSozA@mail.gmail.com>
 <CAKJDb-NTkZ=1pkHWQ66nYi2dkKC178oQkgFhcUha=0PLjJNoGQ@mail.gmail.com>
 <55BB5C54.9000707@gmail.com>
Message-ID: <mpgiqu$9ik$1@ger.gmane.org>

On 7/31/2015 7:30 AM, Xavier de Gaye wrote:
>
>
> On 07/31/2015 06:42 AM, Zachary Ware wrote:
>> On Thu, Jul 30, 2015 at 8:21 PM, Brett Cannon <brett at python.org>
>> wrote:
>>> Best thing I can think of is to post the Roundup search you did

Just put 1 in the Message count box on the standard search page. 
Nothing special.

>>> to find those 400 so thoseof us who can help can just start
>>> whittling them away. You could also share it with core-mentorship
>>> and explain we need help evaluating these issues with the caveat
>>> we have no idea how difficult it is to do the evaluation.
>>
>> Here's a query:
>> https://bugs.python.org/issue?@action=search&@columns=title,id,creator,activity,actor,status&@sort=activity&status=-1,1,3,4&message_count=1

> This is nice, thanks. Note that this is missing the cases where more
> than one message was required, for example to send two attachments (a
> script as the use case, and a patch).

A second attachment by itself should not increase the message count. 
But people sometimes add a second message with or without an upload.

Putting 1 in the Nosy count will also pick up orphans if no one else has 
been added as nosy.  But the latter can be done by both the original 
poster or triagers or even automatically by the tracker itself.

-- 

Terry Jan Reedy