Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

[Serhiy Storchaka]

15.12.17 02:33, Antoine Pitrou пише:

On Thu, 14 Dec 2017 16:03:48 -0800
Guido van Rossum  wrote:

A slot is pretty expensive, as *every* class in existence will be another 8
bytes larger (and possibly more due to malloc rounding).


I'm always surprised by the discussions about class object size.
Even imagining you have 1 classes in memory (a pretty large number,
though I'm sure you can reach that number with a lot of dependencies),
we're talking about a total 800 kB memory growth (let's recall that
each of those classes will probably have code objects, docstrings and what
not attached to it -- i.e. you don't often create empty classes).

Is it really an important concern?


The increased memory consumption is not the only cost. Initializing new 
slots takes a time. You have to spent a time for all class objects, not 
only for theses that have correspondent methods. In case of complex 
hierarchy the cost is larger, because you need to look up methods in all 
parent classes. This increases the startup time and increases the cost 
of creating local classes.


___
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] Guarantee ordered dict literals in v3.7?

[Paul Moore]

On 15 December 2017 at 05:28, Raymond Hettinger
 wrote:
> In contrast, I gave collections.OrderedDict a different design (later coded 
> in C by Eric Snow).  The primary goal was to have efficient maintenance of 
> order even for severe workloads such at that imposed by the lru_cache which 
> frequently alters order without touching the underlying dict.   
> Intentionally, the OrderedDict has a design that prioritizes ordering 
> capabilities at the expense of additional memory overhead and a constant 
> factor worse insertion time.

That's interesting information - I wasn't aware of the different
performance goals. I'd suggest adding a discussion of these goals to
the OrderedDict documentation. Now that dictionaries preserve order
(whether or not we make that language guaranteed or an implementation
detail) having clear information on the intended performance
trade-offs of an OrderedDict would help people understand why they
might choose one over the other.

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/archive%40mail-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[INADA Naoki]

> That's interesting information - I wasn't aware of the different
> performance goals.

FYI, performance characteristic of my POC implementation of
OrderedDict based on dict order are:

* 50% less memory usage
* 15% faster creation
* 100% (2x) faster iteration
* 20% slower move_to_end
* 40% slower comparison

(copied from https://bugs.python.org/issue31265#msg301942 )

Comparison is very unoptimized at the moment and I believe it can be
more faster.
On the other hand, I'm not sure about I can optimize move_to_end() more.

If OrderdDict is recommended to be used for just keeping insertion order,
I feel 1/2 memory usage and 2x faster iteration are more important than
20% slower move_to_end().

But if either "dict keeps insertion order" or "dict keeps insertion order until
deletion" is language spec, there is no reason to use energy and time for
discussion of OrderedDict implementation.

Regards,

INADA Naoki  
___
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] Is static typing still optional?

[Steve Holden]

On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> .
>
> I see a couple of options:
> 1a: Use a default type annotation, if one is not is supplied. typing.Any
> would presumably make the most sense.
> 1b: Use None if not type is supplied.
> 2: Rework the code to not require annotations at all.
>
> I think I'd prefer 1a, since it's easy.
>
>
> 2) would be great :-)
>
> I find this bit of “typing creep” makes me nervous— Typing should Never be
> required!
>
> ​+1
​


> I understand that the intent here is that the user could ignore typing and
> have it all still work. But I’d rather is was not still there under the
> hood.
>
> Just because standardized way to do something is included in core Python
> doesn’t mean the standard library has to use it.
>
> ​I trust my repetition of the point that the stdlib is an important
learning resource isn't unduly harping on the subject. Python is in danger
of becoming pretty arcane rather too rapidly for my own liking​, though I
confess to being mostly a consumer of Python.

> However, typing is not currently imported by dataclasses.py.
>
>
> And there you have an actual reason besides my uneasiness :-)
>
> - CHB
>
> ​hmm...​
___
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] [OT] Re: Is static typing still optional?

[Antoine Pitrou]

I'm not sure what Mail User Agent each of you is using, but it is quite
impossible (here) to make out who is saying what in your latest
messages.

See plain text rendering here:
https://mail.python.org/pipermail/python-dev/2017-December/151274.html

Regards

Antoine.


On Fri, 15 Dec 2017 10:56:28 +
Steve Holden  wrote:
> On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:  
> 
> > .
> >
> > I see a couple of options:
> > 1a: Use a default type annotation, if one is not is supplied. typing.Any
> > would presumably make the most sense.
> > 1b: Use None if not type is supplied.
> > 2: Rework the code to not require annotations at all.
> >
> > I think I'd prefer 1a, since it's easy.
> >
> >
> > 2) would be great :-)
> >
> > I find this bit of “typing creep” makes me nervous— Typing should Never be
> > required!
> >
> > ​+1  
> ​
> 
> 
> > I understand that the intent here is that the user could ignore typing and
> > have it all still work. But I’d rather is was not still there under the
> > hood.
> >
> > Just because standardized way to do something is included in core Python
> > doesn’t mean the standard library has to use it.
> >
> > ​I trust my repetition of the point that the stdlib is an important  
> learning resource isn't unduly harping on the subject. Python is in danger
> of becoming pretty arcane rather too rapidly for my own liking​, though I
> confess to being mostly a consumer of Python.
> 
> > However, typing is not currently imported by dataclasses.py.
> >
> >
> > And there you have an actual reason besides my uneasiness :-)
> >
> > - CHB
> >
> > ​hmm...​  
> 



___
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] Is static typing still optional?

[Eric V. Smith]

On 12/15/2017 5:56 AM, Steve Holden wrote:
On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal 
mailto:chris.bar...@noaa.gov>> wrote:

...

However, typing is not currently imported by dataclasses.py.

>

And there you have an actual reason besides my uneasiness :-)

- CHB

​hmm...​


[Agreed with Antoine on the MUA and quoting being confusing.]

The only reason typing isn't imported is performance. I hope that once 
PEP 560 is complete this will no longer be an issue, and dataclasses 
will always import typing. But of course typing will still not be needed 
for most uses of @dataclass or make_dataclass(). This is explained in 
the PEP.


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/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

[Serhiy Storchaka]

15.12.17 04:00, Guido van Rossum пише:
In the light of Antoine's and Stephan's feedback I think this can be 
reconsidered -- while I want to take a cautious stance about resource 
consumption I don't want to stand in the way of progress.


I don't see any problems with implementing this on types defined in C. 
This isn't harder than implementing __sizeof__ or pickling support, and 
NumPy classes already have implemented both. Maybe Yury forgot about 
METH_STATIC and METH_CLASS?


The cost of adding new slots:

1. Increased memory consumption. This increases the size of *every* 
class, even if they don't implement this feature.


2. Increased class initialization time. For every class for every slot 
we need to look up corresponding methods in dictionaries of the class 
itself and all its parents (caching doesn't work fine at this stage). 
Significant part of class initialization time is spent on initializing 
slots. This will increase the startup time and the time of creating 
local classes. The relative overhead is more significant in Cython.


3. We need to add a new type feature flag Py_TPFLAGS_HAVE_*. The number 
of possible flags is limited, and most bits already are used. We can add 
the limited number of new slots, and should not spent this resource 
without large need.


4. Increased complexity. Currently the code related to PEP 560 is 
located in few places. With supporting new slots we will need to touch 
more delicate code not related directly to PEP 560. It is hard to review 
and to test such kind of changes. I can't guarantee the correctness.


Some libraries can create new classes on demand (see for example 
https://rhye.org/post/python-cassandra-namedtuple-performance/ and not 
accepted proposition in https://bugs.python.org/issue13299). This 
increases the cost of items 1 and 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] Accepting PEP 560 -- Core support for typing module and generic types

[Yury Selivanov]

> I don't see any problems with implementing this on types defined in C. This 
> isn't harder than implementing __sizeof__ or pickling support, and NumPy 
> classes already have implemented both. Maybe Yury forgot about METH_STATIC 
> and METH_CLASS?

I just tested __class_getitem__ defined via METH_STATIC and it works.
This means we don't need to add slots.  Thanks for the hint, Serhiy!

Ivan, this might be worth mentioning in the PEP or in the docs.

Yury
___
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] Make __class_getitem__ a class method

[Serhiy Storchaka]

The class itself always is passed as the first argument to 
__class_getitem__():


cls.__class_getitem__(cls, item)

I propose to make __class_getitem__ a class method. This will make 
simpler implementing it in C. Currently it should be declared with flags 
METH_VARARGS|METH_STATIC and implementing as


static PyObject *
generic_class_getitem(PyObject *Py_UNUSED(self), PyObject *args)
{
PyObject *type, *item;
if (!PyArg_UnpackTuple(args, "__class_getitem__", 2, 2, &type, 
&item)) {

return NULL;
}
...
}

Note an unused parameter and the need of manual unpacking arguments.

If use it as a class method it should be declared with flags 
METH_O|METH_CLASS and implemented as


static PyObject *
generic_class_getitem(PyObject *type, PyObject *item)
{
...
}

See https://github.com/python/cpython/pull/4883 for sample.

___
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] Accepting PEP 560 -- Core support for typing module and generic types

[Ivan Levkivskyi]

On 15 December 2017 at 15:55, Yury Selivanov 
wrote:

> > I don't see any problems with implementing this on types defined in C.
> This isn't harder than implementing __sizeof__ or pickling support, and
> NumPy classes already have implemented both. Maybe Yury forgot about
> METH_STATIC and METH_CLASS?
>
> I just tested __class_getitem__ defined via METH_STATIC and it works.
> This means we don't need to add slots.  Thanks for the hint, Serhiy!
>
> Ivan, this might be worth mentioning in the PEP or in the docs.


I think it should be added to the PEP. Somehow I didn't think about C
extensions, but now I see that it is important, also recently there
appeared a lot of interest in better support of static typing for NumPy
arrays and numeric stack.
I will make a PR a bit later.

--
Ivan
___
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] Make __class_getitem__ a class method

[Ivan Levkivskyi]

I like this idea. I have few suggestions for the test cases you added, will
add them a bit later in the PR.

--
Ivan


On 15 December 2017 at 16:00, Serhiy Storchaka  wrote:

> The class itself always is passed as the first argument to
> __class_getitem__():
>
> cls.__class_getitem__(cls, item)
>
> I propose to make __class_getitem__ a class method. This will make simpler
> implementing it in C. Currently it should be declared with flags
> METH_VARARGS|METH_STATIC and implementing as
>
> static PyObject *
> generic_class_getitem(PyObject *Py_UNUSED(self), PyObject *args)
> {
> PyObject *type, *item;
> if (!PyArg_UnpackTuple(args, "__class_getitem__", 2, 2, &type, &item))
> {
> return NULL;
> }
> ...
> }
>
> Note an unused parameter and the need of manual unpacking arguments.
>
> If use it as a class method it should be declared with flags
> METH_O|METH_CLASS and implemented as
>
> static PyObject *
> generic_class_getitem(PyObject *type, PyObject *item)
> {
> ...
> }
>
> See https://github.com/python/cpython/pull/4883 for sample.
>
> ___
> 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/levkivsky
> i%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

[Python-Dev] f-strings

[Wagner Herculano]

Good evening,
I'm Wagner Herculano from Brazil.
I was trying to do a table exercise with number 5 and tried formatting spaces 
and did not find it in PEP 498 documentation.
Finally I found a way, if possible, include this example in the documentation 
please.

Below is my script with the desired formatting about table of 5.

n = 5
for i in range(1,11):
print(f'{n} x {i:>2} = {n*i:>2}')

Result
5 x  1 =  5
5 x  2 = 10
5 x  3 = 15
5 x  4 = 20
5 x  5 = 25
5 x  6 = 30
5 x  7 = 35
5 x  8 = 40
5 x  9 = 45
5 x 10 = 50
---
Sorry my English, I needed to use Google Translate

Best Regards,
Wagner Herculano
___
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] Guarantee ordered dict literals in v3.7?

[Guido van Rossum]

Make it so. "Dict keeps insertion order" is the ruling. Thanks!

On Fri, Dec 15, 2017 at 2:30 AM, INADA Naoki  wrote:

> > That's interesting information - I wasn't aware of the different
> > performance goals.
>
> FYI, performance characteristic of my POC implementation of
> OrderedDict based on dict order are:
>
> * 50% less memory usage
> * 15% faster creation
> * 100% (2x) faster iteration
> * 20% slower move_to_end
> * 40% slower comparison
>
> (copied from https://bugs.python.org/issue31265#msg301942 )
>
> Comparison is very unoptimized at the moment and I believe it can be
> more faster.
> On the other hand, I'm not sure about I can optimize move_to_end() more.
>
> If OrderdDict is recommended to be used for just keeping insertion order,
> I feel 1/2 memory usage and 2x faster iteration are more important than
> 20% slower move_to_end().
>
> But if either "dict keeps insertion order" or "dict keeps insertion order
> until
> deletion" is language spec, there is no reason to use energy and time for
> discussion of OrderedDict implementation.
>
> Regards,
>
> INADA Naoki  
> ___
> 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/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] f-strings

[Mariatta Wijaya]

That's covered under "format specifiers" I think.
The PEP mentions this:
https://www.python.org/dev/peps/pep-0498/#format-specifiers

That specific example is not mentioned in the docs, but there other
examples of using format specifiers with f-strings.
https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals


On Dec 15, 2017 7:39 AM, "Wagner Herculano" 
wrote:

> Good evening,
> I'm Wagner Herculano from Brazil.
> I was trying to do a table exercise with number 5 and tried formatting
> spaces and did not find it in PEP 498 documentation.
> Finally I found a way, if possible, include this example in the
> documentation please.
>
> Below is my script with the desired formatting about table of 5.
>
> *n = 5*
>
>
>
>
>
>
>
>
>
>
>
>
>
> *for i in range(1,11): print(f'{n} x {i:>2} = {n*i:>2}') Result5
> x  1 =  5 5 x  2 = 10 5 x  3 = 15 5 x  4 = 20 5 x  5 = 25 5 x  6 = 30 5 x
> 7 = 35 5 x  8 = 40 5 x  9 = 45 5 x 10 = 50*
> *---*
> *Sorry my English, I needed to use Google Translate*
>
> Best Regards,
> Wagner Herculano
>
> ___
> 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/mariatta.
> wijaya%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] Support of the Android platform

[Xavier de Gaye]

On 12/14/2017 02:59 PM, Victor Stinner wrote:
> It seems like Android is evolving quickly, would say quicker than
> Python releases. I'm asking if it's a good idea to put a recipe aside
> the Python source code for one specific Android API version? Would it
> still make sense to build for NDK v14 in 2 or 5 years?

NDK 14 has been released in march 2017 and the latest release is NDK 16. There are sometimes major changes between releases and I think it is critical to ensure that the builds all use the same NDK 
release for that reason. Supporting another NDK release is just a substitution in one of the files of the build system and I am sure that in 2 or 5 years there would have been a core developer smart 
enough to make that substitution (this could even have been me, I will only be 71 years old in 5 years :-)). Anyway if this is a problem, this should have been discussed in a review of the PR.


There are concerns, including a concern raised by me, about supporting Android with that build system or to supporting Android at all. It has been interesting and gratifying to work on this build 
system and to get the Python test suite running on Android without failures. Given these concerns and the lack of interest in the support of Android it is time for me to switch to something else, 
maybe improve the bdb module, why not ?


Xavier
___
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] Guarantee ordered dict literals in v3.7?

[Raymond Hettinger]

> On Dec 15, 2017, at 7:53 AM, Guido van Rossum  wrote:
> 
> Make it so. "Dict keeps insertion order" is the ruling. Thanks!

Thank you.  That is wonderful news :-)

Would it be reasonable to replace some of the OrderedDict() uses in the 
standard library with dict()?  For example, have namedtuples's _asdict() go 
back to returning a plain dict as it did in its original incarnation. Also, it 
looks like argparse could save an import by using a regular dict.


Raymond

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

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

[Antoine Pitrou]

On Fri, 15 Dec 2017 14:05:46 +0200
Serhiy Storchaka  wrote:
> 15.12.17 04:00, Guido van Rossum пише:
> > In the light of Antoine's and Stephan's feedback I think this can be 
> > reconsidered -- while I want to take a cautious stance about resource 
> > consumption I don't want to stand in the way of progress.  
> 
> I don't see any problems with implementing this on types defined in C. 
> This isn't harder than implementing __sizeof__ or pickling support, and 
> NumPy classes already have implemented both. Maybe Yury forgot about 
> METH_STATIC and METH_CLASS?
> 
> The cost of adding new slots:
> 
> 1. Increased memory consumption. This increases the size of *every* 
> class, even if they don't implement this feature.
> 
> 2. Increased class initialization time. For every class for every slot 
> we need to look up corresponding methods in dictionaries of the class 
> itself and all its parents (caching doesn't work fine at this stage). 
> Significant part of class initialization time is spent on initializing 
> slots. This will increase the startup time and the time of creating 
> local classes. The relative overhead is more significant in Cython.
> 
> 3. We need to add a new type feature flag Py_TPFLAGS_HAVE_*. The number 
> of possible flags is limited, and most bits already are used. We can add 
> the limited number of new slots, and should not spent this resource 
> without large need.
> 
> 4. Increased complexity. Currently the code related to PEP 560 is 
> located in few places. With supporting new slots we will need to touch 
> more delicate code not related directly to PEP 560. It is hard to review 
> and to test such kind of changes. I can't guarantee the correctness.

These are all very good points (except #1 which I think is a red
herring, see my posted example).  Do you have any general idea how to
speed up class creation?

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/archive%40mail-archive.com

Re: [Python-Dev] Make __class_getitem__ a class method

[Yury Selivanov]

Shouldn't we optimize the usability for pure-Python first, and then for C API?

Right now we have the '__new__' magic method, which isn't a
@classmethod.  Making '__class_getitem__' a @classmethod will confuse
regular Python users.  For example:

   class Foo:
  def __new__(cls, ...): pass

  @classmethod
  def __class_getitem__(cls, item): pass

To me it makes sense that type methods that are supposed to be called
on type by the Python interpreter don't need the classmethod
decorator.

METH_STATIC is a public working API, and in my opinion it's totally
fine if we use it. It's not even hard to use it, it's just *mildly*
inconvenient at most.

Yury
___
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] f-strings

[Chris Barker - NOAA Federal]

That's covered under "format specifiers" I think.
The PEP mentions this:
https://www.python.org/dev/peps/pep-0498/#format-specifiers


I can see how a newbie might not realize that that means that f-strings use
the same formatting language as the .format() method, and or where to find
documentation for it.

So somewhere in the docs making that really clear, with a link to the
formatting spec documentation would be good.

Not sure where though — a PEP is not designed to be user documentation.

-CHB


That specific example is not mentioned in the docs, but there other
examples of using format specifiers with f-strings.
https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals


On Dec 15, 2017 7:39 AM, "Wagner Herculano" 
wrote:

> Good evening,
> I'm Wagner Herculano from Brazil.
> I was trying to do a table exercise with number 5 and tried formatting
> spaces and did not find it in PEP 498 documentation.
> Finally I found a way, if possible, include this example in the
> documentation please.
>
> Below is my script with the desired formatting about table of 5.
>
> *n = 5*
>
>
>
>
>
>
>
>
>
>
>
>
>
> *for i in range(1,11): print(f'{n} x {i:>2} = {n*i:>2}') Result5
> x  1 =  5 5 x  2 = 10 5 x  3 = 15 5 x  4 = 20 5 x  5 = 25 5 x  6 = 30 5 x
> 7 = 35 5 x  8 = 40 5 x  9 = 45 5 x 10 = 50*
> *---*
> *Sorry my English, I needed to use Google Translate*
>
> Best Regards,
> Wagner Herculano
>
> ___
> 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/mariatta.
> wijaya%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/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/archive%40mail-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Guido van Rossum]

On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum  wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> Thank you.  That is wonderful news :-)
>
> Would it be reasonable to replace some of the OrderedDict() uses in the
> standard library with dict()?  For example, have namedtuples's _asdict() go
> back to returning a plain dict as it did in its original incarnation. Also,
> it looks like argparse could save an import by using a regular dict.
>

If it's documented as OrderedDict that would be backwards incompatible,
since that has additional methods. Even if not documented it's likely to
break some code. So, I'm not sure about this (though I agree with the
sentiment that OrderedDict is much less important now).

-- 
--Guido van Rossum (python.org/~guido)
___
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] Make __class_getitem__ a class method

[Ivan Levkivskyi]

On 15 December 2017 at 17:47, Yury Selivanov 
wrote:

> Shouldn't we optimize the usability for pure-Python first, and then for C
> API?
>
> Right now we have the '__new__' magic method, which isn't a
> @classmethod.  Making '__class_getitem__' a @classmethod will confuse
> regular Python users.  For example:
>
>class Foo:
>   def __new__(cls, ...): pass
>
>   @classmethod
>   def __class_getitem__(cls, item): pass
>
> To me it makes sense that type methods that are supposed to be called
> on type by the Python interpreter don't need the classmethod
> decorator.
>

Good point! Pure Python will be the primary use case and we have another
precedent
for "automatic" class method: __init_subclass__ (it does not need to be
decorated).


> METH_STATIC is a public working API, and in my opinion it's totally
> fine if we use it. It's not even hard to use it, it's just *mildly*
> inconvenient at most.
>

OK, then documenting this "recipe" (METH_STATIC plus tuple unpacking)
should be sufficient.

--
Ivan
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2017-12-08 - 2017-12-15)
Python tracker at https://bugs.python.org/

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

Issues counts and deltas:
  open6330 (+15)
  closed 37755 (+64)
  total  44085 (+79)

Open issues with patches: 2448 


Issues opened (51)
==

#17852: Built-in module _io can lose data from buffered files at exit
https://bugs.python.org/issue17852  reopened by pitrou

#32256: Make patchcheck.py work for out-of-tree builds
https://bugs.python.org/issue32256  opened by izbyshev

#32257: Support Disabling Renegotiation for SSLContext
https://bugs.python.org/issue32257  opened by chuq

#32259: Misleading "not iterable" Error Message when generator return 
https://bugs.python.org/issue32259  opened by Camion

#32261: Online doc does not include inspect.classify_class_attrs
https://bugs.python.org/issue32261  opened by csabella

#32263: Template string docs refer to "normal %-based substitutions"
https://bugs.python.org/issue32263  opened by v+python

#32266: test_pathlib fails if current path has junctions
https://bugs.python.org/issue32266  opened by Ivan.Pozdeev

#32267: strptime misparses offsets with microsecond format
https://bugs.python.org/issue32267  opened by mariocj89

#32270: subprocess closes redirected fds even if they are in pass_fds
https://bugs.python.org/issue32270  opened by izbyshev

#32275: SSL socket methods don't retry on EINTR?
https://bugs.python.org/issue32275  opened by pitrou

#32276: there is no way to make tempfile reproducible (i.e. seed the u
https://bugs.python.org/issue32276  opened by Yaroslav.Halchenko

#32278: Allow dataclasses.make_dataclass() to omit type information
https://bugs.python.org/issue32278  opened by eric.smith

#32279: Pass keyword arguments from dataclasses.make_dataclass() to @d
https://bugs.python.org/issue32279  opened by eric.smith

#32280: Expose `_PyRuntime` through a section name
https://bugs.python.org/issue32280  opened by Maxime Belanger

#32281: bdist_rpm v.s. the Macintosh
https://bugs.python.org/issue32281  opened by bhyde

#32282: When using a Windows XP compatible toolset, `socketmodule.c` f
https://bugs.python.org/issue32282  opened by Maxime Belanger

#32283: Cmd.onecmd documentation is misleading
https://bugs.python.org/issue32283  opened by lyda

#32285: In `unicodedata`, it should be possible to check a unistr's no
https://bugs.python.org/issue32285  opened by Maxime Belanger

#32287: Import of _pyio module failed on cygwin
https://bugs.python.org/issue32287  opened by Matúš Valo

#32288: Inconsistent behavior with slice assignment?
https://bugs.python.org/issue32288  opened by Massimiliano Culpo

#32289: Glossary does not define "extended slicing"
https://bugs.python.org/issue32289  opened by steven.daprano

#32290: bolen-dmg-3.6: compilation failed with OSError: [Errno 23] Too
https://bugs.python.org/issue32290  opened by vstinner

#32291: Value error for string shared memory in multiprocessing
https://bugs.python.org/issue32291  opened by magu

#32295: User friendly message when invoking bdist_wheel sans wheel pac
https://bugs.python.org/issue32295  opened by EWDurbin

#32296: Implement asyncio._get_running_loop() and get_event_loop() in 
https://bugs.python.org/issue32296  opened by yselivanov

#32299: unittest.mock.patch.dict.__enter__ should return the dict
https://bugs.python.org/issue32299  opened by Allen Li

#32300: print(os.environ.keys()) should only print the keys
https://bugs.python.org/issue32300  opened by Aaron.Meurer

#32303: Namespace packages have inconsistent __loader__ and __spec__.l
https://bugs.python.org/issue32303  opened by barry

#32304: Upload failed (400): Digests do not match on .tar.gz ending wi
https://bugs.python.org/issue32304  opened by llecaroz

#32305: Namespace packages have inconsistent __file__ and __spec__.ori
https://bugs.python.org/issue32305  opened by barry

#32306: Clarify map API in concurrent.futures
https://bugs.python.org/issue32306  opened by David Lukeš

#32307: Bad assumption on thread stack size makes python crash with mu
https://bugs.python.org/issue32307  opened by Natanael Copa

#32308: Replace empty matches adjacent to a previous non-empty match i
https://bugs.python.org/issue32308  opened by serhiy.storchaka

#32309: Implement asyncio.run_in_executor shortcut
https://bugs.python.org/issue32309  opened by asvetlov

#32310: Remove _Py_PyAtExit from Python.h
https://bugs.python.org/issue32310  opened by nascheme

#32312: Create Py_AtExitRegister C API
https://bugs.python.org/issue32312  opened by nascheme

#32313: Wrong inspect.getsource for datetime
https://bugs.python.org/issue32313  opened by Aaron.Meurer

#32315: can't run any scripts with 2.7.x, 32 and 64-bit
https://bugs.python.org/issue32315  opened by DoctorEvil

#32317: sys.exc_clear() clears exception in other stack frames
https://bugs.python.org/issue32317  opened by Garrett Berg

#32318: Remove "globals()" ca

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

[Serhiy Storchaka]

15.12.17 18:36, Antoine Pitrou пише:

Do you have any general idea how to speed up class creation?


Some work was done in [https://bugs.python.org/issue31336]. Currently I 
have no ideas.


Creating a class is 1-2 orders slower than creating a function. And 
adding parent classes significantly slows down it.


$ ./python -m perf timeit --duplicate=100 'def f(s): pass'
.
Mean +- std dev: 50.4 ns +- 0.8 ns
$ ./python -m perf timeit --duplicate=100 'class C: pass'
.
Mean +- std dev: 6.80 us +- 0.14 us
$ ./python -m perf timeit --duplicate=100 'class C:' '  def m(s): pass'
.
Mean +- std dev: 7.11 us +- 0.11 us
$ ./python -m perf timeit --duplicate=100 'class C(str): pass'
.
Mean +- std dev: 8.47 us +- 0.34 us

I'm surprised that that creating a method is much slower (6 times!) than 
creating a function. Maybe due to __set_name__ or other magic.


It isn't surprised that creating an enum or namedtuple class is much 
slower than creating a regular class. The latter was much worse before 3.7.


$ ./python -m perf timeit -s 'from enum import Enum' --duplicate=100 
'class E(Enum): A = 1'

.
Mean +- std dev: 45.9 us +- 0.8 us
$ ./python -m perf timeit -s 'from collections import namedtuple' 
--duplicate=100 'P = namedtuple("P", ("x",))'

.
Mean +- std dev: 44.7 us +- 0.6 us

___
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] Guarantee ordered dict literals in v3.7?

[Eric V. Smith]

On 12/15/2017 11:55 AM, Guido van Rossum wrote:
On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger 
mailto:raymond.hettin...@gmail.com>> wrote:



> On Dec 15, 2017, at 7:53 AM, Guido van Rossum mailto:gu...@python.org>> wrote:
>
> Make it so. "Dict keeps insertion order" is the ruling. Thanks!

Thank you.  That is wonderful news :-)

Would it be reasonable to replace some of the OrderedDict() uses in
the standard library with dict()?  For example, have namedtuples's
_asdict() go back to returning a plain dict as it did in its
original incarnation. Also, it looks like argparse could save an
import by using a regular dict.


If it's documented as OrderedDict that would be backwards incompatible, 
since that has additional methods. Even if not documented it's likely to 
break some code. So, I'm not sure about this (though I agree with the 
sentiment that OrderedDict is much less important now).


For dataclasses, I'll change from OrderedDict to dict, since there's no 
backward compatibility concern.


But I need to remember to not do that when I put the 3.6 version on PyPI.

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/archive%40mail-archive.com

[Python-Dev] __init_subclass__ is a class method (Was: Make __class_getitem__ a class method)

[Serhiy Storchaka]

15.12.17 19:04, Ivan Levkivskyi пише:
Good point! Pure Python will be the primary use case and we have another 
precedent
for "automatic" class method: __init_subclass__ (it does not need to be 
decorated).


__init_subclass__ is very different beast, and parallels with it can be 
confusing. It is automatically decorated with classmethod if it is a 
regular function implemented in C. The following two examples are 
totally equivalent:


class A:
def __init_subclass__(cls): pass

class B:
@classmethod
def __init_subclass__(cls): pass

help(A) shows __init_subclass__() as a class method (in 3.7).

But if you implement the class in C you need to make __init_subclass__ a 
class method.


I think __init_subclass__ should be documented as a class method since 
it is a class method.


___
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] f-strings

[Mariatta Wijaya]

I agree it's useful info :)

I went ahead and made a PR [1].
In my PR, I simply linked to the Format Specification Mini Language[2] from
f-strings documentation[3].

Not sure about updating PEP 498 at this point..

[1] https://github.com/python/cpython/pull/4888

[2] https://docs.python.org/3.6/library/string.html#format-s
pecification-mini-language

[3]  https://docs.python.org/3/reference/lexical_analysis.html#f-strings
___
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] Make __class_getitem__ a class method

[Serhiy Storchaka]

15.12.17 18:47, Yury Selivanov пише:

Shouldn't we optimize the usability for pure-Python first, and then for C API?

Right now we have the '__new__' magic method, which isn't a
@classmethod.  Making '__class_getitem__' a @classmethod will confuse
regular Python users.  For example:

class Foo:
   def __new__(cls, ...): pass

   @classmethod
   def __class_getitem__(cls, item): pass

To me it makes sense that type methods that are supposed to be called
on type by the Python interpreter don't need the classmethod
decorator.

METH_STATIC is a public working API, and in my opinion it's totally
fine if we use it. It's not even hard to use it, it's just *mildly*
inconvenient at most.


__new__ is not a class method, it is an "automatic" static method.

>>> class C:
... def __new__(cls): return object.__new__(cls)
...
>>> C().__new__ is C.__new__
True
>>> C.__dict__['__new__']


The following two declarations are equivalent:

class A:
def __new__(cls): return cls.__name__

class B:
@staticmethod
def __new__(cls): return cls.__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

[Python-Dev] Type creation speed

[Antoine Pitrou]

On Fri, 15 Dec 2017 19:18:11 +0200
Serhiy Storchaka  wrote:
> 15.12.17 18:36, Antoine Pitrou пише:
> > Do you have any general idea how to speed up class creation?  
> 
> Some work was done in [https://bugs.python.org/issue31336]. Currently I 
> have no ideas.
> 
> Creating a class is 1-2 orders slower than creating a function. And 
> adding parent classes significantly slows down it.

I made simple, approximate measurements with an empty class:

- fixup_slot_dispatchers() takes 78% of the time (!)
- __build_class__() takes 5%
- computing the default __qualname__, __module__, __doc__ takes 3%
- set_names() takes 2.5%
- init_subclass() takes 2.5%

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/archive%40mail-archive.com

Re: [Python-Dev] Make __class_getitem__ a class method

[Yury Selivanov]

On Fri, Dec 15, 2017 at 12:45 PM, Serhiy Storchaka  wrote:
> 15.12.17 18:47, Yury Selivanov пише:
>>
>> Shouldn't we optimize the usability for pure-Python first, and then for C
>> API?
>>
>> Right now we have the '__new__' magic method, which isn't a
>> @classmethod.  Making '__class_getitem__' a @classmethod will confuse
>> regular Python users.  For example:
>>
>> class Foo:
>>def __new__(cls, ...): pass
>>
>>@classmethod
>>def __class_getitem__(cls, item): pass
>>
>> To me it makes sense that type methods that are supposed to be called
>> on type by the Python interpreter don't need the classmethod
>> decorator.
>>
>> METH_STATIC is a public working API, and in my opinion it's totally
>> fine if we use it. It's not even hard to use it, it's just *mildly*
>> inconvenient at most.
>
>
> __new__ is not a class method, it is an "automatic" static method.

I never said that __new__ is a class method :)

> The following two declarations are equivalent:
>
> class A:
> def __new__(cls): return cls.__name__
>
> class B:
> @staticmethod
> def __new__(cls): return cls.__name__


But nobody decorates __new__ with a @staticmethod.  And making
__class_getitem__ a @classmethod will only confuse users -- that's all
I'm saying.

So I'm +1 to keep the things exactly as they are now.  It would be
great do document that in order to implement __class_getitem__ in C
one should add it as METH_STATIC.  I also think we should merge your
PR that tests that it works the way it's expected.

Yury
___
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] Guarantee ordered dict literals in v3.7?

[Serhiy Storchaka]

15.12.17 17:53, Guido van Rossum пише:

Make it so. "Dict keeps insertion order" is the ruling. Thanks!


What should dict.popitem() return? The first item, the last item, or 
unspecified?


___
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] Guarantee ordered dict literals in v3.7?

[Guido van Rossum]

Whatever it does in 3.6.

On Fri, Dec 15, 2017 at 10:19 AM, Serhiy Storchaka 
wrote:

> 15.12.17 17:53, Guido van Rossum пише:
>
>> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>>
>
> What should dict.popitem() return? The first item, the last item, or
> unspecified?
>
>
> ___
> 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/guido%
> 40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] Guarantee ordered dict literals in v3.7?

[Paul Moore]

On 15 December 2017 at 18:19, Serhiy Storchaka  wrote:
> 15.12.17 17:53, Guido van Rossum пише:
>>
>> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> What should dict.popitem() return? The first item, the last item, or
> unspecified?

I'd say leave it as unspecified.
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/archive%40mail-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Eric Snow]

On Fri, Dec 15, 2017 at 8:53 AM, Guido van Rossum  wrote:
> Make it so. "Dict keeps insertion order" is the ruling. Thanks!

Does that include preserving order after deletion?

-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/archive%40mail-archive.com

Re: [Python-Dev] Support of the Android platform

[Glenn Linderman]

On 12/15/2017 8:29 AM, Xavier de Gaye wrote:

On 12/14/2017 02:59 PM, Victor Stinner wrote:
> It seems like Android is evolving quickly, would say quicker than
> Python releases. I'm asking if it's a good idea to put a recipe aside
> the Python source code for one specific Android API version? Would it
> still make sense to build for NDK v14 in 2 or 5 years?

NDK 14 has been released in march 2017 and the latest release is NDK 
16. There are sometimes major changes between releases and I think it 
is critical to ensure that the builds all use the same NDK release for 
that reason. Supporting another NDK release is just a substitution in 
one of the files of the build system and I am sure that in 2 or 5 
years there would have been a core developer smart enough to make that 
substitution (this could even have been me, I will only be 71 years 
old in 5 years :-)). Anyway if this is a problem, this should have 
been discussed in a review of the PR.


There are concerns, including a concern raised by me, about supporting 
Android with that build system or to supporting Android at all. It has 
been interesting and gratifying to work on this build system and to 
get the Python test suite running on Android without failures. Given 
these concerns and the lack of interest in the support of Android it 
is time for me to switch to something else, maybe improve the bdb 
module, why not ?


Xavier


I, for one, would love to see Android become a supported platform.

My understanding is that APIs are generally backward compatible, so that 
programs created with one API continue to work on future APIs... there 
may be new features they don't use and maybe can't support, because they 
don't know about newer APIs, but that is true of Windows and Linux and 
Mac also. It doesn't seem like it would be necessary to "support" or 
"release" an official Python for every new Android version, but it would 
be nice to have ongoing support for a recent version each time Python is 
released, if Xavier or someone can do it.  It is certainly a mainstream 
platform for development these days.


I see a variety of Python apps on Android, but I have no idea how well 
they work, or what their source is, or if they are supported, or what 
features of Python or its standard library might not be available, etc. 
I've been too busy on other projects to take time to investigate them.


Glenn
___
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] Make __class_getitem__ a class method

[Serhiy Storchaka]

15.12.17 20:02, Yury Selivanov пише:

But nobody decorates __new__ with a @staticmethod.  And making
__class_getitem__ a @classmethod will only confuse users -- that's all
I'm saying.

So I'm +1 to keep the things exactly as they are now.  It would be
great do document that in order to implement __class_getitem__ in C
one should add it as METH_STATIC.  I also think we should merge your
PR that tests that it works the way it's expected.


In this case I suggest to make __class_getitem__ an automatic class 
method like __init_subclass__.


The number of special cases bothers me.

___
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] Guarantee ordered dict literals in v3.7?

[Guido van Rossum]

On Fri, Dec 15, 2017 at 10:30 AM, Eric Snow 
wrote:

> On Fri, Dec 15, 2017 at 8:53 AM, Guido van Rossum 
> wrote:
> > Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> Does that include preserving order after deletion?


Yes, that's what the rest of the thread was about.

-- 
--Guido van Rossum (python.org/~guido)
___
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] Make __class_getitem__ a class method

[Eric Snow]

On Fri, Dec 15, 2017 at 11:35 AM, Serhiy Storchaka  wrote:
> In this case I suggest to make __class_getitem__ an automatic class method
> like __init_subclass__.

+1  I was just about to suggest the same thing.

-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/archive%40mail-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Tim Peters]

[Eric Snow ]
> Does that include preserving order after deletion?

Given that we're blessing current behavior:

- At any moment, iteration order is from oldest to newest.  So, "yes"
to your question.

- While iteration starts with the oldest, .popitem() returns the
youngest.  This is analogous to how lists work, viewing a dict
similarly ordered "left to right" (iteration starts at the left,
.pop() at the right, for lists and dicts).
___
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] Support of the Android platform

[Mike Miller]

I've used Kivy with buildozer on Android and it generally works well, with a few 
issues.  Currently it uses the Crystax NDK for Python 3 support.


Does anyone know how this development will affect it?

-Mike


On 2017-12-15 10:06, Glenn Linderman wrote:
I see a variety of Python apps on Android, but I have no idea how well they 
work, or what their source is, or if they are supported, or what features of 
Python or its standard library might not be available, etc. I've been too busy 
on other projects to take time to investigate them.


___
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] Accepting PEP 560 -- Core support for typing module and generic types

[MRAB]

On 2017-12-15 16:36, Antoine Pitrou wrote:

On Fri, 15 Dec 2017 14:05:46 +0200
Serhiy Storchaka  wrote:

15.12.17 04:00, Guido van Rossum пише:
> In the light of Antoine's and Stephan's feedback I think this can be 
> reconsidered -- while I want to take a cautious stance about resource 
> consumption I don't want to stand in the way of progress.  

I don't see any problems with implementing this on types defined in C. 
This isn't harder than implementing __sizeof__ or pickling support, and 
NumPy classes already have implemented both. Maybe Yury forgot about 
METH_STATIC and METH_CLASS?


The cost of adding new slots:

1. Increased memory consumption. This increases the size of *every* 
class, even if they don't implement this feature.


2. Increased class initialization time. For every class for every slot 
we need to look up corresponding methods in dictionaries of the class 
itself and all its parents (caching doesn't work fine at this stage). 
Significant part of class initialization time is spent on initializing 
slots. This will increase the startup time and the time of creating 
local classes. The relative overhead is more significant in Cython.


3. We need to add a new type feature flag Py_TPFLAGS_HAVE_*. The number 
of possible flags is limited, and most bits already are used. We can add 
the limited number of new slots, and should not spent this resource 
without large need.


4. Increased complexity. Currently the code related to PEP 560 is 
located in few places. With supporting new slots we will need to touch 
more delicate code not related directly to PEP 560. It is hard to review 
and to test such kind of changes. I can't guarantee the correctness.


These are all very good points (except #1 which I think is a red
herring, see my posted example).  Do you have any general idea how to
speed up class creation?

Re the flags, could a flag be used to indicate that there are additional 
flags?

___
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] New crash in test_embed on macOS 10.12

[Barry Warsaw]

I haven’t bisected this yet, but with git head, built and tested on macOS 
10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed:

==
FAIL: test_bpo20891 (test.test_embed.EmbeddingTests)
--
Traceback (most recent call last):
  File "/Users/barry/projects/python/cpython/Lib/test/test_embed.py", line 207, 
in test_bpo20891
out, err = self.run_embedded_interpreter("bpo20891")
  File "/Users/barry/projects/python/cpython/Lib/test/test_embed.py", line 59, 
in run_embedded_interpreter
(p.returncode, err))
AssertionError: -6 != 0 : bad returncode -6, stderr is 'Fatal Python error: 
PyEval_SaveThread: NULL tstate\n\nCurrent thread 0x7fffcb58a3c0 (most 
recent call first):\n'

Seems reproducible across different machines (all running 10.12.6 and Xcode 
9.2), even after a make clean and configure.  I don’t see the same failure on 
Debian, and I don’t see the crashes on the buildbots.

Can anyone verify?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Is static typing still optional?

[Chris Barker]

Sorry about the email mangling -- I do a lot of my listserve work on the
bus on an iPhone, with the built -in mail client -- and it REALLY sucks for
doing interspersed email replying -- highly encouraging the dreaded top
posting...

But anyway, I think both Steve and I were expressing concerns about "Typing
Creep".  Typing should always be optional in Python, and while this PEP
does keep it optional, Steve's point was that the code in the standard
library serves not only as a library, but as examples of how to write
"robust" python code.

The rest of this note is me -- I'm not pretending ot speak for Steve.

Reading the PEP, this text makes me uneasy:

"A field is defined as any variable identified in__annotations__. That is,
a variable that has a type annotation."

And if I understand the rest of the PEP, while typing itself is optional,
the use of type Annotation is not -- it is exactly what's being used to
generate the fields the user wants.

And the examples are all using typing -- granted, primarily the built in
types, but still:


@dataclass
class C:
a: int   # 'a' has no default value
b: int = 0   # assign a default value for 'b'


This sure LOOKS like typing is required. It also makes me nervous because,
as I understand it, the types aren't actually used in the
implementation (presumable they would be by mypy and the like?). So I think
for folks that aren't using typing and a type checker in their development
process, it would be pretty confusing that this means and what it actually
does. Particularly folks that are coming from a background of a statically
typed language.

Then I see:

"""
Field objects describe each defined field.
...
Its documented attributes are:

name: The name of the field.
type: The type of the field.
...
"""

So again, typing looks to be pretty baked in to the whole concept.

and then:

"""
One place where dataclass actually inspects the type of a field is to
determine if a field is a class variable as defined in PEP 526.
"""

and

"""
The other place where dataclass inspects a type annotation is to determine
if a field is an init-only variable. It does this by seeing if the type of
a field is of type dataclasses.InitVar.
"""

"""
Data Classes will raise a TypeError if it detects a default parameter of
type list, dict, or set.
"""

So: it seems that type hinting, while not required to use Data Classes, is
very much baked into the implementation an examples.

As I said -- this makes me uneasy -- It's a very big step that essentially
promotes the type hinting to a new place in Python -- you will not be able
to use a standard library class without at least a little thought about
types and typing.

I note this:

"""
This discussion started on python-ideas [9] and was moved to a GitHub repo
[10] for further discussion. As part of this discussion, we made the
decision to use PEP 526 syntax to drive the discovery of fields.
"""

I confess I only vaguely followed that discussion -- in fact, mostly I
thought that the concept of Data Classes was a good one, and was glad to
see SOMETHING get implemented, and didn't think I had much to contribute to
the details of how it was done. So these issues may have already been
raised and considered, so carry on.

But:

NOTE: from PEP 526:

"Python will remain a dynamically typed language, and the authors have no
desire to ever make type hints mandatory, even by convention. "

The Data Classes implementation is not making it mandatory by any means,
but it is making it a more "standard" part of the language that can not
simply be ignored anymore. And it seems some features of dataclasses can
only be accessed via actual typing, in addition to the requirement of type
annotations.

If nothing else, the documentation should make it very clear that the
typing aspects of Data Classes is indeed optional, and preferably give some
untyped examples, something like:

@dataclass
class C:
a: None  # 'a' has no default value
b: None = 0   # assign a default value for 'b'


If, in fact, that would be the way to do it.

-Chris




On Fri, Dec 15, 2017 at 3:22 AM, Eric V. Smith  wrote:

> On 12/15/2017 5:56 AM, Steve Holden wrote:
>
>> On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal <
>> chris.bar...@noaa.gov > wrote:
>>
> ...
>
>> However, typing is not currently imported by dataclasses.py.
>>>
>> >
>
>> And there you have an actual reason besides my uneasiness :-)
>>
>> - CHB
>>
>> ​hmm...​
>>
>
> [Agreed with Antoine on the MUA and quoting being confusing.]
>
> The only reason typing isn't imported is performance. I hope that once PEP
> 560 is complete this will no longer be an issue, and dataclasses will
> always import typing. But of course typing will still not be needed for
> most uses of @dataclass or make_dataclass(). This is explained in the PEP.
>
> Eric.
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voic

Re: [Python-Dev] Is static typing still optional?

[Chris Barker]

One other note (see my last message).

The PEP should include a summary of the discussion of the decision to use
the type annotation syntax vs other options.

I just looked through all the gitHub issues and found nothing, and started
to look at the python-ideas list archive and got overwhelmed.

So having that justification in the PEP would be good.

-CHB


On Fri, Dec 15, 2017 at 12:07 PM, Chris Barker 
wrote:

> Sorry about the email mangling -- I do a lot of my listserve work on the
> bus on an iPhone, with the built -in mail client -- and it REALLY sucks for
> doing interspersed email replying -- highly encouraging the dreaded top
> posting...
>
> But anyway, I think both Steve and I were expressing concerns about
> "Typing Creep".  Typing should always be optional in Python, and while this
> PEP does keep it optional, Steve's point was that the code in the standard
> library serves not only as a library, but as examples of how to write
> "robust" python code.
>
> The rest of this note is me -- I'm not pretending ot speak for Steve.
>
> Reading the PEP, this text makes me uneasy:
>
> "A field is defined as any variable identified in__annotations__. That
> is, a variable that has a type annotation."
>
> And if I understand the rest of the PEP, while typing itself is optional,
> the use of type Annotation is not -- it is exactly what's being used to
> generate the fields the user wants.
>
> And the examples are all using typing -- granted, primarily the built in
> types, but still:
>
>
> @dataclass
> class C:
> a: int   # 'a' has no default value
> b: int = 0   # assign a default value for 'b'
>
>
> This sure LOOKS like typing is required. It also makes me nervous because,
> as I understand it, the types aren't actually used in the
> implementation (presumable they would be by mypy and the like?). So I think
> for folks that aren't using typing and a type checker in their development
> process, it would be pretty confusing that this means and what it actually
> does. Particularly folks that are coming from a background of a statically
> typed language.
>
> Then I see:
>
> """
> Field objects describe each defined field.
> ...
> Its documented attributes are:
>
> name: The name of the field.
> type: The type of the field.
> ...
> """
>
> So again, typing looks to be pretty baked in to the whole concept.
>
> and then:
>
> """
> One place where dataclass actually inspects the type of a field is to
> determine if a field is a class variable as defined in PEP 526.
> """
>
> and
>
> """
> The other place where dataclass inspects a type annotation is to determine
> if a field is an init-only variable. It does this by seeing if the type of
> a field is of type dataclasses.InitVar.
> """
>
> """
> Data Classes will raise a TypeError if it detects a default parameter of
> type list, dict, or set.
> """
>
> So: it seems that type hinting, while not required to use Data Classes, is
> very much baked into the implementation an examples.
>
> As I said -- this makes me uneasy -- It's a very big step that essentially
> promotes the type hinting to a new place in Python -- you will not be able
> to use a standard library class without at least a little thought about
> types and typing.
>
> I note this:
>
> """
> This discussion started on python-ideas [9] and was moved to a GitHub repo
> [10] for further discussion. As part of this discussion, we made the
> decision to use PEP 526 syntax to drive the discovery of fields.
> """
>
> I confess I only vaguely followed that discussion -- in fact, mostly I
> thought that the concept of Data Classes was a good one, and was glad to
> see SOMETHING get implemented, and didn't think I had much to contribute to
> the details of how it was done. So these issues may have already been
> raised and considered, so carry on.
>
> But:
>
> NOTE: from PEP 526:
>
> "Python will remain a dynamically typed language, and the authors have no
> desire to ever make type hints mandatory, even by convention. "
>
> The Data Classes implementation is not making it mandatory by any means,
> but it is making it a more "standard" part of the language that can not
> simply be ignored anymore. And it seems some features of dataclasses can
> only be accessed via actual typing, in addition to the requirement of type
> annotations.
>
> If nothing else, the documentation should make it very clear that the
> typing aspects of Data Classes is indeed optional, and preferably give some
> untyped examples, something like:
>
> @dataclass
> class C:
> a: None  # 'a' has no default value
> b: None = 0   # assign a default value for 'b'
>
>
> If, in fact, that would be the way to do it.
>
> -Chris
>
>
>
>
> On Fri, Dec 15, 2017 at 3:22 AM, Eric V. Smith  wrote:
>
>> On 12/15/2017 5:56 AM, Steve Holden wrote:
>>
>>> On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal <
>>> chris.bar...@noaa.gov > wrote:
>>>
>> ...
>>
>>> However, typing is not currently impo

Re: [Python-Dev] New crash in test_embed on macOS 10.12

[Raymond Hettinger]

> On Dec 15, 2017, at 11:55 AM, Barry Warsaw  wrote:
> 
> I haven’t bisected this yet, but with git head, built and tested on macOS 
> 10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed:
> 
> ==
> FAIL: test_bpo20891 (test.test_embed.EmbeddingTests)
> --
> Traceback (most recent call last):
>  File "/Users/barry/projects/python/cpython/Lib/test/test_embed.py", line 
> 207, in test_bpo20891
>out, err = self.run_embedded_interpreter("bpo20891")
>  File "/Users/barry/projects/python/cpython/Lib/test/test_embed.py", line 59, 
> in run_embedded_interpreter
>(p.returncode, err))
> AssertionError: -6 != 0 : bad returncode -6, stderr is 'Fatal Python error: 
> PyEval_SaveThread: NULL tstate\n\nCurrent thread 0x7fffcb58a3c0 (most 
> recent call first):\n'
> 
> Seems reproducible across different machines (all running 10.12.6 and Xcode 
> 9.2), even after a make clean and configure.  I don’t see the same failure on 
> Debian, and I don’t see the crashes on the buildbots.
> 
> Can anyone verify?

I saw this same test failure.  After a "make distclean", it went away.


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

Re: [Python-Dev] New crash in test_embed on macOS 10.12

[Barry Warsaw]

On Dec 15, 2017, at 15:14, Raymond Hettinger  
wrote:
> 
> I saw this same test failure.  After a "make distclean", it went away.

Dang, not for me.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Guarantee ordered dict literals in v3.7?

[Nathaniel Smith]

On Dec 15, 2017 10:50, "Tim Peters"  wrote:

[Eric Snow ]
> Does that include preserving order after deletion?

Given that we're blessing current behavior:

- At any moment, iteration order is from oldest to newest.  So, "yes"
to your question.

- While iteration starts with the oldest, .popitem() returns the
youngest.  This is analogous to how lists work, viewing a dict
similarly ordered "left to right" (iteration starts at the left,
.pop() at the right, for lists and dicts).


Fortunately, this also matches OrderedDict.popitem().

It'd be nice if we could also support dict.popitem(last=False) to get the
other behavior, again matching OrderedDict.

-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/archive%40mail-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Raymond Hettinger]

> On Dec 15, 2017, at 7:53 AM, Guido van Rossum  wrote:
> 
> Make it so. "Dict keeps insertion order" is the ruling.

On Twitter, someone raised an interesting question.  

Is the guarantee just for 3.7 and later?  Or will the blessing also cover 3.6 
where it is already true.

The 3.6 guidance is to use OrderedDict() when ordering is required.  As of now, 
that guidance seems superfluous and may no longer be a sensible practice.  For 
example, it would be nice for Eric Smith when he does his 3.6 dataclasses 
backport to not have to put OrderedDict back in the code.  

Do you still have the keys to the time machine?


Raymond


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

Re: [Python-Dev] f-strings

[Chris Barker]

On Fri, Dec 15, 2017 at 9:39 AM, Mariatta Wijaya 
wrote:

> I agree it's useful info :)
>
> I went ahead and made a PR [1].
>

Thanks! I added a couple comments to that PR.


> Not sure about updating PEP 498 at this point..
>

A little clarification text would be nice. I made a PR for that:

https://github.com/python/peps/pull/514


-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.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/archive%40mail-archive.com

Re: [Python-Dev] New crash in test_embed on macOS 10.12

[Victor Stinner]

Hi,

2017-12-15 20:55 GMT+01:00 Barry Warsaw :
> I haven’t bisected this yet, but with git head, built and tested on macOS 
> 10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed:
>
> ==
> FAIL: test_bpo20891 (test.test_embed.EmbeddingTests)
> --
> Traceback (most recent call last):
>   File "/Users/barry/projects/python/cpython/Lib/test/test_embed.py", line 
> 207, in test_bpo20891
> out, err = self.run_embedded_interpreter("bpo20891")
>   File "/Users/barry/projects/python/cpython/Lib/test/test_embed.py", line 
> 59, in run_embedded_interpreter
> (p.returncode, err))
> AssertionError: -6 != 0 : bad returncode -6, stderr is 'Fatal Python error: 
> PyEval_SaveThread: NULL tstate\n\nCurrent thread 0x7fffcb58a3c0 (most 
> recent call first):\n'
>
> Seems reproducible across different machines (all running 10.12.6 and Xcode 
> 9.2), even after a make clean and configure.  I don’t see the same failure on 
> Debian, and I don’t see the crashes on the buildbots.
>
> Can anyone verify?

It's a known issue. The hint is in the method name: test_bpo20891 :-)

https://bugs.python.org/issue20891#msg307553

I fixed a bug and added a test for it, but the test showed an unknown
race condition.

I wrote a fix for the race condition, but I was asked to run a
benchmark and I didn't run it yet.

https://github.com/python/cpython/pull/4700

I hesitate to skip the test until I fix the second bug.

Victor
___
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] Is static typing still optional?

[Paul Moore]

On 15 December 2017 at 20:07, Chris Barker  wrote:
> And if I understand the rest of the PEP, while typing itself is optional,
> the use of type Annotation is not -- it is exactly what's being used to
> generate the fields the user wants.
>
> And the examples are all using typing -- granted, primarily the built in
> types, but still:
>
>
> @dataclass
> class C:
> a: int   # 'a' has no default value
> b: int = 0   # assign a default value for 'b'
>
>
> This sure LOOKS like typing is required. It also makes me nervous because,
> as I understand it, the types aren't actually used in the implementation
> (presumable they would be by mypy and the like?). So I think for folks that
> aren't using typing and a type checker in their development process, it
> would be pretty confusing that this means and what it actually does.
> Particularly folks that are coming from a background of a statically typed
> language.

I actually don't have any problem with this. It looks natural to me,
reads perfectly fine, and is a far better way of defining fields than
many of the other approaches that I've seen in the past (that don't
use annotations).

The one thing I would find surprising is that the actual type used is ignored.

@dataclass
class C:
a: str = 0

AIUI this is valid, but it looks weird to me. There's an easy answer,
though - just don't do that.

> Then I see:
>
> """
> Field objects describe each defined field.
> ...
> Its documented attributes are:
>
> name: The name of the field.
> type: The type of the field.
> ...
> """
>
> So again, typing looks to be pretty baked in to the whole concept.

Well, being able to see the type the class author intended is a
feature. I don't know I'd consider that as meaning typing is "baked
in". It's useful but ignorable data.

> and then:
>
> """
> One place where dataclass actually inspects the type of a field is to
> determine if a field is a class variable as defined in PEP 526.
> """
>
> and
>
> """
> The other place where dataclass inspects a type annotation is to determine
> if a field is an init-only variable. It does this by seeing if the type of a
> field is of type dataclasses.InitVar.
> """

Those are somewhat more explicit cases of directly using type
annotations as declarations. But what alternative would you propose?
It still seems fine to me.

> """
> Data Classes will raise a TypeError if it detects a default parameter of
> type list, dict, or set.
> """

Doesn't that mean that

@dataclass
class C:
a: int = []

raises an error? The problem here is the same as that of mutable
function default parameters - we don't want every instance of C to
share a single list object as their default value for a. It's got
nothing to do with the annotation (that's why I used the
deliberately-inconsistent annotation of int here). I'm a strong +1 on
making this an error, as it's likely to be an easy mistake to make,
and quite hard to debug.

> So: it seems that type hinting, while not required to use Data Classes, is
> very much baked into the implementation an examples.

Annotations and the annotation syntax are fundamental to the design.
But that's core Python syntax. But I wouldn't describe types as being
that significant to the design, it's more "if you supply them we'll
make use of them".

Don't forget, function parameter annotations were around long before
typing. Variable annotations weren't, but they could have been - it's
just that typing exposed a use case for them. Data classes could just
as easily have been the motivating use case for PEP 526.

> As I said -- this makes me uneasy -- It's a very big step that essentially
> promotes the type hinting to a new place in Python -- you will not be able
> to use a standard library class without at least a little thought about
> types and typing.

I will say that while I don't use typing or mypy at all in my code, I
don't have any particular dislike of the idea of typing, or the syntax
for declaring annotations. So I find it hard to understand your
concerns here. My personal uneasiness is actually somewhat the
opposite - I find it disconcerting that if I annotate a
variable/parameter as having type int, nothing stops me assigning a
string to it. But that's *precisely* what typing being optional means,
so while it seems odd to my static typing instincts, it's entirely
within the spirit of not forcing typing onto Python.

> If nothing else, the documentation should make it very clear that the typing
> aspects of Data Classes is indeed optional, and preferably give some untyped
> examples, something like:
>
> @dataclass
> class C:
> a: None  # 'a' has no default value
> b: None = 0   # assign a default value for 'b'

This does seem like a reasonable option to note. Something along the
lines of "If you don't use type annotations in your code, and you want
to avoid introducing them, using None as a placeholder for the type is
sufficient". However, I suspect that using None as a "I don't really
want to assig

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Guido van Rossum]

On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum  wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling.
>
> On Twitter, someone raised an interesting question.
>
> Is the guarantee just for 3.7 and later?  Or will the blessing also cover
> 3.6 where it is already true.
>
> The 3.6 guidance is to use OrderedDict() when ordering is required.  As of
> now, that guidance seems superfluous and may no longer be a sensible
> practice.  For example, it would be nice for Eric Smith when he does his
> 3.6 dataclasses backport to not have to put OrderedDict back in the code.
>

For 3.6 we can't change the language specs, we can just document how it
works in CPython. I don't know what other Python implementations do in
their version that's supposed to be compatible with 3.6 but I don't want to
retroactively declare them non-conforming. (However for 3.7 they have to
follow suit.) I also don't think that the "it stays ordered across
deletions" part of the ruling is true in CPython 3.6.

I don't know what guidance to give Eric, because I don't know what other
implementations do nor whether Eric cares about being compatible with
those. IIUC micropython does not guarantee this currently, but I don't know
if they claim Python 3.6 compatibility -- in fact I can't find any document
that specifies the Python version they're compatible with more precisely
than "Python 3".

-- 
--Guido van Rossum (python.org/~guido)
___
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] __init_subclass__ is a class method (Was: Make __class_getitem__ a class method)

[Ivan Levkivskyi]

On 15 December 2017 at 18:40, Serhiy Storchaka  wrote:

> 15.12.17 19:04, Ivan Levkivskyi пише:
>
>> Good point! Pure Python will be the primary use case and we have another
>> precedent
>> for "automatic" class method: __init_subclass__ (it does not need to be
>> decorated).
>>
>
> __init_subclass__ is very different beast, and parallels with it can be
> confusing. It is automatically decorated with classmethod if it is a
> regular function implemented in C. The following two examples are totally
> equivalent:
>
> class A:
> def __init_subclass__(cls): pass
>
> class B:
> @classmethod
> def __init_subclass__(cls): pass
>
> help(A) shows __init_subclass__() as a class method (in 3.7).
>
> But if you implement the class in C you need to make __init_subclass__ a
> class method.
>
> I think __init_subclass__ should be documented as a class method since it
> is a class method.
>

Thank you for clarification!
Actually documentation
https://docs.python.org/3.6/reference/datamodel.html#customizing-class-creation
already says `classmethod object.__init_subclass__(cls)`
I am not an expert in this, so I am not sure if the docs can be improved
here (maybe we can add how this works with C API?)

--
Ivan
___
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] Make __class_getitem__ a class method

[Ivan Levkivskyi]

On 15 December 2017 at 19:35, Serhiy Storchaka  wrote:

> 15.12.17 20:02, Yury Selivanov пише:
>
>> But nobody decorates __new__ with a @staticmethod.  And making
>> __class_getitem__ a @classmethod will only confuse users -- that's all
>> I'm saying.
>>
>> So I'm +1 to keep the things exactly as they are now.  It would be
>> great do document that in order to implement __class_getitem__ in C
>> one should add it as METH_STATIC.  I also think we should merge your
>> PR that tests that it works the way it's expected.
>>
>
> In this case I suggest to make __class_getitem__ an automatic class method
> like __init_subclass__.
>
> The number of special cases bothers me.
>

I just want to clarify what is proposed. As I understand:

* From the point of view of a pure Python class there will be no difference
with the current behaviour, one just writes

  class C:
  def __class_getitem__(cls, item):
  ...

*  In `type_new`, `__class_getitem__` will be wrapped in classmethod
*  From the point of view of C extensions one will use METH_CLASS and no
tuple unpacking

If this is true that this looks reasonable. If no-one is against, then I
can make a PR.
The only downside to this that I see is that `type.__new__` will be
slightly slower.

--
Ivan
___
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] __init_subclass__ is a class method (Was: Make __class_getitem__ a class method)

[Serhiy Storchaka]

16.12.17 00:48, Ivan Levkivskyi пише:
Actually documentation 
https://docs.python.org/3.6/reference/datamodel.html#customizing-class-creation 
already says `classmethod object.__init_subclass__(cls)`
I am not an expert in this, so I am not sure if the docs can be improved 
here (maybe we can add how this works with C API?)


Sorry, I had wrote my previous message before reading the documentation, 
just after reading the sources. Now I have discovered that the special 
behavior of __init_subclass__ is already documented. I don't know 
whether it is needed to add something more.


___
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] Guarantee ordered dict literals in v3.7?

[Raymond Hettinger]

> On Dec 15, 2017, at 1:47 PM, Guido van Rossum  wrote:
> 
> On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger 
>  wrote:
> 
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum  wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling.
> 
> On Twitter, someone raised an interesting question.
> 
> Is the guarantee just for 3.7 and later?  Or will the blessing also cover 3.6 
> where it is already true.
> 
> The 3.6 guidance is to use OrderedDict() when ordering is required.  As of 
> now, that guidance seems superfluous and may no longer be a sensible 
> practice.  For example, it would be nice for Eric Smith when he does his 3.6 
> dataclasses backport to not have to put OrderedDict back in the code.
> 
> For 3.6 we can't change the language specs, we can just document how it works 
> in CPython. I don't know what other Python implementations do in their 
> version that's supposed to be compatible with 3.6 but I don't want to 
> retroactively declare them non-conforming. (However for 3.7 they have to 
> follow suit.) I also don't think that the "it stays ordered across deletions" 
> part of the ruling is true in CPython 3.6.

FWIW, the regular dict does stay ordered across deletions in CPython3.6:

>>> d = dict(a=1, b=2, c=3, d=4)
>>> del d['b']
>>> d['b'] = 5
>>> d
{'a': 1, 'c': 3, 'd': 4, 'b': 5}

Here's are more interesting demonstration:

from random import randrange, shuffle
from collections import OrderedDict

population = 100
s = list(range(population // 4))
shuffle(s)
d = dict.fromkeys(s)
od = OrderedDict.fromkeys(s)
for i in range(50):
k = randrange(population)
d[k] = i
od[k] = i
k = randrange(population)
if k in d:
del d[k]
del od[k]
assert list(d.items()) == list(od.items())

The dict object insertion logic just appends to the arrays of keys, values, and 
hashvalues.  When the number of usable elements decreases to zero (reaching the 
limit of the most recent array allocation), the dict is resized (compacted) 
left-to-right so that order is preserved.

Here are some of the relevant sections from the 3.6 source tree:

Objects/dictobject.c line 89:

Preserving insertion order

It's simple for combined table.  Since dk_entries is mostly append only, we 
can
get insertion order by just iterating dk_entries.

One exception is .popitem().  It removes last item in dk_entries and 
decrement
dk_nentries to achieve amortized O(1).  Since there are DKIX_DUMMY remains 
in
dk_indices, we can't increment dk_usable even though dk_nentries is
decremented.

In split table, inserting into pending entry is allowed only for 
dk_entries[ix]
where ix == mp->ma_used. Inserting into other index and deleting item cause
converting the dict to the combined table.

Objects/dictobject.c::insertdict() line 1140:

if (mp->ma_keys->dk_usable <= 0) {
/* Need to resize. */
if (insertion_resize(mp) < 0) {
Py_DECREF(value);
return -1;
}
hashpos = find_empty_slot(mp->ma_keys, key, hash);
}

Objects/dictobject.c::dictresize() line 1282:

PyDictKeyEntry *ep = oldentries;
for (Py_ssize_t i = 0; i < numentries; i++) {
while (ep->me_value == NULL)
ep++;
newentries[i] = *ep++;
}

> 
> I don't know what guidance to give Eric, because I don't know what other 
> implementations do nor whether Eric cares about being compatible with those. 
> IIUC micropython does not guarantee this currently, but I don't know if they 
> claim Python 3.6 compatibility -- in fact I can't find any document that 
> specifies the Python version they're compatible with more precisely than 
> "Python 3".


I did a little research and here' what I found:

"MicroPython aims to implement the Python 3.4 standard (with selected features 
from later versions)" 
-- http://docs.micropython.org/en/latest/pyboard/reference/index.html

"PyPy is a fast, compliant alternative implementation of the Python language 
(2.7.13 and 3.5.3)."
-- http://pypy.org/

"Jython 2.7.0 Final Released (May 2015)"
-- http://www.jython.org/

"IronPython 2.7.7 released on 2016-12-07"
-- http://ironpython.net/

So, it looks like your could say 3.6 does whatever CPython 3.6 already does and 
not worry about leaving other implementations behind.  (And PyPy is actually 
ahead of us here, having compact and order-preserving dicts for quite a while).

Cheers,


Raymond

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

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Guido van Rossum]

Cool, thanks! I'm curious why this was brought up at all then...

On Dec 15, 2017 3:36 PM, "Raymond Hettinger" 
wrote:

>
>
> > On Dec 15, 2017, at 1:47 PM, Guido van Rossum  wrote:
> >
> > On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger <
> raymond.hettin...@gmail.com> wrote:
> >
> > > On Dec 15, 2017, at 7:53 AM, Guido van Rossum 
> wrote:
> > >
> > > Make it so. "Dict keeps insertion order" is the ruling.
> >
> > On Twitter, someone raised an interesting question.
> >
> > Is the guarantee just for 3.7 and later?  Or will the blessing also
> cover 3.6 where it is already true.
> >
> > The 3.6 guidance is to use OrderedDict() when ordering is required.  As
> of now, that guidance seems superfluous and may no longer be a sensible
> practice.  For example, it would be nice for Eric Smith when he does his
> 3.6 dataclasses backport to not have to put OrderedDict back in the code.
> >
> > For 3.6 we can't change the language specs, we can just document how it
> works in CPython. I don't know what other Python implementations do in
> their version that's supposed to be compatible with 3.6 but I don't want to
> retroactively declare them non-conforming. (However for 3.7 they have to
> follow suit.) I also don't think that the "it stays ordered across
> deletions" part of the ruling is true in CPython 3.6.
>
> FWIW, the regular dict does stay ordered across deletions in CPython3.6:
>
> >>> d = dict(a=1, b=2, c=3, d=4)
> >>> del d['b']
> >>> d['b'] = 5
> >>> d
> {'a': 1, 'c': 3, 'd': 4, 'b': 5}
>
> Here's are more interesting demonstration:
>
> from random import randrange, shuffle
> from collections import OrderedDict
>
> population = 100
> s = list(range(population // 4))
> shuffle(s)
> d = dict.fromkeys(s)
> od = OrderedDict.fromkeys(s)
> for i in range(50):
> k = randrange(population)
> d[k] = i
> od[k] = i
> k = randrange(population)
> if k in d:
> del d[k]
> del od[k]
> assert list(d.items()) == list(od.items())
>
> The dict object insertion logic just appends to the arrays of keys,
> values, and hashvalues.  When the number of usable elements decreases to
> zero (reaching the limit of the most recent array allocation), the dict is
> resized (compacted) left-to-right so that order is preserved.
>
> Here are some of the relevant sections from the 3.6 source tree:
>
> Objects/dictobject.c line 89:
>
> Preserving insertion order
>
> It's simple for combined table.  Since dk_entries is mostly append
> only, we can
> get insertion order by just iterating dk_entries.
>
> One exception is .popitem().  It removes last item in dk_entries and
> decrement
> dk_nentries to achieve amortized O(1).  Since there are DKIX_DUMMY
> remains in
> dk_indices, we can't increment dk_usable even though dk_nentries is
> decremented.
>
> In split table, inserting into pending entry is allowed only for
> dk_entries[ix]
> where ix == mp->ma_used. Inserting into other index and deleting item
> cause
> converting the dict to the combined table.
>
> Objects/dictobject.c::insertdict() line 1140:
>
> if (mp->ma_keys->dk_usable <= 0) {
> /* Need to resize. */
> if (insertion_resize(mp) < 0) {
> Py_DECREF(value);
> return -1;
> }
> hashpos = find_empty_slot(mp->ma_keys, key, hash);
> }
>
> Objects/dictobject.c::dictresize() line 1282:
>
> PyDictKeyEntry *ep = oldentries;
> for (Py_ssize_t i = 0; i < numentries; i++) {
> while (ep->me_value == NULL)
> ep++;
> newentries[i] = *ep++;
> }
>
> >
> > I don't know what guidance to give Eric, because I don't know what other
> implementations do nor whether Eric cares about being compatible with
> those. IIUC micropython does not guarantee this currently, but I don't know
> if they claim Python 3.6 compatibility -- in fact I can't find any document
> that specifies the Python version they're compatible with more precisely
> than "Python 3".
>
>
> I did a little research and here' what I found:
>
> "MicroPython aims to implement the Python 3.4 standard (with selected
> features from later versions)"
> -- http://docs.micropython.org/en/latest/pyboard/reference/index.html
>
> "PyPy is a fast, compliant alternative implementation of the Python
> language (2.7.13 and 3.5.3)."
> -- http://pypy.org/
>
> "Jython 2.7.0 Final Released (May 2015)"
> -- http://www.jython.org/
>
> "IronPython 2.7.7 released on 2016-12-07"
> -- http://ironpython.net/
>
> So, it looks like your could say 3.6 does whatever CPython 3.6 already
> does and not worry about leaving other implementations behind.  (And PyPy
> is actually ahead of us here, having compact and order-preserving dicts for
> quite a while).
>
> Cheers,
>
>
> Raymond
>
>
___

Re: [Python-Dev] f-strings

[Wagner Herculano]

Hi,
Thank you all for your time.
In fact I'm really a newbie and I need to study so hard (including English) to 
become someone like you all. I don't know if is possible, but I need to try.
Once again, thank you all for your time and I'm sorry if I'm bother both of you.

Kind regards,
   Wagner Herculano.


From: Chris Barker - NOAA Federal 
Sent: Friday, December 15, 2017 2:49:08 PM
To: Mariatta Wijaya
Cc: Wagner Herculano; Python Dev
Subject: Re: [Python-Dev] f-strings




That's covered under "format specifiers" I think.
The PEP mentions this: 
https://www.python.org/dev/peps/pep-0498/#format-specifiers

I can see how a newbie might not realize that that means that f-strings use the 
same formatting language as the .format() method, and or where to find 
documentation for it.

So somewhere in the docs making that really clear, with a link to the 
formatting spec documentation would be good.

Not sure where though — a PEP is not designed to be user documentation.

-CHB


That specific example is not mentioned in the docs, but there other examples of 
using format specifiers with f-strings.
https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals


On Dec 15, 2017 7:39 AM, "Wagner Herculano" 
mailto:waghercul...@hotmail.com>> wrote:
Good evening,
I'm Wagner Herculano from Brazil.
I was trying to do a table exercise with number 5 and tried formatting spaces 
and did not find it in PEP 498 documentation.
Finally I found a way, if possible, include this example in the documentation 
please.

Below is my script with the desired formatting about table of 5.

n = 5
for i in range(1,11):
print(f'{n} x {i:>2} = {n*i:>2}')

Result
5 x  1 =  5
5 x  2 = 10
5 x  3 = 15
5 x  4 = 20
5 x  5 = 25
5 x  6 = 30
5 x  7 = 35
5 x  8 = 40
5 x  9 = 45
5 x 10 = 50
---
Sorry my English, I needed to use Google Translate

Best Regards,
Wagner Herculano

___
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/mariatta.wijaya%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/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/archive%40mail-archive.com