[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2015-09-04 - 2015-09-11)
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:
  open5076 (+19)
  closed 31753 (+49)
  total  36829 (+68)

Open issues with patches: 2258 


Issues opened (46)
==

#8232: webbrowser.open incomplete on Windows
http://bugs.python.org/issue8232  reopened by larry

#24199: Idle: remove idlelib.idlever.py and its use in About dialog
http://bugs.python.org/issue24199  reopened by terry.reedy

#25001: Make --nowindows argument to regrtest propagate when running w
http://bugs.python.org/issue25001  opened by brett.cannon

#25002: Deprecate asyncore/asynchat
http://bugs.python.org/issue25002  opened by gvanrossum

#25003: os.urandom() should call getrandom(2) not getentropy(2) on Sol
http://bugs.python.org/issue25003  opened by jbeck

#25006: List pybind11 binding generator
http://bugs.python.org/issue25006  opened by wenzel

#25007: Add support of copy protocol to zlib compressors and decompres
http://bugs.python.org/issue25007  opened by serhiy.storchaka

#25008: Deprecate smtpd
http://bugs.python.org/issue25008  opened by brett.cannon

#25011: Smarter rl complete: hide private and special names
http://bugs.python.org/issue25011  opened by serhiy.storchaka

#25012: pathlib should allow converting to absolute paths without reso
http://bugs.python.org/issue25012  opened by mu_mind

#25013: run_pdb() in test_pdb.py always returns stderr as None
http://bugs.python.org/issue25013  opened by xdegaye

#25015: Idle: scroll Text faster with mouse wheel
http://bugs.python.org/issue25015  opened by terry.reedy

#25017: htmllib deprecated: Which library to use? Missing sane default
http://bugs.python.org/issue25017  opened by guettli

#25020: IDLE - centralize ui policies and small utilities
http://bugs.python.org/issue25020  opened by markroseman

#25021: product_setstate() Out-of-bounds Read
http://bugs.python.org/issue25021  opened by JohnLeitch

#25023: time.strftime('%a'), ValueError: embedded null byte, in ko loc
http://bugs.python.org/issue25023  opened by sy LEE

#25024: Allow passing "delete=False" to TemporaryDirectory
http://bugs.python.org/issue25024  opened by Antony.Lee

#25026: (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type 
http://bugs.python.org/issue25026  opened by koobs

#25027: Python 3.5.0rc3 on Windows can not load more than 127 C extens
http://bugs.python.org/issue25027  opened by cgohlke

#25031: IDLE - file list improvements
http://bugs.python.org/issue25031  opened by markroseman

#25032: IDLE - same menubar across application
http://bugs.python.org/issue25032  opened by markroseman

#25034: string.Formatter accepts empty fields but displays wrong when 
http://bugs.python.org/issue25034  opened by anthon

#25035: Getter/setter for argparse keys
http://bugs.python.org/issue25035  opened by Sworddragon

#25036: IDLE - infrastructure changes so editors don't assume they're 
http://bugs.python.org/issue25036  opened by markroseman

#25039: Docs: Link to Stackless Python in Design and History FAQ secti
http://bugs.python.org/issue25039  opened by Winterflower

#25040: xml.sax.make_parser makes bad use of parser_list argument defa
http://bugs.python.org/issue25040  opened by Gautier Portet

#25041: document AF_PACKET socket address format
http://bugs.python.org/issue25041  opened by Tim.Tisdall

#25042: Create an "embedding SDK" distribution?
http://bugs.python.org/issue25042  opened by paul.moore

#25043: document socket constants for Bluetooth
http://bugs.python.org/issue25043  opened by Tim.Tisdall

#25044: bring BTPROTO_SCO inline with other Bluetooth protocols
http://bugs.python.org/issue25044  opened by Tim.Tisdall

#25045: smtplib throws exception TypeError: readline()
http://bugs.python.org/issue25045  opened by phlambotte

#25047: xml.etree.ElementTree encoding declaration should be capital (
http://bugs.python.org/issue25047  opened by zimeon

#25049: Strange behavior under doctest: staticmethods have different _
http://bugs.python.org/issue25049  opened by jneb

#25050: windows installer does not allow 32 and 64 installs side by si
http://bugs.python.org/issue25050  opened by Adam.Groszer

#25053: Possible race condition in Pool
http://bugs.python.org/issue25053  opened by Stanislaw Izaak Pitucha

#25054: Capturing start of line '^'
http://bugs.python.org/issue25054  opened by Alcolo Alcolo

#25056: no support for Bluetooth LE in socket
http://bugs.python.org/issue25056  opened by Tim.Tisdall

#25057: Make parameter of io.base to be positional and keyword
http://bugs.python.org/issue25057  opened by introom

#25058: Right square bracket argparse metavar
http://bugs.python.org/issue25058  opened by cortopy

#25059: Mistake in input-output tutorial regarding print() seperator
http://bugs.python.org/issue25059  opened by Saimadhav.Heblikar

#25061: Add native enum support for argparse
http://

[Python-Dev] Partial function application

[Herbert Kruitbosch]

Dear developers,

First of all, I'm a programmer for a data science company and I recently
graduated.

That being said, I have wondered why python does not have syntactical
support (like syntax sugar) for partial function application. I think
partial function application is a powerful concept, but also think that
the implementation in functional.partial as described here:

https://www.python.org/dev/peps/pep-0309/

is too verbose. Moreover I think the functional programming paradigm is
a powerful one in general, especially when implemented as much as
possible in an iterative language as python avoiding the typical
problems we have with purely functional languages like Haskell. An plea
for this concept is that, for example, small pieces Haskell (or
functional) code can be extremely expressive and concise.

I was wondering if there are considerations for including partial
function application syntactically. I very often find myself writing
statements as:

data_sorted = sort(data, key = lambda x: x[0])

where I would prefer

data_sorted = sort(data, key = #1[0])

where the #1 is similar to the one used in Mathematica for the same
purpose. That is, an expression with #1  becomes an anonymous function
which takes one argument, and, obviously, if a #n is included, the
anonymous function takes n arguments.

Notice that #1[0] does not seem like partial function application,
however it is if you (C++'isly) assume that the deference operation []
is a function dereference(subscriptable, subscript).

Obviously, I am only expecting that you get these type of suggestions
all the time and that there is a good change you do not find it adequate
for many reasons, for example keeping the language compact. I this case,
I would also like to hear so.

Yours sincerely and thank you in advance, Herbert
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

[Brett Cannon]

Since everyone seems happy with the proposal to keep deprecated modules in
Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP
4. If no one objects I will commit the change and then update formatter and
imp to say they will be removed once Python 2.7 is no longer supported.



--- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700
+++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700
@@ -2,7 +2,7 @@
 Title: Deprecation of Standard Modules
 Version: $Revision$
 Last-Modified: $Date$
-Author: Martin von Löwis 
+Author: Brett Cannon , Martin von Löwis <
mar...@v.loewis.de>
 Status: Active
 Type: Process
 Content-Type: text/x-rst
@@ -50,6 +50,15 @@
 releases that immediately follows the deprecation; later releases may
 ship without the deprecated modules.

+For modules existing in both Python 2.7 and Python 3.5
+--
+In order to facilitate writing code that works in both Python 2 & 3
+simultaneously, any module deprecated from Python 3.5 onwards that
+also exists in Python 2.7 will not be removed from the standard
+library until Python 2.7 is no longer supported. Exempted from this
+is any module in the idlelib package as well as any exceptions
+granted by the Python development team.
+

 Procedure for declaring a module undeprecated
 =
@@ -258,12 +267,16 @@
Remove from 2.7
 Documentation: None

+Module name:   imp
+Rationale: Replaced by the importlib module.
+Date:  2013-02-10
+Documentation: Deprecated as of Python 3.4.
+
 Module name:   formatter
 Rationale: Lack of use in the community, no tests to keep
code working.
-Documentation: Deprecated as of Python 3.4 by raising
-   PendingDeprecationWarning. Slated for removal in
-   Python 3.6.
+Date:  2013-08-12
+Documentation: Deprecated as of Python 3.4.


 Deprecation of modules removed in Python 3.0



On Tue, 8 Sep 2015 at 09:59 Brett Cannon  wrote:

> There are two discussions going on in the issue tracker about deprecating
> some modules and it has led to the inevitable discussion of Python 2/3
> compatibility (I'm not even going to bother mentioning the issue #s as this
> thread is not about the modules specifically but module deprecation in
> general). Because I'm tired of rehashing the same discussion every time a
> module deprecation comes up I would like to make an official decision that
> we can follow any time we decide to deprecate a module.
>
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module and
> remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation
>
> I'm personally in the #2 camp. I want users to be fully aware that the
> module in question is not being updated and possibly not even getting
> non-critical bugfixes, but it's still there in Python 3 in order to make
> sure that you can have code which straddles Python 2 & 3 more easily.
>
> I don't like #1 because when the module exists in python 2.7 as it makes
> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
> deprecated isn't going to kill us, especially if we make it clear the code
> only exists for transitioning purposes and you very well may have to work
> around any bugs you come across (and yes, this means changing my stance for
> the formatter module's deprecation).
>
> I don't like #3 because if you have an API memorized or you copied some
> code you found online you very well may not realize a module is deprecated.
> It's not difficult to silence a deprecation warning and you can make it so
> that even if you use -Werror your deprecated module imports continue to
> work without throwing an exception while all other deprecations do throw an
> exception.
>
> Whatever decision we come to I will update PEP 4 and then personally go
> through the various deprecated modules in Python 3.6 and tweak them as
> necessary to follow whatever policy we come up with.
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

[Guido van Rossum]

+1.

The language seems a bit ambiguous: "deprecated from 3.5 onward" -- what if
a module was deprecated in 3.3 or 3.4 but still present in 3.5? I assume
those are also included, but the language makes it possible to interpret
this as applying only to modules that were first marked as deprecated in
3.5...

On Fri, Sep 11, 2015 at 10:42 AM, Brett Cannon  wrote:

> Since everyone seems happy with the proposal to keep deprecated modules in
> Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP
> 4. If no one objects I will commit the change and then update formatter and
> imp to say they will be removed once Python 2.7 is no longer supported.
>
>
>
> --- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700
> +++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700
> @@ -2,7 +2,7 @@
>  Title: Deprecation of Standard Modules
>  Version: $Revision$
>  Last-Modified: $Date$
> -Author: Martin von Löwis 
> +Author: Brett Cannon , Martin von Löwis <
> mar...@v.loewis.de>
>  Status: Active
>  Type: Process
>  Content-Type: text/x-rst
> @@ -50,6 +50,15 @@
>  releases that immediately follows the deprecation; later releases may
>  ship without the deprecated modules.
>
> +For modules existing in both Python 2.7 and Python 3.5
> +--
> +In order to facilitate writing code that works in both Python 2 & 3
> +simultaneously, any module deprecated from Python 3.5 onwards that
> +also exists in Python 2.7 will not be removed from the standard
> +library until Python 2.7 is no longer supported. Exempted from this
> +is any module in the idlelib package as well as any exceptions
> +granted by the Python development team.
> +
>
>  Procedure for declaring a module undeprecated
>  =
> @@ -258,12 +267,16 @@
> Remove from 2.7
>  Documentation: None
>
> +Module name:   imp
> +Rationale: Replaced by the importlib module.
> +Date:  2013-02-10
> +Documentation: Deprecated as of Python 3.4.
> +
>  Module name:   formatter
>  Rationale: Lack of use in the community, no tests to keep
> code working.
> -Documentation: Deprecated as of Python 3.4 by raising
> -   PendingDeprecationWarning. Slated for removal in
> -   Python 3.6.
> +Date:  2013-08-12
> +Documentation: Deprecated as of Python 3.4.
>
>
>  Deprecation of modules removed in Python 3.0
>
>
>
> On Tue, 8 Sep 2015 at 09:59 Brett Cannon  wrote:
>
>> There are two discussions going on in the issue tracker about deprecating
>> some modules and it has led to the inevitable discussion of Python 2/3
>> compatibility (I'm not even going to bother mentioning the issue #s as this
>> thread is not about the modules specifically but module deprecation in
>> general). Because I'm tired of rehashing the same discussion every time a
>> module deprecation comes up I would like to make an official decision that
>> we can follow any time we decide to deprecate a module.
>>
>> The approaches to module deprecation I have seen are:
>> 1. Nothing changes to the deprecation process; you deprecate a module and
>> remove it in one to two releases
>> 2. Deprecate the module but with no plans for removal until Python 2.7
>> reaches its EOL (I have been calling this Python 4)
>> 3. Document the deprecation but no actual code deprecation
>>
>> I'm personally in the #2 camp. I want users to be fully aware that the
>> module in question is not being updated and possibly not even getting
>> non-critical bugfixes, but it's still there in Python 3 in order to make
>> sure that you can have code which straddles Python 2 & 3 more easily.
>>
>> I don't like #1 because when the module exists in python 2.7 as it makes
>> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
>> deprecated isn't going to kill us, especially if we make it clear the code
>> only exists for transitioning purposes and you very well may have to work
>> around any bugs you come across (and yes, this means changing my stance for
>> the formatter module's deprecation).
>>
>> I don't like #3 because if you have an API memorized or you copied some
>> code you found online you very well may not realize a module is deprecated.
>> It's not difficult to silence a deprecation warning and you can make it so
>> that even if you use -Werror your deprecated module imports continue to
>> work without throwing an exception while all other deprecations do throw an
>> exception.
>>
>> Whatever decision we come to I will update PEP 4 and then personally go
>> through the various deprecated modules in Python 3.6 and tweak them as
>> necessary to follow whatever policy we come up with.
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/gu

Re: [Python-Dev] Partial function application

[Brett Cannon]

On Fri, 11 Sep 2015 at 10:41 Herbert Kruitbosch <
python-...@herbertkruitbosch.com> wrote:

> Dear developers,
>
> First of all, I'm a programmer for a data science company and I recently
> graduated.
>
> That being said, I have wondered why python does not have syntactical
> support (like syntax sugar) for partial function application. I think
> partial function application is a powerful concept, but also think that the
> implementation in functional.partial as described here:
>
> https://www.python.org/dev/peps/pep-0309/
>
> is too verbose. Moreover I think the functional programming paradigm is a
> powerful one in general, especially when implemented as much as possible in
> an iterative language as python avoiding the typical problems we have with
> purely functional languages like Haskell. An plea for this concept is that,
> for example, small pieces Haskell (or functional) code can be extremely
> expressive and concise.
>
> I was wondering if there are considerations for including partial function
> application syntactically. I very often find myself writing statements as:
>
> data_sorted = sort(data, key = lambda x: x[0])
>

To start off, I wouldn't write it that way, but this way:

data_sorted - sort(data, key=operator.itemgetter(0))


>
> where I would prefer
>
> data_sorted = sort(data, key = #1[0])
>

That syntax won't work because `#` is used to start a comment and there is
no way to disambiguate that in the grammar.


>
> where the #1 is similar to the one used in Mathematica for the same
> purpose. That is, an expression with #1 becomes an anonymous function which
> takes one argument, and, obviously, if a #n is included, the
> anonymous function takes n arguments.
>
> Notice that #1[0] does not seem like partial function application, however
> it is if you (C++'isly) assume that the deference operation [] is a
> function dereference(subscriptable, subscript).
>
> Obviously, I am only expecting that you get these type of suggestions all
> the time and that there is a good change you do not find it adequate for
> many reasons, for example keeping the language compact. I this case, I
> would also like to hear so.
>

In my code the few times I want partial function applications I have found
the functions in the operator module meet that need, else functools.partial
or a quickly written closure do the trick. I don't think dedicated syntax
is warranted when those other options already exist  to meet the same need.


>
> Yours sincerely and thank you in advance,
>

Thanks for the suggestion!

-Brett


> Herbert
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

[Brett Cannon]

Tweaked wording that clearly state the mere existence in both Python 2.7
and 3.5 means the module won't be  removed until Python 2.7 is EOL'ed:

In order to facilitate writing code that works in both Python 2 & 3
simultaneously, any module that exists in both Python 3.5 and
Python 2.7 will not be removed from the standard library until
Python 2.7 is no longer supported as specified by PEP 373. Exempted
from this rule is any module in the idlelib package as well as any
exceptions granted by the Python development team.

On Fri, 11 Sep 2015 at 10:47 Guido van Rossum  wrote:

> +1.
>
> The language seems a bit ambiguous: "deprecated from 3.5 onward" -- what
> if a module was deprecated in 3.3 or 3.4 but still present in 3.5? I assume
> those are also included, but the language makes it possible to interpret
> this as applying only to modules that were first marked as deprecated in
> 3.5...
>
> On Fri, Sep 11, 2015 at 10:42 AM, Brett Cannon  wrote:
>
>> Since everyone seems happy with the proposal to keep deprecated modules
>> in Python 3 until Python 2.7 reaches EOL, here are my proposed changes to
>> PEP 4. If no one objects I will commit the change and then update formatter
>> and imp to say they will be removed once Python 2.7 is no longer supported.
>>
>>
>>
>> --- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700
>> +++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700
>> @@ -2,7 +2,7 @@
>>  Title: Deprecation of Standard Modules
>>  Version: $Revision$
>>  Last-Modified: $Date$
>> -Author: Martin von Löwis 
>> +Author: Brett Cannon , Martin von Löwis <
>> mar...@v.loewis.de>
>>  Status: Active
>>  Type: Process
>>  Content-Type: text/x-rst
>> @@ -50,6 +50,15 @@
>>  releases that immediately follows the deprecation; later releases may
>>  ship without the deprecated modules.
>>
>> +For modules existing in both Python 2.7 and Python 3.5
>> +--
>> +In order to facilitate writing code that works in both Python 2 & 3
>> +simultaneously, any module deprecated from Python 3.5 onwards that
>> +also exists in Python 2.7 will not be removed from the standard
>> +library until Python 2.7 is no longer supported. Exempted from this
>> +is any module in the idlelib package as well as any exceptions
>> +granted by the Python development team.
>> +
>>
>>  Procedure for declaring a module undeprecated
>>  =
>> @@ -258,12 +267,16 @@
>> Remove from 2.7
>>  Documentation: None
>>
>> +Module name:   imp
>> +Rationale: Replaced by the importlib module.
>> +Date:  2013-02-10
>> +Documentation: Deprecated as of Python 3.4.
>> +
>>  Module name:   formatter
>>  Rationale: Lack of use in the community, no tests to keep
>> code working.
>> -Documentation: Deprecated as of Python 3.4 by raising
>> -   PendingDeprecationWarning. Slated for removal in
>> -   Python 3.6.
>> +Date:  2013-08-12
>> +Documentation: Deprecated as of Python 3.4.
>>
>>
>>  Deprecation of modules removed in Python 3.0
>>
>>
>>
>> On Tue, 8 Sep 2015 at 09:59 Brett Cannon  wrote:
>>
>>> There are two discussions going on in the issue tracker about
>>> deprecating some modules and it has led to the inevitable discussion of
>>> Python 2/3 compatibility (I'm not even going to bother mentioning the issue
>>> #s as this thread is not about the modules specifically but module
>>> deprecation in general). Because I'm tired of rehashing the same discussion
>>> every time a module deprecation comes up I would like to make an official
>>> decision that we can follow any time we decide to deprecate a module.
>>>
>>> The approaches to module deprecation I have seen are:
>>> 1. Nothing changes to the deprecation process; you deprecate a module
>>> and remove it in one to two releases
>>> 2. Deprecate the module but with no plans for removal until Python 2.7
>>> reaches its EOL (I have been calling this Python 4)
>>> 3. Document the deprecation but no actual code deprecation
>>>
>>> I'm personally in the #2 camp. I want users to be fully aware that the
>>> module in question is not being updated and possibly not even getting
>>> non-critical bugfixes, but it's still there in Python 3 in order to make
>>> sure that you can have code which straddles Python 2 & 3 more easily.
>>>
>>> I don't like #1 because when the module exists in python 2.7 as it makes
>>> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
>>> deprecated isn't going to kill us, especially if we make it clear the code
>>> only exists for transitioning purposes and you very well may have to work
>>> around any bugs you come across (and yes, this means changing my stance for
>>> the formatter module's deprecation).
>>>
>>> I don't like #3 because if you have an API memorized or you copied some
>>> code you found online you very well may not realize a module is deprecate

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Tue, Sep 8, 2015 at 8:27 PM, Guido van Rossum  wrote:

> Now if only PEP 495 could be as easy... :-)
>

I think we nailed the hard issues there.   The next update will have a
restored hash invariant and == that satisfies all three axioms of
equivalency.  I am not making a better progress because I am debating with
myself about the fate of < and > comparisons.  Cross-zone comparisons
strike in full force there as well because two times ordered in UTC may
appear in the opposite order in the local timezone where the clock is moved
back.  Note that I saved the hash invariant and the transitivity of == at
the expense of the loss of trichotomy in comparisons (we will have pairs of
aware datetimes that are neither equal nor < nor >).  I don't think we need
to change anything with < and > comparisons, but I am trying to come up
with the arguments that will at least be convincing to myself.  (I suspect
that if I am not the only one who worries about this, the other such people
can be counted by the values of the fold flag. :-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Partial function application

[Herbert Kruitbosch]

> On Fri, 11 Sep 2015 at 10:41 Herbert Kruitbosch 
>  wrote:
> __
>> data_sorted = sort(data, key = #1[0])
>
> That syntax won't work because `#` is used to start a comment and
> there is no way to disambiguate that in the grammar.

Obviously :) The #-syntax is used by Mathematica, which is why I used it
here. As you stated, it is not adequate for python3. You could imagine a
$n or ***n syntax. I'm not in any way well informed on the python3
syntax, nor what would be aesthetically appealing and readable.

>> where the #1 is similar to the one used in Mathematica for the same
>> purpose. That is, an expression with #1  becomes an anonymous
>> function which takes one argument, and, obviously, if a #n is
>> included, the anonymous function takes n arguments.
>>
>> Notice that #1[0] does not seem like partial function application,
>> however it is if you (C++'isly) assume that the deference operation
>> [] is a function dereference(subscriptable, subscript).
>>
>> Obviously, I am only expecting that you get these type of suggestions
>> all the time and that there is a good change you do not find it
>> adequate for many reasons, for example keeping the language compact.
>> I this case, I would also like to hear so.
>
> In my code the few times I want partial function applications I have
> found the functions in the operator module meet that need, else
> functools.partial or a quickly written closure do the trick. I don't
> think dedicated syntax is warranted when those other options already
> exist  to meet the same need.

I would guess it depends on personal preference. And like you stated,
there are many clear and intuitive workarounds. I never got to the point
where functools.partial and operator.* became part of my coding
equipment, and I  would adore this feature. I'm very curious if there
are more people on my team, but am also interested to hear about
opinions against such a feature.

> Thanks for the suggestion!

No problem, and thank you for reading it :)

Herbert
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Partial function application

[Terry Reedy]

On 9/11/2015 3:56 AM, Herbert Kruitbosch wrote:



I was wondering if there are considerations for including partial
function application syntactically. I very often find myself writing
statements as:
data_sorted = sort(data, key = lambda x: x[0])
where I would prefer
data_sorted = sort(data, key = #1[0])
where the #1 is similar to the one used in Mathematica for the same
purpose. That is, an expression with #1 becomes an anonymous function
which takes one argument, and, obviously, if a #n is included, the
anonymous function takes n arguments.


For future reference, ideas like this belong on the python-list or 
python-ideas list. Pydev is more for discussion of policy, concrete 
issues for the next releases, and approval ideas that have been fully 
fleshed out in the form of a PEP.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

[Raymond Hettinger]

> On Sep 11, 2015, at 1:57 PM, Brett Cannon  wrote:
> 
> In order to facilitate writing code that works in both Python 2 & 3
> simultaneously, any module that exists in both Python 3.5 and
> Python 2.7 will not be removed from the standard library until
> Python 2.7 is no longer supported as specified by PEP 373. Exempted
> from this rule is any module in the idlelib package as well as any
> exceptions granted by the Python development team.

I think that reads nicely.  It makes a clear contract with developers
letting them know that we will avoid making their life unnecessarily difficult.


Raymond


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Terry Reedy]

On 9/11/2015 2:36 PM, Alexander Belopolsky wrote:


On Tue, Sep 8, 2015 at 8:27 PM, Guido van Rossum mailto:gu...@python.org>> wrote:

Now if only PEP 495 could be as easy... :-)


I think we nailed the hard issues there.   The next update will have a
restored hash invariant and == that satisfies all three axioms of
equivalency.


You are trying to sanely deal with politically mandated insanity.
I think it essential that you not introduce mathematical insanity, but 
whatever you do will be less than completely satisfactory.



 I am not making a better progress because I am debating
with myself about the fate of < and > comparisons.


Both should not be true for the same pair ;-)

> Cross-zone

comparisons strike in full force there as well because two times ordered
in UTC may appear in the opposite order in the local timezone where the
clock is moved back.


Comparison of absolute Newtonion time, represented by UTC, and local 
'clock face' relative time with political hacks, are different concepts. 
 If I get up at 8:00 AM (in Delaware, USA) and you get up at 8:01 
wherever you are, which of us got up earlier?  It depends on what 
'earlier' means in the context and purpose of the question. Are we 
asking about wakeup discipline, or email exchange?


Pick whichever you and whoever consider to be most useful.  Presuming 
that one can convert to UTC before comparision, I suspect the local 
version.



 Note that I saved the hash invariant and the
transitivity of == at the expense of the loss of trichotomy in
comparisons (we will have pairs of aware datetimes that are neither
equal nor < nor >).


That is the nature of partial orders.


 I don't think we need to change anything with < and
 > comparisons,


I am guessing that the comparisons are currently local.


but I am trying to come up with the arguments that will
at least be convincing to myself.  (I suspect that if I am not the only
one who worries about this, the other such people can be counted by the
values of the fold flag. :-)


Good luck ;-)

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 6:45 PM, Terry Reedy  wrote:

>
>> I think we nailed the hard issues there.   The next update will have a
>> restored hash invariant and == that satisfies all three axioms of
>> equivalency.
>>
>
> You are trying to sanely deal with politically mandated insanity.
> I think it essential that you not introduce mathematical insanity, but
> whatever you do will be less than completely satisfactory.


The insanity I am dealing with now is specific to Python datetime which
wisely blocks any binary operation that involves naive and aware datetimes,
but allows comparisons and subtractions of datetimes with different
timezones.  This is not an unusual situation given a limited supply of
binary operators, Python has to reuse them in less than ideal ways. For
example,

>>> a = 'a'
>>> b = 'b'
>>> c = 5
>>> (a + b) * c == a * c + b * c
False

is less than ideal if you hold the distributive law of arithmetic sacred.
Similarly, '-' is reused in datetime for two different operation: if s and
t are datetimes with the same tzinfo, s - t tells you how far to move hands
on the local clock to arrive at s when you start at t.  This is clearly a
very useful operation that forms the basis of everything else that we do in
datetime.  Note that for this operation, it does not matter what kind of
time your clock is showing or whether it is running at all.  We are not
asking how long one needs to wait to see s after t was shown.  We are just
asking how far to turn the knob on the back of the clock.  This operation
does not make sense when s and t have different tzinfos, so in this case a
'-' is reused for a different operation.  This operation is much more
involved.  We require an existence of some universal time (UTC) and a rule
to convert s and t to that time and define s - t as s.astimezone(UTC) -
t.timezone(UTC).  In the later expression '-' is taken in the "turns of the
knob" sense because the operands are in the same timezone (UTC).

Clearly, when we "abuse" the mathematical notation in this way, we cannot
expect mathematical identities to hold and it is easy to find for example,
aware datetimes u, t, and s such that (t - u) - (s - u) ≠ t - s.

Deciding when it is ok to sacrifice mathematical purity for practical
convenience is an art, not a science.  The case of interzone datetime
arithmetic is a borderline case.  I would much rather let users decide what
they want: s.astimezone(t.tzinfo) - t, s - t.astimezone(s.tzinfo) or
 s.astimezone(UTC) - t.astimezone(UTC) and not assume that s - t "clearly"
means the last of the three choices.  But the decision to allow interzone t
- s was made long time ago and it is a PEP 495 goal to change that.


>
>  I am not making a better progress because I am debating
>> with myself about the fate of < and > comparisons.
>>
>
> Both should not be true for the same pair ;-)


I'll give you that.  No worries.

>
>
> > Cross-zone
>
>> comparisons strike in full force there as well because two times ordered
>> in UTC may appear in the opposite order in the local timezone where the
>> clock is moved back.
>>
>
> Comparison of absolute Newtonion time, represented by UTC, and local
> 'clock face' relative time with political hacks, are different concepts.
> If I get up at 8:00 AM (in Delaware, USA) and you get up at 8:01 wherever
> you are, which of us got up earlier?  It depends on what 'earlier' means
> in the context and purpose of the question. Are we asking about wakeup
> discipline, or email exchange?
>

There is no "earlier" or "later".  There are "lesser" and "greater" which
are already defined for all pairs of aware datetimes.  PEP 495 doubles the
set of possible datetimes and they don't fit in one straight line anymore.
The whole point of PEP 495 is to introduce a "fold" in the timeline.


> Pick whichever you and whoever consider to be most useful.  Presuming that
> one can convert to UTC before comparision, I suspect the local version.


It is more delicate than that.  Are you willing to accept a possibility of
an infinite loop if you run a binary search for a UTC time in an ordered
list of local times?  We tolerate that with numbers, but you only have this
risk when you have a "nan" in your list.  I don't think the new PEP 495
datetimes will be nearly as bad as floating point NaNs: at least datetime
== will still be reflexive and transitive unlike  floating point ==.  Still
I am not ready to say that we have solved all the puzzles yet.  But we are
close.


>
>  Note that I saved the hash invariant and the
>> transitivity of == at the expense of the loss of trichotomy in
>> comparisons (we will have pairs of aware datetimes that are neither
>> equal nor < nor >).
>>
>
> That is the nature of partial orders.


Yes, but are we willing to accept that datetimes have only partial order?
And in Python 3 we consider comparison between unorderable objects to be an
error instead of silently returning False.  I am strongly against allowing
exceptions in astimezone(), ==, or ha

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Random832]

Alexander Belopolsky  writes:
> There is no "earlier" or "later". There are "lesser" and "greater"
> which are already defined for all pairs of aware datetimes. PEP 495
> doubles the set of possible datetimes

That depends on what you mean by "possible".

> and they don't fit in one
> straight line anymore. The whole point of PEP 495 is to introduce a
> "fold" in the timeline.

That doesn't make sense. Within a given timezone, any given moment of
UTC time (which is a straight line [shut up, no leap seconds here]) maps
to only one local time. The point of PEP 495 seems to be to eliminate
the cases where two UTC moments map to the same aware local time.

Out of curiosity, can "fold" ever be any value other than 0 or 1? I
don't know if there are any real-world examples (doubt it), but I could
easily contrive a timezone definition that had three of a particular
clock time.

> Yes, but are we willing to accept that datetimes have only partial
> order?

I apparently haven't been following the discussion closely enough to
understand how this can possibly be the case outside cases I assumed it
already was (naive vs aware comparisons being invalid).

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Glenn Linderman]

On 9/11/2015 5:40 PM, Alexander Belopolsky wrote:


The insanity I am dealing with now

...
But the decision to allow interzone t - s was made long time ago and 
it is a PEP 495 goal to change that.


The first few paragraphs you wrote, which I elided, are a great 
explanation of why things work in ways that might be unexpected, and by 
including in the descriptions other things that might be unexpected, it 
helps people realize that the need to understand what the operators 
really mean, when applied to classes, rather than numbers.  Of course, 
even floating point number operations and integer division only 
approximate mathematical reality, if you are looking for more examples.


But the beginning phrase about "insanity" should probably be elided in 
documentation, yet the body could very well be appropriate for tutorial 
documentation, even if not reference documentation, although I'd not 
object to finding it there.


The last phrase, about it being a PEP 495 goal to change that, might be 
true, but if it changes it, then it would be a confusing and backward 
incompatible change.




Yes, but are we willing to accept that datetimes have only partial order?


That's what the politicians gave us. These are datetime objects, not 
mathematical numbers.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 8:56 PM, Random832  wrote:

> Alexander Belopolsky  writes:
> > There is no "earlier" or "later". There are "lesser" and "greater"
> > which are already defined for all pairs of aware datetimes. PEP 495
> > doubles the set of possible datetimes
>
> That depends on what you mean by "possible".
>

What exactly depends on the meaning of  "possible"?  In this context
"possible" means "can appear in a Python program."



> > and they don't fit in one
> > straight line anymore. The whole point of PEP 495 is to introduce a
> > "fold" in the timeline.
>
> That doesn't make sense. Within a given timezone, any given moment of
> UTC time (which is a straight line [shut up, no leap seconds here]) maps
> to only one local time. The point of PEP 495 seems to be to eliminate
> the cases where two UTC moments map to the same aware local time.
>

Yes, but it does that at the cost of introducing the second local "01:30"
which is "later" than the first "01:40" while "obviously" (and according to
the current datetime rules)  "01:30" < "01:40".

>
> Out of curiosity, can "fold" ever be any value other than 0 or 1?
>

Thankfully, no.

>
> > Yes, but are we willing to accept that datetimes have only partial
> > order?
>
> I apparently haven't been following the discussion closely enough to
> understand how this can possibly be the case outside cases I assumed it
> already was (naive vs aware comparisons being invalid).


Local times that fall in the spring-forward gap cannot be ordered interzone
even without PEP 495.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman 
wrote:
[Alexander Belopolsky]

> But the decision to allow interzone t - s was made long time ago and it is
> a PEP 495 goal to change that.
>
> The last phrase, about it being a PEP 495 goal to change that, might be
> true, but if it changes it, then it would be a confusing and backward
> incompatible change.


Oops, a Freudian slip.  It is *not* a PEP 495 goal to change that.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman 
wrote:

> That's what the politicians gave us. These are datetime objects, not
> mathematical numbers.


That's an argument for not defining mathematical operations like <, > or -
on them, but you cannot deny the convenience of having those.  Besides,
datetime objects are mathematical numbers as long as you only deal with one
timezone or restrict yourself to naive instances.  The problem with
interzone subtraction, for example, is that we start with nice (not so
little) integers and define an operation that is effectively op(x, y) =
f(x) - g(y) where f and g are arbitrary functions under the control of
the politicians.
It is convenient to equate op with subtraction and if f and g are simple
shifts, it is a subtraction, but in general it is not.  This is the root of
the problem, but datetime objects are still as close to mathematical
numbers as Python ints.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Glenn Linderman]

On 9/11/2015 6:39 PM, Alexander Belopolsky wrote:
On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman 
mailto:v+pyt...@g.nevcal.com>> wrote:


That's what the politicians gave us. These are datetime objects,
not mathematical numbers.


That's an argument for not defining mathematical operations like <, > 
or - on them, but you cannot deny the convenience of having those. 


It wasn't intended to argue for not defining the operations, just 
intended to justify that it is partial ordering... if the associated 
timezone implements daylight saving.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Random832]

Alexander Belopolsky  writes:
> Yes, but it does that at the cost of introducing the second local
> "01:30" which is "later" than the first "01:40" while "obviously" (and
> according to the current datetime rules) "01:30" < "01:40".

The current datetime rules, such as they are, as far as I am aware,
order all aware datetimes (except spring-forward) according to the UTC
moment they map to. I'm not sure what the benefit of changing this
invariant is.

> Out of curiosity, can "fold" ever be any value other than 0 or 1?
>
> Thankfully, no.

What happens, then, if I were to define a timezone with three local
times from the same date? None may exist now, but the IANA data format
can certainly represent this case. Should we be talking about adding an
explicit offset member?  (Ultimately, this "fold=1 means the second one"
notion is a novel invention, and including the offset either explicitly
a la ISO8601, or implicitly by writing EST/EDT, is not)

>
> > Yes, but are we willing to accept that datetimes have only
> partial
> > order?
> 
> I apparently haven't been following the discussion closely enough
> to
> understand how this can possibly be the case outside cases I
> assumed it
> already was (naive vs aware comparisons being invalid).
>
> Local times that fall in the spring-forward gap cannot be ordered
> interzone even without PEP 495.

Hmm. If these have to be allowed to exist, then...

What about ordering times according to, notionally, a tuple of (UTC
timestamp of transition, number of "fake" seconds "after" the
transition) for a spring-forward time?

Also, can someone explain why this:
>>> ET = pytz.timezone("America/New_York")
>>> datetime.strftime(datetime.now(ET) + timedelta(days=90),
...   "%Y%m%d %H%M%S %Z %z")
returns '20151210 214526 EDT -0400'

I don't know if I expected 214526 or 204526, but I certainly expected
the timezone info to say EST -0500. If EST and EDT are apparently two
distinct tzinfo values, then what exactly would a value landing near the
"fall back" transition have given for fold? fold=1 but EDT?

And if EST and EDT are, against all rationality, distinct tzinfo values,
then when exactly can fold ever actually be 1, and why is it needed?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Guido van Rossum]

I think we're getting into python-ideas territory here...

--Guido (on mobile)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 9:51 PM, Glenn Linderman 
wrote:

> It wasn't intended to argue for not defining the operations, just intended
> to justify that it is partial ordering...


It is not even that.  Note that even partial ordering still requires
transitivity of <=, but we don't have that in datetime:

>>> from datetime import *
>>> from datetimetester import Eastern
>>> UTC = timezone.utc
>>> a = datetime(2002, 4, 7, 1, 40, tzinfo=Eastern)
>>> b = datetime(2002, 4, 7, 2, tzinfo=Eastern)
>>> c = datetime(2002, 4, 7, 6, 20, tzinfo=UTC)
>>> a <= b <= c
True
>>> a <= c
False

The above session is run in the currently released python.  The Eastern
timezone implementation is imported from the CPython test suit.

The fact that transitivity of <= is already broken gives me little comfort
because pretty much everything involving "problem times" is currently
broken and users expect that.  PEP 495, however, is expected to fix the
issues with the problem times and not just replace one broken behavior with
another.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 10:00 PM, Random832  wrote:
>
> The current datetime rules, such as they are, as far as I am aware,
> order all aware datetimes (except spring-forward) according to the UTC
> moment they map to.


No.  See the library reference manual: "If both comparands are aware, and
have the same tzinfo attribute, the common tzinfo attribute is ignored and
the base datetimes are compared." <
https://docs.python.org/3/library/datetime.html>

The reasons for this have been explained at length in the recent
Datetime-SIG discussions.  Please check the archives if you are interested:
.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 10:00 PM, Random832  wrote:

> And if EST and EDT are, against all rationality, distinct tzinfo values,
> then when exactly can fold ever actually be 1, and why is it needed?
>

No, fold is not needed in the case of fixed offset timezones.  For an
obvious reason: there are no folds or gaps in those.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 10:22 PM, Guido van Rossum 
wrote:

> I think we're getting into python-ideas territory here...


Well, a violation of transitivity of <= in the current CPython
implementation may be considered a bug by some.  This makes this discussion
appropriate for python-dev.  We could discuss this on Datetime-SIG, but I
think the question is more broad than just datetime.

When is it appropriate for Python operators to violate various mathematical
identities?  We know that some violations are unavoidable when you try to
represent real numbers in finite size objects, but when you effectively
deal with a subset of integers, what identities are important and what can
be ignored for practical reasons?

Intuitively, I feel that the hash invariant and the reflexivity and
transitivity of == are more important than say distribution law for + and
*, but where does it leave the transitivity of <=?  Is it as important as
== being an equivalence, or it's a nice to have like the distribution law?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Tim Peters]

[Random832 ]
> ...
>
> Also, can someone explain why this:
> >>> ET = pytz.timezone("America/New_York")
> >>> datetime.strftime(datetime.now(ET) + timedelta(days=90),
> ...   "%Y%m%d %H%M%S %Z %z")
> returns '20151210 214526 EDT -0400'

pytz lives in its own world here, and only uses eternally-fixed-offset
zones.  It's a magnificent hack to get around the lack of an "is_dst
bit" in datetime's design, and effectively records that bit via
_which_ fixed-offset zone it attaches to the datetime.

The tradeoff is that, to get results you expect, you _need_ to invoke
pytz's .normalize() after doing any arithmetic (and pytz's doc are
very clear about this - do read them).  That's required for pytz to
realize the tzinfo in the result is no longer appropriate for the
result's date and time, so it can (if needed) replace it with a
different fixed-offset tzinfo.


> I don't know if I expected 214526 or 204526, but I certainly expected
> the timezone info to say EST -0500. If EST and EDT are apparently two
> distinct tzinfo values,

In pytz, they are.  This isn't how tzinfos were _intended_ to work in
Python, but pytz does create an interesting set of tradeoffs.

> then what exactly would a value landing near the
> "fall back" transition have given for fold? fold=1 but EDT?

As above, pytz is in its own world here.  It doesn't need `fold`
because it has its own hack for disambiguating local times in a fold.


> And if EST and EDT are, against all rationality, distinct tzinfo values,
> then when exactly can fold ever actually be 1, and why is it needed?

pytz doesn't need it.  "Hybrid" tzinfos do, because there is currently
no way outside of pytz to disambiguate local times in a fold.

So, short course:  if you ask questions about pytz's behavior, you're
asking question about pytz, not  really about Python's datetime.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[MRAB]

On 2015-09-12 02:23, Alexander Belopolsky wrote:


On Fri, Sep 11, 2015 at 8:56 PM, Random832 mailto:random...@fastmail.com>> wrote:

Alexander Belopolsky mailto:alexander.belopol...@gmail.com>> writes:
> There is no "earlier" or "later". There are "lesser" and "greater"
> which are already defined for all pairs of aware datetimes. PEP 495
> doubles the set of possible datetimes

That depends on what you mean by "possible".

What exactly depends on the meaning of  "possible"?  In this context
"possible" means "can appear in a Python program."

> and they don't fit in one
> straight line anymore. The whole point of PEP 495 is to introduce a
> "fold" in the timeline.

That doesn't make sense. Within a given timezone, any given moment of
UTC time (which is a straight line [shut up, no leap seconds here]) maps
to only one local time. The point of PEP 495 seems to be to eliminate
the cases where two UTC moments map to the same aware local time.

Yes, but it does that at the cost of introducing the second local
"01:30" which is "later" than the first "01:40" while "obviously" (and
according to the current datetime rules)  "01:30" < "01:40".

Out of curiosity, can "fold" ever be any value other than 0 or 1?

Thankfully, no.


[snip]
What would happen if it's decided to stay on DST and then, later on, to
reintroduce DST?

Or what would happen in the case of "British Double Summer Time" (go
forward twice in the spring and backward twice in the autumn)?

https://en.wikipedia.org/wiki/British_Summer_Time

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 11:03 PM, Tim Peters  wrote:

> > then what exactly would a value landing near the
> > "fall back" transition have given for fold? fold=1 but EDT?
>
> As above, pytz is in its own world here.  It doesn't need `fold`
> because it has its own hack for disambiguating local times in a fold.


But I consider it as an imperative that pytz's hack continues to work in
the post-PEP 495 world.  Fortunately, this is not a hard requirement to
satisfy.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Fri, Sep 11, 2015 at 11:07 PM, MRAB  wrote:

> What would happen if it's decided to stay on DST and then, later on, to
> reintroduce DST?
>

No problem as long as you don't move the clock back x minutes and then
decide that you did not move it back enough and move it again before x
minutes have passed.  Fortunately, no government in the world can pass a
new law in an hour.  More so in an hour between 01:00 and 02:00 AM. :-)

An interesting possibility is a fold straddling a leap second, but
hopefully those who pass the timekeeping laws have learned about the leap
seconds by now.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Random832]

MRAB  writes:
> What would happen if it's decided to stay on DST and then, later on, to
> reintroduce DST?
>
> Or what would happen in the case of "British Double Summer Time" (go
> forward twice in the spring and backward twice in the autumn)?
>
> https://en.wikipedia.org/wiki/British_Summer_Time

"backward twice" could theoretically do it, if you literally went back
an hour, waited an hour (or any nonzero amount less than two hours), and
went back an hour again, rather than just going back two hours. I don't
know if any real-life authorities have ever done such a thing; that's
why I asked.

You could also have them if you had a "timezone" representing the
real-time local time of someone who traveled across timezone boundaries
multiple times in close succession, rather than the time of a
geographical place.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Terry Reedy]

On 9/11/2015 8:40 PM, Alexander Belopolsky wrote:


The insanity I am dealing with now is specific to Python datetime which
wisely blocks any binary operation that involves naive and aware
datetimes, but allows comparisons and subtractions of datetimes with
different timezones.  This is not an unusual situation given a limited
supply of binary operators, Python has to reuse them in less than ideal
ways. For example,

 >>> a = 'a'
 >>> b = 'b'
 >>> c = 5
 >>> (a + b) * c == a * c + b * c
False

is less than ideal if you hold the distributive law of arithmetic
sacred.


In mathematics, algebra is, put simply, the study of binary operations. 
None of the laws for particular operations on particular sets is 
'sacred'.  They are simply facts. Or possibly axioms whose consequences 
are to be explored.  A mathematician has no problem with 'a'+'b' != 
'b'+'a'.  After closure, associativity is the most 'basic' operation, 
but non-associative operations are studied.


The equality relation, mapping pairs of members of a set to True or 
False is a different matter.  Being an equivalence relation is 
fundamental to both normal logic, algebraic proofs, and the definition 
of sets.  It is also required for the 'proper' operation of Python's 
sets. (Lets leave nans out of the discussion).



 Similarly, '-' is reused in datetime for two different
operation: if s and t are datetimes with the same tzinfo, s - t tells
you how far to move hands on the local clock to arrive at s when you
start at t.  This is clearly a very useful operation that forms the
basis of everything else that we do in datetime.  Note that for this
operation, it does not matter what kind of time your clock is showing or
whether it is running at all.  We are not asking how long one needs to
wait to see s after t was shown.  We are just asking how far to turn the
knob on the back of the clock.  This operation does not make sense when
s and t have different tzinfos, so in this case a '-' is reused for a
different operation.  This operation is much more involved.  We require
an existence of some universal time (UTC) and a rule to convert s and t
to that time and define s - t as s.astimezone(UTC) - t.timezone(UTC).
In the later expression '-' is taken in the "turns of the knob" sense
because the operands are in the same timezone (UTC).


Datetime members, are rather unusual beasts. They are triples consisting 
of a member of a discrete sequence (with some odd gaps), a tz tag, and a 
0/1 fold tag. The tz tags divide datetimes into equivalence classes. 
The '-' operation is also unusual in being defined differently for pairs 
in the same or different equivalence classes.



Clearly, when we "abuse" the mathematical notation in this way,


Mathematicians wildly overload operater/relation symbols. '=' is the 
only one I can think of with more-or-less universal properties.



we cannot expect mathematical identities


which are context dependent


to hold


in a different context.  Right.


and it is easy to find for
example, aware datetimes u, t, and s such that (t - u) - (s - u) ≠ t - s.


Datetime '-' (subtraction) should be documented as an unusual overloaded 
use which does not have the normal properties that the naive might expect.


Within the constraint on '=', there are two choices for designing an 
operation.
1. Define the operation the way you want, and live with the consequent 
properties (or absence of properties).
2. Decide the properties you require, and live with the consequent 
restriction on the definition.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

[Serhiy Storchaka]

On 08.09.15 19:59, Brett Cannon wrote:

The approaches to module deprecation I have seen are:
1. Nothing changes to the deprecation process; you deprecate a module
and remove it in one to two releases
2. Deprecate the module but with no plans for removal until Python 2.7
reaches its EOL (I have been calling this Python 4)
3. Document the deprecation but no actual code deprecation


Of course #2 LGTM. What if at the same time add Py3k warning in next 2.7 
bugfix release?



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com