Re: [Python-Dev] f-strings

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,

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

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 < >

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

> 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

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

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

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

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

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

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).

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

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

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

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

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

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:

Re: [Python-Dev] f-strings

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.

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

> 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.

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

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. -

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

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 ___

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

> 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:

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

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.

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

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

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

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)

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

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

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

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,

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

[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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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 >

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

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

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

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

[Python-Dev] Type creation speed

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

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

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

Re: [Python-Dev] f-strings

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]

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

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

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

On 12/15/2017 11:55 AM, Guido van Rossum wrote: On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger > wrote: > On Dec 15, 2017, at 7:53 AM, Guido van Rossum > wrote: > >

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

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

[Python-Dev] Summary of Python tracker Issues

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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 That specific example is not mentioned in the docs, but there other examples of using format specifiers with f-strings.

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

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

[Python-Dev] f-strings

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

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

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__(): > >

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

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

[Python-Dev] Make __class_getitem__ a class method

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

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

> 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

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

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

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

On 12/15/2017 5:56 AM, Steve Holden wrote: On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal > wrote: ... However, typing is not currently imported by dataclasses.py. > And there you have an actual reason besides my

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

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

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

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

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

> 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%

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

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

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

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