Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-26 Thread Lennart Regebro
On Mon, Jul 27, 2015 at 4:04 AM, Tim Peters 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

Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-26 Thread Lennart Regebro
On Mon, Jul 27, 2015 at 12:15 AM, Paul Moore 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

Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-26 Thread Tim Peters
[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 in

Re: [Python-Dev] Burning down the backlog.

2015-07-26 Thread Nick Coghlan
On 27 July 2015 at 11:37, R. David Murray 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

Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-26 Thread Tim Peters
[Paul Moore ] > 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

Re: [Python-Dev] Burning down the backlog.

2015-07-26 Thread R. David Murray
On Sun, 26 Jul 2015 22:59:51 +0100, Paul Moore wrote: > On 26 July 2015 at 16:39, Berker Peksağ 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/triagin

Re: [Python-Dev] Burning down the backlog.

2015-07-26 Thread Mark Lawrence
On 26/07/2015 22:59, Paul Moore wrote: On 26 July 2015 at 16:39, Berker Peksağ 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

Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-26 Thread Paul Moore
On 26 July 2015 at 16:33, Nick Coghlan 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. >

Re: [Python-Dev] Burning down the backlog.

2015-07-26 Thread Paul Moore
On 26 July 2015 at 16:39, Berker Peksağ 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

Re: [Python-Dev] Burning down the backlog.

2015-07-26 Thread Alexander Belopolsky
On Sun, Jul 26, 2015 at 11:39 AM, Berker Peksağ 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-gu

Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-26 Thread Alexander Belopolsky
On Sun, Jul 26, 2015 at 11:33 AM, Nick Coghlan 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 inte

Re: [Python-Dev] PyCapsule_Import semantics, relative imports, module names etc.

2015-07-26 Thread Nick Coghlan
On 27 July 2015 at 01:21, Larry Hastings 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. F

Re: [Python-Dev] Burning down the backlog.

2015-07-26 Thread Berker Peksağ
On Sun, Jul 26, 2015 at 2:58 PM, Paul Moore wrote: > On 25 July 2015 at 20:28, Robert Collins 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&%40

Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-26 Thread Nick Coghlan
On 26 July 2015 at 18:12, Lennart Regebro wrote: > On Sun, Jul 26, 2015 at 8:05 AM, Tim Peters 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 conv

Re: [Python-Dev] PyCapsule_Import semantics, relative imports, module names etc.

2015-07-26 Thread Larry Hastings
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

Re: [Python-Dev] [RELEASED] Python 3.5.0b4 is now available

2015-07-26 Thread Stephane Wirtel
\o/ > On 26 juil. 2015, at 4:37 PM, Larry Hastings 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-Dev] [RELEASED] Python 3.5.0b4 is now available

2015-07-26 Thread Larry Hastings
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 "featu

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

2015-07-26 Thread Mark Shannon
> On 26 July 2015 at 10:41 Ronald Oussoren wrote: > > > > > On 26 Jul 2015, at 09:14, Ronald Oussoren wrote: > > > > > >> On 25 Jul 2015, at 17:39, Mark Shannon >> > wrote: > >> > >> Hi, > >> > >> On 22/07/15 09:25, Ronald Oussoren wrote:> Hi, > >>> > >>> Another s

Re: [Python-Dev] Burning down the backlog.

2015-07-26 Thread Paul Moore
On 25 July 2015 at 20:28, Robert Collins 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=searc

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

2015-07-26 Thread Ronald Oussoren
> On 26 Jul 2015, at 09:14, Ronald Oussoren wrote: > > >> On 25 Jul 2015, at 17:39, Mark Shannon > > 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 P

Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-26 Thread Lennart Regebro
On Sun, Jul 26, 2015 at 8:05 AM, Tim Peters 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

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

2015-07-26 Thread Ronald Oussoren
> On 25 Jul 2015, at 17:39, Mark Shannon 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