Re: [Python-Dev] How far to go with user-friendliness

[Alexander]

> 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  wrote:
> On Wed, 15 Jul 2015 07:40:57 +1200
> Robert Collins  wrote:
>
>> On 15 July 2015 at 07:39, Paul Moore  wrote:
>> > On 14 July 2015 at 20:27, Robert Collins  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@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/xr.lists%40gmail.com
___
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 3121, 384 Refactoring Issues

[Alexander Belopolsky]

On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence 
wrote:

> I'm just curious as to why there are 54 open issues after both of these
> PEPs have been accepted and 384 is listed as finished.  Did we hit some
> unforeseen technical problem which stalled development?


I tried to bring some sanity to that effort by opening a "meta issue":

http://bugs.python.org/issue15787

My enthusiasm, however, vanished after I reviewed the refactoring for the
datetime module:

http://bugs.python.org/issue15390

My main objections are to following PEP 384
 (Stable ABI) within stdlib
modules.  I see little benefit for the stdlib (which is shipped fresh with
every new version of Python) from following those guidelines.
___
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 3121, 384 Refactoring Issues

[Alexander Belopolsky]

On Sat, Jul 12, 2014 at 11:19 AM, Nick Coghlan  wrote:

> The main downside of "do as we say, not as we do" in this case is that we
> miss out on the feedback loop of what the stable ABI is like to *use*.


I good start for improving the situation would be to  convert the extension
module templates that we ship with the Python source:

http://bugs.python.org/issue15848 (xxsubtype module)
http://bugs.python.org/issue15849 (xx module)
___
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 3121, 384 Refactoring Issues

[Alexander Belopolsky]

On Mon, Jul 14, 2014 at 11:41 AM, Brett Cannon  wrote:

> So maybe we should re-examine the patches and accept the bits that clean
> up init/finalization and leave out any ABI-related changes.


This is precisely what I suggested two years ago.

http://bugs.python.org/issue15390#msg170249

I am not against ABI-related changes in principle, but I think these
changes should be carefully considered on a case by case basis and not
applied wholesale.
___
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] sum(...) limitation

[Alexander Belopolsky]

On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano  wrote:

> String concatenation with + is an attractive
> nuisance for many people, including some who actually know better but
> nevertheless do it. Also, for reasons I don't understand, many people
> dislike or cannot remember to use ''.join.
>

Since sum() already treats strings as a special case, why can't it simply
call (an equivalent of) ''.join itself instead of telling the user to do
it?  It does not matter why "many people dislike or cannot remember to use
''.join" - if this is a fact - it should be considered by language
implementors.
___
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] sum(...) limitation

[Alexander Belopolsky]

On Sat, Aug 2, 2014 at 11:06 AM, Stefan Behnel  wrote:

> I don't think sum(strings) is beautiful enough


sum(strings) is more beautiful than ''.join(strings) in my view, but
unfortunately it does not work even for lists because the initial value
defaults to 0.

sum(strings, '') and ''.join(strings) are equally ugly and non-obvious
because they require an empty string.  Empty containers are an advanced
concept and it is unfortunate that a simple job of concatenating a list of
(non-empty!) strings exposes the user to it.
___
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] Surely "nullable" is a reasonable name?

[Alexander Belopolsky]

On Mon, Aug 4, 2014 at 12:57 PM, Ethan Furman  wrote:

> 'allow_none' is definitely clearer.


I disagree. Unlike "nullable", "allow_none" does not tell me what happens
on the C side when I pass in None.  If the receiving type is PyObject*,
either NULL or Py_None is a valid choice.
___
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] Surely "nullable" is a reasonable name?

[Alexander Belopolsky]

On Mon, Aug 4, 2014 at 1:53 PM, Antoine Pitrou  wrote:

> I disagree. Unlike "nullable", "allow_none" does not tell me what
>> happens on the C side when I pass in None.  If the receiving type is
>> PyObject*, either NULL or Py_None is a valid choice.
>>
>
> But here the receiving type can be an int.


We cannot "allow None" when the receiving type is C int.  In this case, we
need a way to implement "nullable int" type in C.  We can use int * or a
pair of int and _Bool or anything else.  Whatever the implementation, the
concept that is implemented is "nullable int."  The advantage of using the
term "nullable" is that it is language and implementation neutral.
___
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] pathlib handling of trailing slash (Issue #21039)

[Alexander Belopolsky]

On Wed, Aug 6, 2014 at 8:11 PM, Antoine Pitrou  wrote:

> Am I overlooking other cases?


There are many interfaces where trailing slash is significant.  For
example, rsync uses trailing slash on the target directory to avoid
creating an additional directory level at the destination.  Loosing it when
passing path strings through pathlib.Path() may be a source of bugs.
___
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] pathlib handling of trailing slash (Issue #21039)

[Alexander Belopolsky]

On Fri, Aug 8, 2014 at 8:27 AM, Paul Moore  wrote:

> I had a use case where I wanted to allow a config file to contain
> "path: foo" to create a file called foo, and "path: foo/" to create a
> directory. It was a shortcut for specifying an explicit "directory:
> true" parameter as well.
>

Here is my use case: I have a database application that can save a table in
a variety of formats based on the supplied file name.  For example,
save('t.csv', t) saves in CSV text format while save('t', t)  saves in the
default binary format.  In addition, it supports "splayed" format where a
table is saved in multiple files across a directory - one file per column.
 The native database save function chooses this format when file name ends
with a slash: save('t/', t).   I would like to make the save() function in
Python that works like this, but takes pathlib.Path instances instead of
str, but in the current version, I cannot supply 't/' as a Path instance.
___
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] sum(...) limitation

[Alexander Belopolsky]

On Fri, Aug 8, 2014 at 8:56 PM, Ethan Furman  wrote:

> I don't use sum at all, or at least very rarely, and it still irritates me.


You are not alone.  When I see sum([a, b, c]), I think it is a + b + c, but
in Python it is 0 + a + b + c.  If we had a "join" operator for strings
that is different form + - then sure, I would not try to use sum to join
strings, but we don't.  I have always thought that sum(x) is just a
shorthand for reduce(operator.add, x), but again it is not so in Python.
 While "sum should only be used for numbers,"  it turns out it is not a
good choice for floats - use math.fsum.  While "strings are blocked because
sum is slow," numpy arrays with millions of elements are not.  And try to
explain to someone that sum(x) is bad on a numpy array, but abs(x) is fine.
 Why have builtin sum at all if its use comes with so many caveats?
___
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] sum(...) limitation

[Alexander Belopolsky]

On Sat, Aug 9, 2014 at 3:08 AM, Stephen J. Turnbull 
wrote:

> All the suggestions
> I've seen so far are (IMHO, YMMV) just as ugly as the present
> situation.
>

What is ugly about allowing strings?  CPython certainly has a way to to
make sum(x, '') at least as efficient as y='';for in in x; y+= x is now.
 What is ugly about making sum([a, b, ..]) be equivalent to a + b + .. so
that non-empty lists of arbitrary types can be "summed"?  What is ugly
about harmonizing sum(x) and reduce(operator.add, x) behaviors?
___
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] sum(...) limitation

[Alexander Belopolsky]

On Sat, Aug 9, 2014 at 2:02 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

> y='';for in in x; y+= x


Should have been

y=''
for i in x; y += i
___
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] sum(...) limitation

[Alexander Belopolsky]

On Sat, Aug 9, 2014 at 1:08 AM, Steven D'Aprano  wrote:

> We wouldn't be having
> these interminable arguments about using sum() to concatenate strings
> (and lists, and tuples) if the & operator was used for concatenation and
> + was only used for numeric addition.
>

But we would probably have a similar discussion about all(). :-)

Use of + is consistent with the use of * for repetition.  What would you
use use for repetition if you use & instead?

Compare, for example

s + ' ' * (n - len(s))

and

s & ' ' * (n - len(s))

Which one is clearer?

It is sum() that need to be fixed, not +.  Not having sum([a, b])
equivalent to a + b for any a, b pair is hard to justify.
___
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] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc

[Alexander Belopolsky]

On Sat, Aug 9, 2014 at 8:44 PM, Steven D'Aprano  wrote:

> It is certainly required when writing code that will behave the same in
> version 2 and 3
>

This is not true.  An alternative is to put

__metaclass__ = type

at the top of your module to make all classes in your module new-style in
python2.
___
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] sum(...) limitation

[Alexander Belopolsky]

On Mon, Aug 11, 2014 at 8:19 PM, Nick Coghlan  wrote:

> Teaching users the difference between linear time operations and quadratic
> ones isn't about purity, it's about passing along a fundamental principle
> of algorithm scalability.


I would understand if this was done in reduce(operator.add, ..) which
indeed spells out the choice of an algorithm, but why sum() should be O(N)
for numbers and O(N**2) for containers?  Would a python implementation
that, for example, optimizes away 0's in sum(list_of_numbers) be
non-compliant with some fundamental principle?
___
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] Real-world use of Counter

[Alexander Belopolsky]

On Wed, Nov 5, 2014 at 2:47 PM, R. David Murray 
wrote:

> As I said on the issue, there is no reason I can see to add extra code
> just to turn an AttributeError into a TypeError.  The AttributeError
> works just fine in letting you know your input type didn't work.
>

+1

Unlike ValueError or LookupError, TypeError and AttributeError indicate a
logical problem with the code rather than an issue with the user input.
>From the programmer perspective, any code that catches and mutates
exceptions is a nuisance.
___
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 479: Change StopIteration handling inside generators

[Alexander Belopolsky]

On Wed, Nov 19, 2014 at 3:10 PM, Guido van Rossum  wrote:

> There's a new PEP proposing to change how to treat StopIteration bubbling
> up out of a generator frame (not caused by a return from the frame). The
> proposal is to replace such a StopIteration with a RuntimeError (chained to
> the original StopIteration), so that only *returning* from a generator (or
> falling off the end) causes the iteration to terminate.


I think the PEP should also specify what will happen if the generator's
__next__() method is called again after RuntimeError is handled.  The two
choices are:

1. Raise StopIteration (current behavior for all exceptions).
2. Raise RuntimeError (may be impossible without gi_frame).

I think choice 1 is implied by the PEP.
___
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] LTTng-UST support for CPython

[Alexander Belopolsky]

On Mon, Dec 1, 2014 at 5:48 PM, Francis Giraldeau <
francis.girald...@gmail.com> wrote:

> - On the C-API side: I did a horrible and silly function show_type() to
> run every Py*_Check() to determine the type of a PyObject *. What would be
> the sane way to do that?


Questions like this are better asked on a users' forum, but you can get the
type name from a python object as follows:

Py_TYPE(obj)->tp_name
___
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] datetime nanosecond support (ctd?)

[Alexander Belopolsky]

On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec  wrote:

> I wonder if the datetime module is really the right location, that has
> constructor(year, month, day, ..., second, microsecond) - with 0 no millis. adding 0 quite right.


We can make nanosecond a keyword-only argument, so that

time(1, 2, 3, nanosecond=123456789) -> 01:02:03.123456789

and

time(1, 2, 3, 4, nanosecond=123456789) -> error

Users will probably be encouraged to avoid positional form when specifying
time to subsecond precision.  I would say  time(1, 2, 3, microsecond=4) is
clearer than time(1, 2, 3, 4) anyways.

Another option is to allow float for the "second" argument:

time(1, 2, 3.123456789) -> 01:02:03.123456789
___
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] Hi, I am new to this board and have a question

[Alexander Belopolsky]

On Wed, Feb 4, 2015 at 6:18 PM, Jianhua Zhou 
wrote:

> The necessary bits to build these optional modules were not found:
>
> _bz2  _lzma _ssl
>
> _tkinter  zlib
>
>
>
> ..
>
>
>
> So what package name should I gave to download the additional source to
> build the optional module?
>
>
>

Questions like this are really better asked on Red Hat forums, but off the
top of my head, you need *-devel packages such as zlib-devel,
openssl-devel, etc.  It is usually easy to figure out from yum search.
___
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] subclassing builtin data structures

[Alexander Belopolsky]

On Thu, Feb 12, 2015 at 7:55 PM, Guido van Rossum  wrote:

> the problem is that the base class (e.g. int) doesn't know how to
> construct an instance of the subclass -- there is no reason (in general)
> why the signature of a subclass constructor should match the base class
> constructor, and it often doesn't.


I hear this explanation every time we have a discussion about subclassing
of datetime types and I don't really buy this.

Consider this simple subclass:

>>> from datetime import date
>>> class Date(date):
... pass
...

What do you think Date.today() should return?  Since I did not override
todat() in my Date class, it has to be datetime.date instance, right?

However:

>>> Date.today().__class__


Wait, Date "doesn't know how to construct an instance of the subclass .."

Indeed, if I change the constructor signature, Date.today() won't work:

>>> class Date(date):
... def __init__(self, extra):
... pass
...
>>> Date.today()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __init__() takes exactly 2 arguments (4 given)

In my view, a constructor is no different from any other method.  If the
designers of the subclass decided to change the signature in an
incompatible way, they should either override all methods that create new
objects or live with tracebacks.

On the other hand, if all I want in my Date class is a better __format__
method, I am forced to override all operators or have my objects silently
degrade in situations like this:

>>> d = Date.today()
>>> d.__class__

>>> d += timedelta(1)
>>> d.__class__


Having binary operations return subclass instances is not without
precedent.  For example, in numpy,

>>> from numpy import ndarray
>>> class Array(ndarray):
... pass
...
>>> a = Array(1)
>>> a[0] = 42
>>> a
Array([ 42.])
>>> a + a
Array([ 84.])

I believe numpy had this behavior since types became subclassable in
Python, so this design is definitely not a "no-go."
___
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] subclassing builtin data structures

[Alexander Belopolsky]

On Thu, Feb 12, 2015 at 11:01 PM, Guido van Rossum  wrote:

>
>> 2) always use the type of self when creating new instances
>> ..
>>cons:
>>  - if constructor signatures change, must override all methods which
>>create new objects
>>
>
> Con for #2 is a showstopper. Forget about it.
>

Sorry if I am missing something obvious, but I still don't understand why
the same logic does not apply to class methods that create new instances:

>>> from datetime import *
>>> date.today()
datetime.date(2015, 2, 13)
>>> datetime.today()
datetime.datetime(2015, 2, 13, 11, 37, 23, 678680)
>>> class Date(date):
... pass
...
>>> Date.today()
Date(2015, 2, 13)

(I actually find datetime.today() returning a datetime rather than a date a
questionable design decision, but probably the datetime type should not
have been a subclass of the date to begin with.)

Are there any date subclasses in the wild that don't accept year, month,
day in the constructor?  If you create such a class, wouldn't you want to
override __add__ and friends anyways?  We already know that you will have
to override today().
___
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] subclassing builtin data structures

[Alexander Belopolsky]

On Fri, Feb 13, 2015 at 12:35 PM, Guido van Rossum  wrote:

> IIUC you're proposing that the base class should *try* to construct an
> instance of the subclass by calling the type with an argument, and fail if
> it doesn't work. But that makes the whole thing brittle in the light of
> changes to the subclass constructor. Also, what should the argument be? The
> only answer I can think of is an instance of the base class.


No.  The arguments should be whatever arguments are appropriate for the
baseclass's __init__ or __new__.  In the case of datetime.date that would
be year, month, day.

Note that the original pure python prototype of the datetime module had
date.__add__ and friends call self.__class__(year, month, day).
Unfortunately, it looks like the original sandbox did not survive the the
hg conversion, so I cannot provide a link to the relevant history.
___
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] subclassing builtin data structures

[Alexander Belopolsky]

On Fri, Feb 13, 2015 at 1:11 PM, Guido van Rossum  wrote:

>
>
>> Note that the original pure python prototype of the datetime module had
>> date.__add__ and friends call self.__class__(year, month, day).
>> Unfortunately, it looks like the original sandbox did not survive the the
>> hg conversion, so I cannot provide a link to the relevant history.
>>
>
> FWIW you're wrong when you claim that "a constructor is no different from
> any other method". Someone else should probably explain this (it's an old
> argument that's been thoroughly settled).
>

Well, the best answer I've got in the past [1] was "ask on python-dev since
Guido called the operator overriding expectation." :-)

[1] http://bugs.python.org/issue2267#msg108060
___
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] subclassing builtin data structures

[Alexander Belopolsky]

On Fri, Feb 13, 2015 at 1:19 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>>
>> FWIW you're wrong when you claim that "a constructor is no different
from any other method". Someone else should probably explain this (it's an
old argument that's been thoroughly settled).
>
>
> Well, the best answer I've got in the past [1] was "ask on python-dev
since Guido called the operator overriding expectation." :-)


And let me repost this bit of history [1]:

Here is the annotated pre-r82065 code:

 39876 gvanrossum def __add__(self, other):
 39876 gvanrossum if isinstance(other, timedelta):
 39928 gvanrossum return self.__class__(self.__days +
other.__days,
 39876 gvanrossum   self.__seconds +
other.__seconds,
 39876 gvanrossum   self.__microseconds +
other.__microseconds)
 40207tim_one return NotImplemented
 39876 gvanrossum


[1] http://bugs.python.org/issue2267#msg125979
___
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 471 (scandir): Poll to choose the implementation (full C or C+Python)

[Alexander Belopolsky]

On Fri, Feb 13, 2015 at 5:07 AM, Victor Stinner 
wrote:

> Now I see 3 choices:
>
> - take the full C implementation, because it's much faster (at least
> 3.4x faster!)
> - reject the whole PEP 471 (not nice), because it adds too much code
> for a minor speedup (not true on Windows: up to 44x faster!)
> - take the C+Python implementation, because maintenance matters more
> than performances (only 1.3x faster, sorry)
>
> => IMO the best option is to take the C implementation. What do you think?
>

+1
___
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] subclassing builtin data structures

[Alexander Belopolsky]

On Fri, Feb 13, 2015 at 4:44 PM, Neil Girdhar  wrote:

> Interesting:
> http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
>

Let me humbly conjecture that the people who wrote the top answers have
background in less capable languages than Python.

Not every language allows you to call self.__class__().  In the languages
that don't you can get away with incompatible constructor signatures.

However, let me try to focus the discussion on a specific issue before we
go deep into OOP theory.

With python's standard datetime.date we have:

>>> from datetime import *
>>> class Date(date):
... pass
...
>>> Date.today()
Date(2015, 2, 13)
>>> Date.fromordinal(1)
Date(1, 1, 1)

Both .today() and .fromordinal(1) will break in a subclass that redefines
__new__ as follows:

>>> class Date2(date):
... def __new__(cls, ymd):
... return date.__new__(cls, *ymd)
...
>>> Date2.today()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __new__() takes 2 positional arguments but 4 were given
>>> Date2.fromordinal(1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __new__() takes 2 positional arguments but 4 were given

Why is this acceptable, but we have to sacrifice the convenience of having
Date + timedelta
return Date to make it work  with Date2:

>>> Date2((1,1,1)) + timedelta(1)
datetime.date(1, 1, 2)
___
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] subclassing builtin data structures

[Alexander Belopolsky]

On Sat, Feb 14, 2015 at 7:23 AM, Steven D'Aprano 
wrote:

> Why can't int, str, list, tuple etc. be more like datetime?


They are.  In all these types, class methods call subclass constructors but
instance methods don't.

>>> class Int(int):
... pass
...
>>> Int.from_bytes(bytes([1,2,3]), 'big')
66051
>>> type(_)


>>> Int(1) + 1
2
>>> type(_)


In the case of int, there is a good reason for this behavior - bool.  In
python, we want True + True == 2.  In numpy, where binary operations
preserve subclasses, you have

>>> import numpy
>>> numpy.bool_(1) + numpy.bool_(1)
True

I don't see a similar argument for the date class, however.  Given
date.{to|from}ordinal(), date subclasses are pretty much bound to have
timedelta addition satisfy (d + td).toordinal() == d.toordinal() +
td.days.  Any other definition would be fighting the baseclass design and
would be better implemented via containment.
___
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] subclassing builtin data structures

[Alexander Belopolsky]

On Sat, Feb 14, 2015 at 2:36 PM, Georg Brandl  wrote:

> > In the case of int, there is a good reason for this behavior - bool.  In
> python,
> > we want True + True == 2.  In numpy, where binary operations preserve
> > subclasses, you have
> >
>  import numpy
>  numpy.bool_(1) + numpy.bool_(1)
> > True
>
> I don't think numpy.bool_ subclasses some class like numpy.int_.


And  numpy.bool_ subclasses don't preserve type in addition:

>>> import numpy
>>> class Bool(numpy.bool_):
... pass
...
>>> numpy.bool_.mro()
[, , ]
>>> Bool(1) + Bool(1)
True
>>> type(_)


So there goes my theory. :-)

I think all these examples just highlight the need for a clear guidance
when self.__class__() can be called in base classes to construct instances
of derived classes.

Apparently numpy has it both ways.  One way for scalars (see above) and the
other for arrays:

>>> class Array(numpy.ndarray):
... pass
...
>>> a = Array(1)
>>> a[0] = 1
>>> a+a
Array([ 2.])
___
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] easy_install ?

[Alexander Belopolsky]

On Tue, Feb 24, 2015 at 4:24 PM, Daniel Holth  wrote:
>
> That might mostly do what you want, since tox could install any
> additional test requirements based on its configuration.


Does "that" refer to using tests_require=['tox'] as I described below? This
means using easy_install implicitly and being exposed to easy_install
bugs.  Note that my attempts to avoid easy_install so far led to dependency
hell starting from the need to install virtualenv.  Unlike setuptools, pip
does not seem to be able to install dependencies in a temporary directory.
It wants a full-blown venv tree.

>
>
> On Tue, Feb 24, 2015 at 4:21 PM, Alexander Belopolsky
>  wrote:
> >
> > On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth  wrote:
> >>
> >> > Is there a recommended way to invoke pip from setup.py?  When I
specify
> >> > "tests_require=" and run "python setup.py test", the requirements get
> >> > installed using setuptools' easy_install function.
> >>
> >> The solution is to not do that. A substitute is to specify your test
> >> requirements in a [test] extra and install them with pip or to run
> >> tests with tox. This gives control of the installer back to the user
> >> instead of the setup.py author.
> >
> >
> > Isn't this a chicken and egg problem?  I currently have
> >
> > tests_require=['tox'],
> >
> > and this is exactly what tox recommends:
> >
> >
https://testrun.org/tox/latest/example/basic.html#integration-with-setuptools-distribute-test-commands
> >
> >
> > Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6.
This
> > is still a very common server configuration.  What is the recommended
way to
> > bootstrap tox in such environment?
> >
___
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] version of freshly built 2.7 python

[Alexander Walters]

Are you building from mercurial or a source tarball?


On 4/2/2015 21:29, Ethan Furman wrote:

I just built the latest version of Python 2.7 on my development machine -- or 
so I thought.  When I invoke it, I get:

   Python 2.7.6+ (2.7:1beb3e0507fa, Apr  2 2015, 17:57:53)

Why am I not seeing 2.7.9?

--
~Ethan~
___
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/tritium-list%40sdamon.com


___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 8, 2015 at 11:18 AM, Lennart Regebro  wrote:

> === Stdlib option 2: A datetime _is_dst flag ===
>
> By having a flag on the datetime instance that says "this is in DST or not"
> the timezone implementation can be kept simpler.
>

I floated this idea [1] back in the days when we discussed the
 datetime.timestamp() method.
The attraction was that such API would be familiar to the users of POSIX
mktime and struct tm,
but the history have shown that these POSIX APIs were insufficient in many
situations and
struct tm was extended by may libraries to include non-standard tm_gmtoff
and tm_zone fields.

With datetime, we also have a problem that POSIX APIs don't have to deal
with: local time
arithmetics.  What is t + timedelta(1) when t falls on the day before DST
change?  How would
you set the isdst flag in the result?

[1] http://bugs.python.org/issue2736#msg124237
___
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] Aware datetime from naive local time Was: Status on PEP-431 Timezones

[Alexander Belopolsky]

On Fri, Apr 10, 2015 at 6:38 AM, Nick Coghlan  wrote:

> It actually took me a long time to understand that the "isdst" flag in
> this context related to the following chain of reasoning:
>
> 1. Due to various reasons, local time offsets relative to UTC may change,
> thus repeating certain subsets of local time
> 2. Repeated local times usually relate to winding clocks back an hour at
> the end of a DST period
> 3. "isdst=True" thus refers to "before the local time change winds the
> clocks back", while "isdst=False" refers to *after* the clocks are wound
> back
>
As Alexander says, you can reduce the amount of assumed knowledge needed to
> understand the API by focusing on the ambiguity resolution directly without
> assuming that the *reason* for the ambiguity is "end of DST period".
>
This is an excellent summary of my original post.  (It is in fact better
than the post itself which I therefore did not include in the quote.)  For
the mathematically inclined, I can reformulate the problem as follows.  For
any given geographical location, loc, and a moment in time t expressed
as UTC time, one can tell what time was shown on a "local clock-tower."
This defines a function  wall(loc, t).   This function is a piece-wise
linear function which may have regular or irregular discontinuities.
Because of these discontinuities, an equation wall(loc, t) = lt may have 0,
1
or 2 solutions.

The DST switchovers are an example of regular discontinuities.  In most
locations, they follow a somewhat predictable pattern with two
discontinuities per year.  Irregular discontinuities happen in locations
with activist governments and don't follow any general rules.

For most world locations past discontinuities are fairly well documented
for at least a century and future changes are published with at least 6
months lead time.

>From a pedagogical point of view, having a separate API that returned 0, 1,
> or 2 results for a local time lookup could thus help make it clear that
> local time to absolute time conversions are effectively a database lookup
> problem, and that timezone offset changes (whether historical or cyclical)
> mean that the mapping isn't 1:1 - some expressible local times never
> actually happen, while others happen more than once.
>
The downside of this API is that naively written code is prone to crashes.
Someone unaware of the invalid local times and not caring about the choice
between ambiguities may write code like

t = utc_times_from_local(lt)[0]

which may work fine for many years before someone gets an IndexError and a
backtrace in her server log.


> For the normal APIs, NonExistentTimeError would then correspond with the
> case where the record lookup API returned no results, while the suggested
> "which" index would handle the two results case without assuming the
> repeated local time was specifically due to the end of a DST period.
>

The NonExistentTimeError has a similar problem as an API returning an empty
list.  Seeing NonExistentTimeError in a server log is not a big improvement
over seeing an IndexError.

Moreover, a program that rejects invalid times on input, but stores them
for a long time may see its database silently corrupted after a zoneinfo
update.

Now it is time to make specific proposal.  I would like to extend
datetime.astimezone() method to work on naive datetime instances.  Such
instances will be assumed to be in local time and discontinuities will be
handled as follows:


1. wall(t) == lt has a single solution.  This is the trivial case and
lt.astimezone(utc) and lt.astimezone(utc, which=i)  for i=0,1 should return
that solution.

2. wall(t) == lt has two solutions t1 and t2 such that t1 < t2. In this
case lt.astimezone(utc) == lt.astimezone(utc, which=0) == t1 and
 lt.astimezone(utc, which=1) == t2.

3. wall(t) == lt has no solution.  This happens when there is UTC time t0
such that wall(t0) < lt and wall(t0+epsilon) > lt (a positive discontinuity
at time t0). In this case lt.astimezone(utc) should return t0 + lt -
wall(t0).  I.e., we ignore the discontinuity and extend wall(t) linearly
past t0.  Obviously, in this case the invariant wall(lt.astimezone(utc)) ==
lt won't hold.   The "which" flag should be handled as follows:
 lt.astimezone(utc) == lt.astimezone(utc, which=0) and lt.astimezone(utc,
which=0) == t0 + lt - wall(t0+eps).

With the proposed features in place, one can use the naive code

t =  lt.astimezone(utc)

and get predictable behavior in all cases and no crashes.

A more sophisticated program can be written like this:

t1 = lt.astimezone(utc, which=0)
t2 = lt.astimezone(utc, which=1)
if t1 == t2:
t = t1
elif t2 > t1:
# ask the user to pick between t1 and t2 or raise
AmbiguousLocalTimeError
else:
t = t1
# warn the user that time was invalid and changed or raise
In

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

[Alexander Belopolsky]

On Fri, Apr 10, 2015 at 12:43 PM, Isaac Schwabacher 
wrote:

> (and strptime doesn't even let you pass in a time zone)


Not true:

>>> datetime.strptime('-0400 EDT', '%z %Z')
datetime.datetime(1900, 1, 1, 0, 0,
tzinfo=datetime.timezone(datetime.timedelta(-1, 72000), 'EDT'))
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher 
wrote:

> > Storing isdst in the datetime object would allow utcoffset(dt) to
> distinguish between 1:30AM before clock change and 1:30AM after. Where do
> you propose to store the offset?
>
> I propose to add an offset field to datetime.datetime. It should be set
> precisely when the tz field is set, and it should contain either a
> timedelta or an integer number of (possibly fractional) seconds, depending
> on what color the bikeshed gets painted. This is, IIUC, precisely where
> Lennart is proposing to store the is_dst flag.


Can you describe a situation where having isdst flag is not sufficient?

Note that in many applications you want to find the appropriate offset
knowing only local time and location, so requiring users to supply the
offset defeats the purpose of the time zone database.  In many
applications, the isdst flag can be hidden from the user.  For example, a
scheduling application can pretend that a repeated hour does not exist and
always assume that 01:30 AM is the first 01:30 AM.  (In many business
applications, it is a good idea anyways.)  Alternatively, a user attempting
to schedule an event at an ambiguous time can be presented with a warning
and a request to pick one of two possible times.  This would be a much
friendlier interface than the one always requiring the use to specify the
UTC offset.
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 8, 2015 at 6:52 PM, Isaac Schwabacher 
wrote:
>
> > So "storing the offset" and "storing a flag" are not two alternative
solutions to the same problem- these
> > are two solutions to two different problems.
>
> I'm viewing a time zone as a map from UTC to local time; for example,
America/Chicago is a time zone. I'm not proposing storing the offset as an
alternative to storing the *time zone*, I'm proposing it as an alternative
to storing whether a given time is DST or not.


When you are proposing to store something, you also need to specify where
you are proposing to store it.  In the current design, local time
information is stored in the datetime object and the rules that govern UTC
to local  mapping (and back) are stored in the tzinfo object.  The
implementors of concrete tzinfo subclasses are supposed to have access to
time zone rules and implement utcoffset(dt), together with dst(dt) and
tzname(dt) methods.

Storing isdst in the datetime object would allow utcoffset(dt) to
distinguish between 1:30AM before clock change and 1:30AM after.  Where do
you propose to store the offset?  If you store it in dt, why would you need
the tzinfo?


>
> We really don't care whether a time is DST or not;

You may not care about it, but current tzinfo interface and
tzinfo.fromutc(dt) method do.  Whatever new features are added to the
standard library, they cannot break existing uses.  This means that
whatever concrete tzinfo implementations we add to stdlib, they must
provide an implementation of tzinfo.dst(dt) method.

>  So our times would look like "2013-11-03 01:30:00-0500 America/Chicago"
and an hour later, "2013-11-03 01:30:00-0600 America/Chicago". And all of
that information is stored in the datetime object.

I don't think this is what most people would expect

$ TZ=America/Chicago date
Wed Apr  8 18:26:01 CDT 2015

or

$ TZ=America/Chicago date +"%c %z"
Wed 08 Apr 2015 06:27:09 PM CDT -0500

and not have location as a part of their timestamps.

Regardless, whatever the proposal to add timezones to stdlib will end up
being, it must include the ability to implement an equivalent of UNIX date
command shown above.
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 3:07 PM, Isaac Schwabacher 
wrote:

> > No, it does not. Please read the documentation: "self must be aware
> (self.tzinfo must not be None, and self.utcoffset() must not return None)."
>
> Whoops, you're right. But that's even worse-- it doesn't give you a way to
> convert a naive datetime at all. Currently the only way from "2013-11-03
> 01:30:00" to "2013-11-03 01:30:00-0500 America/Chicago" is still
> datetime.replace().


Well, you are right, but at least we do have a localtime utility hidden in
the email package:

>>> from datetime import *
>>> from email.utils import localtime
>>> print(localtime(datetime.now()))
2015-04-09 15:19:12.84-04:00

You can read  for the reasons it did not
make into 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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 8, 2015 at 8:11 PM, Alex Lord  wrote:

> Newb question time, what's BoF
>

http://en.wikipedia.org/wiki/Birds_of_a_feather_%28computing%29
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 3:39 PM, Isaac Schwabacher 
wrote:

> > Well, you are right, but at least we do have a localtime utility hidden
> in the email package:
> >
> >
> > >>> from datetime import *
> > >>> from email.utils import localtime
> > >>> print(localtime(datetime.now()))
> > 2015-04-09 15:19:12.84-04:00
> >
> >
> > You can read  for the reasons it did
> not make into datetime.
>
> But that's restricted to the system time zone. Nothing good ever comes
> from the system time zone...


Let's solve one problem at a time.  You cannot have a complete TZ support
without supporting the local timezone.  The advantage of starting with the
local timezone is that most systems have a semi-standard interface to
obtain local zone name and offset for any UTC time.  To support multiple
zones, one would
need to bundle an external library which opens a lot of questions that are
orthogonal to the issue at hand:
how to deal with ambiguous local times in the presence of DST or other
political time shifts?

email.utils.localtime solves this problem in the same way as POSIX mktime
does: by introducing an optional isdst flag.  The main objection to this
interface was that in most use cases the programmer has no intelligent way
to set this flag to anything other than -1.

An alternative solution would be to have localtime(dt) (or astimezone(dt))
return a list of aware local times that in most cases will contain only one
element, but may contain 0 or 2 when dt falls on a switchover.
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 8, 2015 at 3:57 PM, Isaac Schwabacher 
wrote:
>
> On 15-04-08, Lennart Regebro wrote:
> > === Stdlib option 2: A datetime _is_dst flag ===
> >
> > By having a flag on the datetime instance that says "this is in DST or
not"
> > the timezone implementation can be kept simpler.
>
> Storing the offset itself instead of a flag makes things conceptually
cleaner.


It is important to distinguish two notions that unfortunately both called a
"time zone."  For lack
of better terms, let me define "named offsets"  and "locations" as follows:

A "named offset" is an abbreviation such as UTC, EST, MSK, MSD which (at
any given time)
corresponds to a fixed offset from UTC.  Since at different historical
times, the same abbreviation
such as MSK may correspond to a different offset, you cannot always derive
one from another
and extended struct tm provides fields for both: tm_gmtoff and tm_zone.

A location is a name of geographical entity such as America/New_York which
follows the same
timekeeping rules.

The isdst flag is necessary when you know the location and local time and
want to find out the
corresponding UTC time. In many locations, there is one our every year when
knowing local
time is not enough because the same local time corresponds to two different
UTC times.

This happens in the US when we move the clock back one hour some day in the
Fall.  UTC time
marches on, but local time repeats the same hour.  So in order to know what
01:30 AM is in New York,
you also need to know whether it is before we moved the clocks back or
after.

So "storing the offset" and "storing a flag" are not two alternative
solutions to the same problem- these
are two solutions to two different problems.



..
> On 15-04-08, Alexander Belopolsky wrote:
> > With datetime, we also have a problem that POSIX APIs don't have to
deal with: local time
> > arithmetics. What is t + timedelta(1) when t falls on the day before
DST change? How would
> > you set the isdst flag in the result?
>
> It's whatever time comes 60*60*24 seconds after t in the same time zone,
because the timedelta class isn't expressive enough to represent anything
but absolute time differences (nor should it be, IMO).

This is not what most uses expect.  The expect

datetime(y, m, d, 12, tzinfo=New_York) + timedelta(1)

to be

datetime(y, m, d+1, 12, tzinfo=New_York)
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 8, 2015 at 7:32 PM, Chris Angelico  wrote:

> On Thu, Apr 9, 2015 at 8:32 AM, Alexander Belopolsky
>  wrote:
> > A "named offset" is an abbreviation such as UTC, EST, MSK, MSD which (at
> any
> > given time)
> > corresponds to a fixed offset from UTC.
>
> That assumes the abbreviations are unique. They're not. Just this
> morning I had to explain to a new student of mine that no, my time
> zone is not "EST" = New York time, it's actually "EST" = Melbourne
> time. Granted, most of the time New York and Melbourne are opposite on
> DST, so one will be EST and one EDT, but that trick won't always help
> you.


I should have been more precise in my definitions.  A "named offset" is a
pair
(tm_gmtoff, tm_zone).  Given a location and a UTC time (UNIX timestamp), you
should be able to produce a "named offset".

$ TZ=Australia/Melbourne date -d @1428536256 +"%z %Z"
+1000 EST

The "name" part is usually redundant, but convenient for human readers.

The opposite is not true: you cannot derive location from either or both
parts.
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher 
wrote:

> I just looked through the datetime documentation, and it looks like the
> currently blessed way of creating an aware datetime from a naive local
> datetime and a tzinfo is datetime.replace, which is too low level to handle
> the job.


Not quite.  That's how you would create a UTC datetime, but from there you
can get to your local timezone by calling astimezone() with no arguments:

>>> print(datetime.now(timezone.utc).astimezone())
2015-04-09 12:16:58.576272-04:00
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Thu, Apr 9, 2015 at 12:49 PM, Isaac Schwabacher 
wrote:
>
> if someone passed you datetime(2013, 11, 3, 1, 30) without a time zone.
astimezone assumes that the input naive time is UTC, which is not the case
here.


No, it does not.  Please read the documentation: "self must be aware
(self.tzinfo must not be None, and self.utcoffset() must not return None)."

<
https://docs.python.org/3/library/datetime.html#datetime.datetime.astimezone
>
___
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] Aware datetime from naive local time Was: Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Apr 13, 2015 at 1:24 PM, Chris Barker  wrote:

>
>
>>   Because of these discontinuities, an equation wall(loc, t) = lt may
>> have 0, 1
>> or 2 solutions.
>>
>
> This is where I'm confused -- I can see how going from "wall" time
> ("local" time, etc) to UTC has 0, 1, or 2 solutions:
>
> One solution most of the time
>
> Zero solutions when we "spring forward" -- i.e. there is no 2:30 am
> on March 8, 2015 in the US timezones that use DST
>
> Two solutions when we "fall back", i.e. there are two 2:30 am Nov 1, 2015
> in the US timezones that use DST
>
> But I can't see where there are multiple solutions the other way around --
> doesn't a given UTC time map to one and only one "wall time" in a given
> timezone?
>
> Am I wrong, or is this a semantic question as to what "wall" time means?
>

You are right about what wall() means, but I should have been more explicit
about knowns and unknowns in the wall(loc, t) = lt equation.

In that equation I considered loc (the geographical place) and lt (the time
on the clock tower) to be known and t (the universal (UTC) time) to be
unknown.  A solution to the equation is the value of the unknown (t) given
the values of the knowns (loc and lt).

The rest of your exposition is correct including "a given UTC time maps to
one and only one 'wall time' in a given timezone."  However, different UTC
times may map to the same wall time and some expressible wall times are not
results of a map of any UTC 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] Aware datetime from naive local time Was: Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Apr 13, 2015 at 2:05 PM, Chris Barker  wrote:

> However, different UTC times may map to the same wall time and some
>> expressible wall times are not results of a map of any UTC time.
>>
>
> got it. I suggest you perhaps word it something like:
>
> wall_time = f( location, utc_time)
>
> and
>
> utc_time = f( location, utc_time )
>
> These are two different problems, and one is much harder than the other!
> (though both are ugly!)
>

You probably meant "utc_time = f( location, wall_time)" in the last
equation, but that would still be wrong.
A somewhat more correct equation would be

utc_time = f^(-1)( location, wall_time)

where f^(-1) is the inverse function of f, but since f in not monotonic, no
such inverse exists.

Finding the inverse of f is the same as solving the equation f(x) = y for
any given y.  If f is such that this
equation has only one solution for all possible values of y then an inverse
exists, but this
is not so in our case.
___
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] Keyword-only parameters

[Alexander Walters]

Lacking anything anyone else says... the use case for keyword only 
arguments (where they actually make the code better rather than simply 
being different) is rather limited.



On 4/14/2015 13:40, Eric V. Smith wrote:

I'm working on adding a numeric_owner parameter to some tarfile methods
(http://bugs.python.org/issue23193),

In a review, Berker suggested making the parameter keyword-only. I agree
that you'd likely never want to pass just "True", but that
"numeric_owner=True" would be a better usage.

But, I don't see a lot of keyword-only parameters being added to stdlib
code. Is there some position we've taken on this? Barring someone saying
"stdlib APIs shouldn't contain keyword-only params", I'm inclined to
make numeric_owner keyword-only.

Is there anything stopping me from making it keyword-only?

Thanks.
Eric.
___
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/tritium-list%40sdamon.com


___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 8, 2015 at 11:18 AM, Lennart Regebro  wrote:
>
> I wrote PEP-431 two years ago, and never got around to implement it.
> This year I got some renewed motivation after Berker Peksağ made an
> effort of implementing it.
> I'm planning to work more on this during the PyCon sprints, and also
> have a BoF session or similar during the conference.


For those who were not at the conference, can someone summarize the
post-PyCon status of this PEP?

Is Barry still the "BDFL-Delegate"?  Is there an updated draft?  Should
this discussion move to python-ideas?
___
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] Aware datetime from naive local time Was: Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 15, 2015 at 4:46 PM, Akira Li <4kir4...@gmail.com> wrote:

> > Look what happened on July 1, 1990.  At 2 AM, the clocks in Ukraine were
> > moved back one hour.  So times like 01:30 AM happened twice there on that
> > day.  Let's see how Python handles this situation
> >
> > $ TZ=Europe/Kiev python3
>  from email.utils import localtime
>  from datetime import datetime
>  localtime(datetime(1990,7,1,1,30)).strftime('%c %z %Z')
> > 'Sun Jul  1 01:30:00 1990 +0400 MSD'
> >
> > So far so good, I've got the first of the two 01:30AM's.  But what if I
> > want the other 01:30AM?  Well,
> >
>  localtime(datetime(1990,7,1,1,30), isdst=0).strftime('%c %z %Z')
> > 'Sun Jul  1 01:30:00 1990 +0300 EEST'
> >
> > gives me "the other 01:30AM", but it is counter-intuitive: I have to ask
> > for the standard (winter)  time to get the daylight savings (summer)
> time.
> >
>
> It looks incorrect. Here's the corresponding pytz code:
>
>   from datetime import datetime
>   import pytz
>
>   tz = pytz.timezone('Europe/Kiev')
>   print(tz.localize(datetime(1990, 7, 1, 1, 30),
> is_dst=False).strftime('%c %z %Z'))
>   # -> Sun Jul  1 01:30:00 1990 +0300 EEST
>   print(tz.localize(datetime(1990, 7, 1, 1, 30), is_dst=True).strftime('%c
> %z %Z'))
>   # -> Sun Jul  1 01:30:00 1990 +0400 MSD
>
> See also "Enhance support for end-of-DST-like ambiguous time" [1]
>
> [1] https://bugs.launchpad.net/pytz/+bug/1378150
>
> `email.utils.localtime()` is broken:
>

If you think there is a bug in email.utils.localtime - please open an issue
at .


>
>   from datetime import datetime
>   from email.utils import localtime
>
>   print(localtime(datetime(1990, 7, 1, 1, 30)).strftime('%c %z %Z'))
>   # -> Sun Jul  1 01:30:00 1990 +0300 EEST
>   print(localtime(datetime(1990, 7, 1, 1, 30), isdst=0).strftime('%c %z
> %Z'))
>   # -> Sun Jul  1 01:30:00 1990 +0300 EEST
>   print(localtime(datetime(1990, 7, 1, 1, 30), isdst=1).strftime('%c %z
> %Z'))
>   # -> Sun Jul  1 01:30:00 1990 +0300 EEST
>   print(localtime(datetime(1990, 7, 1, 1, 30), isdst=-1).strftime('%c %z
> %Z'))
>   # -> Sun Jul  1 01:30:00 1990 +0300 EEST
>
>
> Versions:
>
>   $ ./python -V
>   Python 3.5.0a3+
>   $ dpkg -s tzdata | grep -i version
>   Version: 2015b-0ubuntu0.14.04
>
> > The uncertainty about how to deal with the repeated hour was the reason
> why
> > email.utils.localtime-like  interface did not make it to the datetime
> > module.
>
> "repeated hour" (time jumps back) can be treated like a end-of-DST
> transition, to resolve ambiguities [1].


I don't understand what you are complaining about.  It is quite possible
that pytz uses is_dst flag differently from the way email.utils.localtime
uses isdst.

I was not able to find a good description of what is_dst means in pytz, but
localtime's isdst is documented as follows:

a positive or zero value for *isdst* causes localtime to
presume initially that summer time (for example, Daylight Saving Time)
is or is not (respectively) in effect for the specified time.

Can you demonstrate that email.utils.localtime does not behave as
documented?
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 15, 2015 at 5:28 PM, Stuart Bishop 
wrote:
>
> On 15 April 2015 at 21:51, Lennart Regebro  wrote:
> > On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop 
wrote:
>
> > Just punting it to tzinfo to make adjustments, ie effectively just
> > doing what normalize() does creates infinite recursion as there is
> > more arithmetic in there, so it's not quite that simple.
>
> This sounds familiar. Its infinite recursion if the tzinfo does its
> calculations using localized datetimes. If the tzinfo is stripped for
> the calculations, there is no tzinfo to recurse into. At least this
> was how I hoped it would work, and it sucks if it doesn't. You could
> be right that using the UTC representation internally for datetimes
> with a tzinfo makes the most sense.

There is no infinite recursion in the way datetime module deals with zone
conversions.   However, implementors of tzinfo subclasses often overlook
the fact that datetime module design mandates specific rules for what
utcoffset() should return for the missing and ambiguous hours. Granted, the
relevant section in the manual [1] is not an easy read and in fact for a
long time that documentation itself was displaying a buggy implementation
of the LocalTimezone class. [2]

Understanding how the design works requires a bit of algebra [3], but I
strongly recommend that anyone trying to improve the timezones support in
the datetime module, print out those 200 lines of comments and go through
them with a pencil following the proofs.

Note that one of the key assumptions [3.2] in that write-up does not hold
in real life.  The assumption is that "standard time" offset does not
depend on the point in time.  However, I do believe that this assumption
can be relaxed without invalidating the main result.   I believe we can
still have unambiguous fromutc() as long as standard time offset does not
change "too often."  Basically, if we (generously)  allow utcoffset to vary
from -24h to +24h, then a "sane" zone can be defined as the one where
utcoffset changes at most once in any 48 hour period.

If I am right about this and the algebra works out, then we don't need to
change datetime module design to properly support all world timezones.

[1] https://docs.python.org/3/library/datetime.html#datetime.tzinfo.fromutc
[2] http://bugs.python.org/issue9063
[3] https://hg.python.org/cpython/file/132b5376bf34/Lib/datetime.py#l1935
[3.2] https://hg.python.org/cpython/file/132b5376bf34/Lib/datetime.py#l1948
___
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] Aware datetime from naive local time Was: Status on PEP-431 Timezones

[Alexander Belopolsky]

On Fri, Apr 17, 2015 at 8:19 PM, Akira Li <4kir4...@gmail.com> wrote:

> Can you demonstrate that email.utils.localtime does not behave as
>> documented?
>>
>
>
> No need to be so defensive about it.
>

There is nothing "defensive" in my question.  I simply don't understand
what you are complaining about other than
your code using pytz produces different results from some other your code
using email.utils.localtime.

If you think you found a bug in  email.utils.localtime - please explain it
without referring to a third party library.

It will also help if you do it at the bug tracker.
___
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] Type hints -- a mediocre programmer's reaction

[Alexander Walters]

So.  This is how you try and get me to care about Python 3.  Can't speak 
for others, but this does the opposite for me.  This makes me ecstatic 
that Python 2 has a nearly-frozen api.

___
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] Type hints -- a mediocre programmer's reaction

[Alexander Belopolsky]

On Tue, Apr 21, 2015 at 2:23 PM, Guido van Rossum  wrote:

> At least nobody will be writing type hints in Cyrillic. :-)


Why not?  It works just fine:

>>> Список = list
>>> def sum(x: Список):
... pass
...
>>>

(See https://en.wikipedia.org/wiki/Rapira  for some prior art.)
___
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] Unicode literals in Python 2.7

[Alexander Walters]

does this not work for you?

from __future__ import unicode_literals


On 4/28/2015 16:20, Adam Bartoš wrote:

Hello,

is it possible to somehow tell Python 2.7 to compile a code entered in 
the interactive session with the flag PyCF_SOURCE_IS_UTF8 set? I'm 
considering adding support for Python 2 in my package 
(https://github.com/Drekin/win-unicode-console) and I have run into 
the fact that when u"α" is entered in the interactive session, it 
results in u"\xce\xb1" rather than u"\u03b1". As this seems to be a 
highly specialized question, I'm asking it here.


Regards, Drekin


___
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/tritium-list%40sdamon.com


___
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 492 vs. PEP 3152, new round

[Alexander Walters]

Out of curiosity, how much of a breaking change would making unary 
operators stack arbitrarily be?



On 4/30/2015 23:57, Nathaniel Smith wrote:


On Apr 30, 2015 8:40 PM, "Guido van Rossum" > wrote:

>
> On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith > wrote:

>>
>> The actual effect of making "await" a different precedence is to 
resolve the ambiguity in

>>
>>   await x ** 2
>>
>> If await acted like -, then this would be
>>   await (x ** 2)
>> But with the proposed grammar, it's instead
>>   (await x) ** 2
>> Which is probably correct, and produces the IMHO rather nice 
invariant that "await" binds more tightly than arithmetic in general 
(instead of having to say that it binds more tightly than arithmetic 
*except* in this one corner case...)

>
> Correct.
>>
>> AFAICT these and the ** case are the only expressions where there's 
any difference between Yury's proposed grammar and your proposal of 
treating await like unary minus. But then given the limitations of 
Python's parser plus the desire to disambiguate the expression above 
in the given way, it becomes an arguably regrettable, yet inevitable, 
consequence that

>>
>>   await -fut
>>   await +fut
>>   await ~fut
>> become parse errors.
>
>  Why is that regrettable? Do you have a plan for overloading one of 
those on Futures? I personally consider it a feature that you can't do 
that. :-)


I didn't say it was regrettable, I said it was arguably regrettable. 
For proof, see the last week of python-dev ;-).


(I guess all else being equal it would be nice if unary operators 
could stack arbitrarily, since that really is the more natural parse 
rule IMO and also if things had worked that way then I would have 
spent this thread less confused. But this is a pure argument from 
elegance. In practice there's obviously no good reason to write "await 
-fut" or "-not x", so meh, whatever.)


-n



___
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/tritium-list%40sdamon.com


___
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] iso8601 parsing

[Alexander Belopolsky]

On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker  wrote:
> On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan  wrote:
>>
> can anyone argue that it's not a good idea for datetime ot
> be able to read the iso format it puts out?

No, but the last time I suggested that that datetime types should
satisfy the same invariants as numbers, namely
T(repr(x)) == x, the idea was met will silence.  I, on the other hand,
am not very enthusiastic about named constructors such as
date.isoparse().  Compared with date(s:str), this is one more method
name to remember, plus the potential for abuse as an instance method.
What is d.isoparse('2017-11-24')?
___
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] iso8601 parsing

[Alexander Belopolsky]

> On Oct 25, 2017, at 11:45 AM, Alex Walters  wrote:
> 
> it means
> the type of the first argument changes the semantic meaning of subsequent
> arguments, and that just adds a level of confusion to any api.

No, it does not. Passing a string a the first of three arguments will still be 
a type error. 
___
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] iso8601 parsing

[Alexander Belopolsky]

On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters  wrote:
>  Why make parsing ISO time special?

It's not the ISO format per se that is special, but parsing of str(x).
For all numeric types, int, float, complex and even
fractions.Fraction, we have a roundtrip invariant T(str(x)) == x.
Datetime types are a special kind of numbers, but they don't follow
this established pattern.  This is annoying when you deal with time
series where it is common to have text files with a mix of dates,
timestamps and numbers.  You can write generic code to deal with ints
and floats, but have to special-case anything time related.
___
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] iso8601 parsing

[Alexander Belopolsky]

On Wed, Oct 25, 2017 at 5:30 PM, Steven D'Aprano  wrote:
> Maybe I'm just being slow today, but I don't see how you can write
> "generic code" to convert text to int/float/complex/Fraction, but not
> times. The only difference is that instead of calling the type directly,
> you call the appropriate classmethod.
>
> What am I missing?

Nothing. The only annoyance is that the data processing code typically
needs to know the type anyway, so the classmethod is one more variable
to keep track of.
___
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] iso8601 parsing

[Alexander Belopolsky]

On Wed, Oct 25, 2017 at 5:30 PM, Chris Barker  wrote:

> Let's get passed the bike shedding and make this work!

Sure.  Submitting a pull request for
 would be a good start.
___
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] iso8601 parsing

[Alexander Belopolsky]

On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker  wrote:

>
> indeed what is the holdup? I don't recall anyone saying it was a bad idea
> in the last discussion.
>
> Do we just need an implementation?
>
> Is the one in the Bug Report not up to snuff? If not, then what's wrong
> with it? This is just not that hard a problem to solve.
>


See my comment from over a year ago: <
https://bugs.python.org/issue15873#msg273609>.  The proposed patch did not
have a C implementation, but we can use the same approach as with strptime
and call Python code from C.  If users will start complaining about
performance, we can speed it up in later releases.  Also the new method
needs to be documented.  Overall, it does not seem to require more than an
hour of work from a motivated developer, but the people who contributed to
the issue in the past seem to have lost their interest.
___
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] iso8601 parsing

[Alexander Belopolsky]

On Wed, Nov 29, 2017 at 7:18 PM, Mario Corchero  wrote:

> There were discussions about having it a function, making the constructor
> of datetime accept a string(this was strongly rejected), having a static
> function in datetime, etc... and there was no real agreement.
>

Guido has written several times that a named constructor is the way
forward.  The name "fromisoformat" was more or less agreed upon as well.
In fact, Mathieu Dupuy's patch was 95% there.
___
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] iso8601 parsing

[Alexander Belopolsky]

> is there a strict deadline here if we want this for Python 3.7?

The deadline for the new features is the date of the first beta currently
scheduled for 2018-01-29, but if you can get this in before the last alpha
(2018-01-08) it will be best.

See PEP 537 (https://www.python.org/dev/peps/pep-0537) for details and
updates.
___
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

[Python-Dev] Unexpected bytecode difference

[Alexander Belopolsky]

I have encountered the following difference between Python 3 and 2:

(py3)
>>> compile('xxx', '<>', 'eval').co_code
b'e\x00S\x00'

(py2)
>>> compile('xxx', '<>', 'eval').co_code
'e\x00\x00S'

Note that 'S' (the code for RETURN_VALUE) and a zero byte are swapped
in Python 2 compared to Python 3.  Is this change documented
somewhere?
___
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] Unexpected bytecode difference

[Alexander Belopolsky]

On Fri, Jan 19, 2018 at 7:01 PM, Guido van Rossum  wrote:
> Presumably because Python 3 switched to wordcode. Applying dis.dis() to
> these code objects results in the same output.
>
 dis.dis(c)
>   0 LOAD_NAME   0 (0)
>   3 RETURN_VALUE

I expected these changes to be documented at
, but the EXTENDED_ARG
section, for example, is the same in the 2 and 3 versions and says
that the default argument is two bytes.
___
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] Unexpected bytecode difference

[Alexander Belopolsky]

On Fri, Jan 19, 2018 at 7:18 PM, Victor Stinner
 wrote:
> It seems like the EXTENDED_ARG doc wasn't updated.

I've opened  to update the dis
module documentation.

I have also found a patch (mkfu4.patch) attached to issue 27095 where
EXTENDED_ARG is described as

 .. opcode:: EXTENDED_ARG (ext)

   EXTENDED_ARG adds ``*ext* * 256`` to the next instruction's argument.
   This is used for arguments exceeding a byte in size, and can be chained
   to create 4-byte arguments.

I am not sure this is correct.  First, multiple EXTENDED_ARG codes
seem to add ext * 256 ** i or bit-append ext to arg. Second, it looks
like this mechanism allows forming arguments of arbitrary bit length,
not just 4-byte arguments.
___
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] Symmetry arguments for API expansion

[Alexander Belopolsky]

On Mon, Mar 12, 2018 at 5:18 PM, Tim Peters  wrote:
> [Guido]
>>  as_integer_ratio() seems mostly cute (it has Tim Peters all
>> over it),
>
> Nope!  I had nothing to do with it.  I would have been -0.5 on adding
> it had I been aware at the time.
>
> - I expect the audience is tiny.

The datetime module would benefit from having as_integer_ratio()
supported by more types.  It's been hard to resist requests to allow
Decimal in timedelta constructors and/or arithmetics

>>> timedelta(Decimal('1.5'))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported type for timedelta days component: decimal.Decimal

but

>>> timedelta(1.5)
datetime.timedelta(days=1, seconds=43200)

I don't recall why we decided not to accept anything with an
.as_integer_ratio() method.

See  for additional discussion.
___
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] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Alexander Belopolsky]

On Fri, May 4, 2018 at 11:43 AM, Steven D'Aprano  wrote:
> On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
> ..
> I'm not defending Ivan's initial email. His tantrum *was* annoying,
> unreasonable, and unfair to those who do care about tkinter. He could
> have done better.
>
> But *we* should be better too. Our response to Ivan has not been
> welcoming, and as a community we haven't lived up to our own standards,
> as we have piled onto him to express our rightous indignation:

+1

It may be a reflection of me sharing the cultural roots with Ivan, but
his original post did not sound particularly offensive to me. I've
seen worse.

When it comes to communication on public fora, I am a strong believer
in Postel's principle of robustness: "be conservative in what you do,
be liberal in what you accept from others."
___
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] 2.7 is here until 2020, please don't call it a waste.

[Alexander Walters]

Python is a giant cache-miss generator.  A little performance boost on 
the opt-code dispatch isn't going to change that much.  If we really do 
care about improving python to do less environmental damage, then that 
is a discussion we should be having on it's own merits.  It was really 
out of place, even in this tangenty thread.


On 5/29/2015 20:34, Nick Coghlan wrote:



On 30 May 2015 09:57, "Antoine Pitrou" > wrote:

>
> On Sat, 30 May 2015 01:49:10 +0200
> Christian Heimes > wrote:

> > For performance patches we have to consider our responsibility for the
> > environment. Every improvement means more speed and less power
> > consumption. Python runs of hundreds of thousands of machines in the
> > cloud. Python 2.7 will be used for at least half a decade, probably
> > longer. Servers can be replaced with faster machines later and less
> > fossil fuel must be burned to produce power.
>
> Please keep your ideology out of this.

I'm a qualified engineer (in computer systems engineering), so caring 
about environmental sustainability is part of my professional ethical 
standards, not just a matter of personal preference: 
http://www.wfeo.org/ethics/


Given the power draw of large data centres, the environmental impact 
of performance improvements to the Python 2 series is a point well 
worth considering.


Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> 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/ncoghlan%40gmail.com




___
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/tritium-list%40sdamon.com


___
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] 2.7 is here until 2020, please don't call it a waste.

[Alexander Walters]

Who said anything about funding?  this is a thread about the patch Intel 
offered (and had committed).


And that's the point.  This is the thread about THAT patch.  Why are we 
hijacking this topic for an environmental debate?  If it is a legitimate 
topic (which it might be), discuss it in its own right. Otherwise it 
sounds like guilt-tripping and greenwashing.


This patch will do little to nothing statistically significant for the 
environment.  Bringing that up is ideology and politics.


On 5/30/2015 04:55, Nick Coghlan wrote:

On 30 May 2015 10:46, "Alexander Walters"  wrote:

Python is a giant cache-miss generator.  A little performance boost on the 
opt-code dispatch isn't going to change that much.  If we really do care about 
improving python to do less environmental damage, then that is a discussion we 
should be having on it's own merits.  It was really out of place, even in this 
tangenty thread.

I think the way core development gets funded is entirely on topic for
the main core development mailing list, we just historically haven't
discussed it openly, even though some of us have been advocating for
various improvements to arrangements behind the scenes. I personally
consider becoming more transparent about how we go about that process
to be a good thing.

Intel are looking to get involved in CPython core development
*specifically* to work on performance improvements, so it's important
to offer folks in the community good reasons for why we're OK with
seeing at least some of that work applied to Python 2, rather than
restricting their contributions to Python 3.

The key is that the reason for not backporting performance
enhancements *differs* from the reasons for not backporting new
features. Rolling out new features has a broad ripple effect on the
Python ecosystem as books, training material, etc, all need to be
updated, and projects need to decide how to communicate their version
dependencies appropriately if they decide to depend on one of the
backported features. We pushed that kind of Python 2 change out to
PyPI years ago, and aside from truly exceptional cases like the
network security enhancements in PEPs 466 & 476 and the decision to
bundle pip to make it easier to access PyPI, it isn't open for
reconsideration as a general principle.

Performance improvements, by contrast, historically haven't been
backported solely due to the stability and maintainability
implications for CPython itself - they don't have a change management
ripple effect the way new language and standard library level features
do. That lack of negative ripple effects that cause work for other
people is why the proposal to contribute paid development time makes
such a big difference to the acceptability of Python 2.7 performance
patches, as it should be a pure gain for current Python 2.7 users, and
the paid development contributions should address the maintainability
concerns on the core development side (particularly since Intel are
*paying* for their coaching in core contribution practices and
politics, rather than expecting to receive that coaching from
community volunteers for free).

Backporting the computed goto patch is an easy place for them to
start, since the change is already well tested in the Python 3 branch,
but we don't expect this to be the end of the line for CPython 2 (or
3) performance enhancements.

However, we also shouldn't downplay the significance of this as a
notable policy change for the Python 2.7 maintenance branch, which
means it is useful to offer folks as many reasons as we can to help
them come to terms with the idea that Python 2 performance still
matters, and that it is only the limitations on our development and
support capacity that prevented us from further improving it
previously.

The commercially pragmatic reason is because Python 2 is where the
largest current installed base is today, so applying some of the
increased development capacity arising from sponsored contributions to
Python 2.7 performance improvements is a good way to demonstrate to
Python 2 developers that we still care about them *as Python 2 users*,
rather than only being interested in them as potential future Python 3
users. This is the rationale that's likely to get our paid
contributors (both current and future) on board with the idea, but it
isn't necessarily going to be compelling to folks that are here as
volunteers.

The first "What's in it for the volunteers?" reason is the one I
raised: giving the nod to an increased corporate developer presence in
Python 2 maintenance should eventually let volunteers stop worrying
about even Python 2.7 bug fix changes with a clear conscience,
confident that as volunteer efforts drop away redistributors and other
folks with an institutional interest will pick up the slack with paid
development time. "Do the fun stuff for free, figure out a way to get
paid for the 

Re: [Python-Dev] Computed Goto dispatch for Python 2

[Alexander Walters]

A better course of action would be to deprecate the non-portable 
version.  Other than setting the PATH envvar, why do we need to continue 
even touching the system on install?  It is highly annoying for those of 
us that maintain several installs of python on a single windows system, 
and it really should stop.


The only use I can think of for ever touching the registry in the first 
place is to tell distutils installers where python is.  I can tell you 
right now, that design choice is a bug.  There are some mighty hacks you 
have to go through to correct that behavior when you happen to be using 
a virtualenv.


(We are calling it 'embedable', but the rest of the world would call it 
'portable', as in, runable from a usb stick)


On 5/31/2015 06:47, Paul Moore wrote:

On 31 May 2015 at 11:41, Paul Moore  wrote:

On 31 May 2015 at 10:14, Xavier Combelle  wrote:

+1. The new embeddable Python distribution for Windows is a great step
forward for this. It's not single-file, but it's easy to produce a
single-directory self-contained application with it. I don't know if
there's anything equivalent for Linux/OSX - maybe it's something we
should look at for them as well (although the whole "static binaries"
concept seems to be fairly frowned on in the Unix world, from what
I've seen).


Just curious What is "the new embeddable Python distribution for Windows" ?

Python 3.5 ships a zipfile which contains a self-contained Python
installation, intended for embedding. The idea is that you unzip it
into your application directory, and use it from within your
application (either via the embedding API, or using the included
python.exe/pythonw.exe). It doesn't use the registry, or any global
resources, so it's independent of any installed python that might be
present.

By the way, IMO the new embeddable distribution is a pretty big deal
on Windows. To make sure that it doesn't end up unnoticed, can I
suggest we include a prominent "What's New" entry for it, and a
section in "Python Setup and Usage" under "Using Python on Windows"
for it?

I'd hate to find that 3 or 4 versions from now, we're still trying to
remind people that they can use the embeddable distribution, in the
same way that executable zipfiles ended up an almost unknown feature
for ages.

Paul
___
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/tritium-list%40sdamon.com


___
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] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

[Alexander Belopolsky]

On Wed, Jul 22, 2015 at 7:09 AM, Paul Moore  wrote:

> does anyone seriously think a core dev
> commits code as a joke???
>

Yes, . :-)
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Thu, Jul 23, 2015 at 12:22 PM, Lennart Regebro  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
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Fri, Jul 24, 2015 at 9:39 PM, Tim Peters  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.
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Sat, Jul 25, 2015 at 2:40 AM, Lennart Regebro  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.
___
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] Status on PEP-431 Timezones

[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 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
___
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] Burning down the backlog.

[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-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".
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore  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
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert  wrote:

> > On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky <
> alexander.belopol...@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
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 12:15 PM, Nikolaus Rath  wrote:

> On Jul 27 2015, Lennart Regebro  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'
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro  wrote:

> On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath  wrote:
> > On Jul 27 2015, Lennart Regebro  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.
___
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] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 5:13 PM, Tim Peters  wrote:

> [Brett Cannon ]
> \> 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.
___
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-498: Literal String Formatting

[Alexander Walters]

Please do not change the meaning of the vestigial U''.  It was re-added 
to the language to fix a problem, rebinding it to another meaning 
introduces new problems.  We have plenty of other letters in the 
alphabet to use.


On 8/8/2015 05:34, Nick Coghlan wrote:

On 8 August 2015 at 11:39, Eric V. Smith  wrote:

Following a long discussion on python-ideas, I've posted my draft of
PEP-498. It describes the "f-string" approach that was the subject of
the "Briefer string format" thread. I'm open to a better title than
"Literal String Formatting".

Thanks you for your work on this - it's a very cool concept!

I've also now written and posted an initial draft of PEP 500, based
directly on PEP 498, which formalises the "__interpolate__" builtin
idea I raised in those threads, along with a PEP 292 based syntax
proposal that aims to be as simple as possible for the simple case of
interpolating existing variables, while still allowing the use of
braces to permit embedding of arbitrary expressions and formatting
directives.

it turned out this approach provided an unanticipated benefit that I
only discovered while writing the PEP: by defining a separate
"__interpolateb__" builtin, it's straightforward to define binary
interpolation in terms of bytes.__mod__, while still defining text
interpolation in terms of str.format.

The previously-redundant-in-python-3 'u' prefix also finds new life as
a way of always requesting the default string interpolation, even if
__interpolate__ has been overridden in the current namespace to mean
something else (like il8n string translation).

Cheers,
Nick.



___
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-498: Literal String Formatting

[Alexander Walters]

... Its adding meaning to something that was intentionally meaningless.  
Not using u'' has the obvious, immediate benefit of not caring what u'' 
means in python 3, so one can continue to write polyglot code.  Since 
you are adding new semantics to python 3, use a different letter so that 
it just breaks in python 2, instead of having different meanings between 
versions.


Python 2 is still the dominant python.

On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters  wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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-498: Literal String Formatting

[Alexander Walters]

Wait a second, the pep itself does not use the vestigial u''... it uses 
i''.  where did u'' come from?


On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters  wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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-498: Literal String Formatting

[Alexander Walters]

As written in the pep, where i'' means 'I have the __interpolate__' 
method, and iu'' means 'i have the __interpolateu__' method (or that 
translators should call these methods), is fine, as the meaning of u ('I 
am unicode, yeah you already knew that') isn't changed.


On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters  wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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-498: Literal String Formatting

[Alexander Walters]

On 8/10/2015 01:29, Sven R. Kunze wrote:
The best solution would be "without prefix and '{var}' only" syntax. 
Not sure if that is possible at all; I cannot remember using '{...}' 
anywhere else than for formatting.


My JSON string literal 'test fixtures' weep at that idea.

___
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-498: Literal String Formatting

[Alexander Walters]

This may seam like a simplistic solution to i18n, but why not just add a 
method to string objects (assuming we implement f-strings) that just 
returns the original, unprocessed string.  If the string was not an 
f-string, it just returns self.  The gettext module can be modified, I 
think trivially, to use the method instead of the string directly.


Is this a horrible idea?

- Alex W.
___
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-498: Literal String Formatting

[Alexander Walters]

On 8/11/2015 11:16, Eric V. Smith wrote:

On 08/11/2015 11:09 AM, Alexander Walters wrote:

This may seam like a simplistic solution to i18n, but why not just add a
method to string objects (assuming we implement f-strings) that just
returns the original, unprocessed string.  If the string was not an
f-string, it just returns self.  The gettext module can be modified, I
think trivially, to use the method instead of the string directly.

You need the original string, in order to figure out what it translates
to. You need the values to replace into that string, evaluated at
runtime, in the context of where the string appears. And you need to
know where in the original (or translated) string to put them.

The problem is that there's no way to evaluate the values and, before
they're substituted in to the string, use a different template string
with obvious substitution points. This is what PEP 501 is trying to do.

Eric.
I don't understand some of that.  We already trust translators with 
_('foo {bar}').format(bar=bar) to not mess up the {bar} in the string, 
so the that wont change.  Is the issue handing the string back to python 
to be formatted?  Could gettext not make the same AST as an f-string 
would, and hand that back to python?  If you add a method to strings 
that returns the un-f-string-processed version of the string, doesn't 
that make all these problems solvable without pep-501?

___
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 needed for http://bugs.python.org/issue9232 ?

[Alexander Walters]

As a user who has banged my head against this more than once, its not a 
feature, its a bug, it does not need a pep (Guido said as much), just 
fix it.


On 8/11/2015 11:31, Chris Barker - NOAA Federal wrote:

there's been enough debate that I suspect we need a

PEP.


I think we might just need another round of discussion here.

Please no :-)

Looking back at the previous discussion, it looked like it's all been
said, and there was almost unanimous approval (with some key mild
disapproval) for the idea, so what we need now is a pronouncement.

If it's unclear whether consensus was close, then folks that are
strongly against should speak up now. If there is a flurry of those,
then a PEP is in order. But another big long unstructured discussion
won't be useful.

-Chris





I'm +1 myself.  Granted there haven't been many times I've wanted it
(functions with enough arguments to want to make it easy to add and
remove elements are a bit of a code smell), but I have wanted it (and
even used the form that is accepted) several times.  On the other hand,
the number of times when the detection of a trailing comma has revealed
a missing argument to me (Raymond's objection) has been...well, I'm
pretty sure it is zero.  Especially since it only happens *sometimes*.
Since backward compatibility says we shouldn't disallow it where it is
currently allowed, the only logical thing to do, IMO, is consistently
allow it.

(If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for
disallowing trailing commas outside of ().  The number of times I've
ended up with an unintentional tuple after converting a dictionary to a
series of assignments outnumbers both of the above :)  Note, I am *not*
suggesting doing this!)

--David
___
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/chris.barker%40noaa.gov

___
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/tritium-list%40sdamon.com


___
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-498: Literal String Formatting

[Alexander Walters]

On 8/11/2015 11:28, Wes Turner wrote:



On Aug 11, 2015 10:19 AM, "Wes Turner" > wrote:


- [ ] review all string interpolation (for "injection")
  * [ ] review every '%'
  * [ ] review every ".format()"
  * [ ] review every f-string (AND LOCALS AND GLOBALS)
  * every os.system, os.exec*, subprocess.Popen
  * every unclosed tag
  * every unescaped control character

This would create work we don't need.

Solution: __str_shell_ escapes, adds slashes, and quotes. __str__SQL__ 
refs a global list of reserved words.



I don't understand why % and .format got interjected into this.

If you are mentioning them as 'get the unprocessed version of any string 
formatting', that is a bad idea, and not needed, since you already have 
an unprocessed string object.  Assuming the method were named 
"hypothetical":


>>> 'foo bar'.hypothetical()  # returns 'foo bar'
>>> '{0} bar'.format('foo').hypothetical()  # returns 'foo bar'
>>> ('%s bar' % ('foo',)).hypothetical() # returns 'foo bar'
>>> f'{foo} bar'.hypothetical() # returns '{foo} bar', prime for 
translation.


could gettext not be modified to create the same AST as f'{foo} bar' 
when it is translated to '{foo} le bar.' and inject it back into the 
runtime?
___
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] [Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement

[Alexander Belopolsky]

[Posted on Python-Dev]

On Sun, Aug 16, 2015 at 3:23 PM, Guido van Rossum  wrote:
> I think that a courtesy message to python-dev is appropriate, with a link to
> the PEP and an invitation to discuss its merits on datetime-sig.

Per Gudo's advise, this is an invitation to join PEP 495 discussion on
Datetime-SIG.

I you would like to catch-up on the SIG discussion, the archive of
this thread starts at
.

The PEP itself can be found at
, but if you would like to
follow draft updates as they happen, you can do it on Github at
.

Even though the PEP is deliberately minimal in scope, there are still
a few issues to be ironed out including how to call the disambiguation
flag.  It is agreed that the name should not refer to DST and should
distinguish between two ambiguous times by their chronological order.
The working name is "first", but no one particularly likes it
including the author of the PEP.  Some candidates are discussed in the
PEP at ,
and some more have been suggested that I will add soon.

Please direct your responses to .
___
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

[Python-Dev] PEP 495: What's left to resolve

[Alexander Belopolsky]

The good news that other than a few editorial changes there is only one
issue which keeps me from declaring PEP 495 complete.  The bad news is that
the remaining issue is subtle and while several solutions have been
proposed, neither stands out as an obviously right.

The Problem
---

PEP 495 requires that the value of the fold attribute is ignored when two
aware datetime objects that share tzinfo are compared.  This is motivated
by the reasons of backward compatibility: we want the value of fold to only
matter in conversions from one zone to another and not in arithmetic within
a single timezone.

As Tim pointed out, this rule is in conflict with the only requirement that
a hash function must satisfy: if two objects compare as equal, their hashes
should be equal as well.

Let t0 and t1 be two times in the fold that differ only by the value of
their fold attribute: t0.fold == 0, t1.fold == 1.  Let u0 =
t0.astimezone(utc) and u1 = t1.astimezone(t1).  PEP 495 requires that u0 <
u1.  (In fact, this is the main purpose of the PEP to disambiguate between
t0 and t1 so that conversion to UTC is well defined.)  However, by the
current PEP 495 rules, t0 == t1 is True, by the pre-PEP rule (and the PEP
rule that fold is ignored in comparisons) we also have t0 == u0 and t1 ==
u1.  So, we have (a) a violation of the transitivity of ==: u0 == t0 == t1
== u1 does not imply u0 == u1 which is bad enough by itself, and (b) since
hash(u0) can be equal to hash(u1) only by a lucky coincidence, the rule
"equality of objects implies equality of hashes" leads to contradiction
because applying it to the chain u0 == t0 == t1 == u1, we get hash(u0) ==
hash(t0) == hash(t1) == hash(u1) which is now a chain of equalities of
integers and on integers == is transitive, so we have hash(u0) == hash(u1)
which as we said can only happen by a lucky coincidence.


The Root of the Problem
---

The rules of arithmetic on aware datetime objects already cause some basic
mathematical identities to break.  The problem described above is avoided
by not having a way to represent u1 in the timezone where u0 and u1 map to
the same local time.  We still have a surprising u0 < u1, but
u0.astimezone(local) == u1.astimezone(local), but it does not rise to the
level of a hash invariant violation because u0.astimezone(local) and
u1.astimezone(local) are not only equal: they are identical in all other
ways and if we convert them back to UTC - they both convert to u0.

The root of the hash problem is not in the t0 == t1 is True rule.  It is in
u0 == t0.  The later equality is just too fragile: if you add
timedelta(hour=1) to both sides to this equation, then (assuming an
ordinary 1 hour fall-back fold), you will get two datetime objects that are
no longer equal. (Indeed, local to utc equality t == u is defined as t -
t.utcoffset() == u.replace(tzinfo=t.tzinfo), but when you add 1 hour to t0,
utcoffset() changes so the equality that held for t0 and u0 will no longer
hold for t0 + timedelta(hour=1) and u0 + timedelta(hour=1).)

PEP 495 gives us a way to break the u0 == t0 equality by replacing t0 with
an "equal" object t1 and simultaneously have u0 == t0, t0 == t1 and t1 !=
u0.


The Solutions
-

Tim suggested several solutions to this problem, but by his own admission
neither is more than "grudgingly acceptable."  For completeness, I will
also present my "non-solution."

Solution 0: Ignore the problem.  Since PEP 495 does not by itself introduce
any tzinfo implementations with variable utcoffset(), it does not create a
hash invariant violation.  I call this a non-solution because it would once
again punt an unsolvable problem to tzinfo implementors.  It is unsolvable
for *them* because without some variant of the rejected PEP 500, they will
have no control over datetime comparisons or hashing.

Solution 1: Make t1 > t0.

Solution 2: Leave t1 == t0, but make t1 != u1.


Request for Comments


I will not discuss pros and cons on the two solutions because my goal here
was only to state the problem, identify the root case and indicate the
possible solutions.  Those interested in details can read Tim's excellent
explanations in the "Another round on error-checking" [1] and "Another
approach to 495's glitches" [2] threads.

I "bcc" python-dev in a hope that someone in the expanded forum will either
say "of course solution N is the right one and here is why" or "here is an
obviously right solution - how could  you guys miss it."


[1]:
https://mail.python.org/pipermail/datetime-sig/2015-September/000622.html
[2]:
https://mail.python.org/pipermail/datetime-sig/2015-September/000716.html
___
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 498: Naming

[Alexander Belopolsky]

On Tue, Sep 8, 2015 at 2:37 AM, Mike Miller 
wrote:

> To my knowledge there was i for interpolation, t for template, and e for
> expression suggested.  Any better ideas?


I believe someone suggested !"..." as well.   I still think f"..." notation
is the best as long as these elements are called "format strings" in the
documentation.  After all, we don't call a unicode string "u-string" or
bytes a "b-string".  Given enough imagination someone may find
not-safe-for-work associations in those abbreviations as well.
___
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 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] 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

[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

[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