Re: [Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)

On 19 November 2017 at 21:06, Mark Shannon wrote: > By far and away the largest change in PEP 560 is the change to the > behaviour of object.__getitem__. This is not mentioned in the PEP at all, > but is explicit in the draft implementation. > The implementation could implement

Re: [Python-Dev] PEP 560: bases classes / confusion

On 16 November 2017 at 18:58, Ethan Furman <et...@stoneleaf.us> wrote: > On 11/16/2017 04:22 AM, Ivan Levkivskyi wrote: > >> On 16 November 2017 at 07:56, Nick Coghlan wrote: >> > > Jim also raised an important point that needs clarification at the spec >>&

Re: [Python-Dev] PEP 560: bases classes / confusion

On 16 November 2017 at 07:56, Nick Coghlan <ncogh...@gmail.com> wrote: > On 16 November 2017 at 04:39, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> Nick is exactly right here. Jim, if you want to propose alternative >> wording, then we could co

Re: [Python-Dev] PEP 560: bases classes / confusion

Nick is exactly right here. Jim, if you want to propose alternative wording, then we could consider it. -- Ivan On 15 November 2017 at 16:37, Nick Coghlan wrote: > On 16 November 2017 at 00:20, Jim J. Jewett wrote: > >> I *think* the following will

Re: [Python-Dev] PEP 562

On 15 November 2017 at 08:43, Serhiy Storchaka <storch...@gmail.com> wrote: > 14.11.17 22:34, Ivan Levkivskyi пише: > >> This function will be called only if ``name`` is not found in the module >> through the normal attribute lookup. >> > > It is worth to

[Python-Dev] PEP 562

is the addition of __dir__, as proposed by Guido. Here is the full text: + PEP: 562 Title: Module __getattr__ and __dir__ Author: Ivan Levkivskyi <levkivs...@gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 09-Sep-2017 Python-Version: 3.7 Post-H

[Python-Dev] PEP 560

/pep-0560/ Here I post the full text for convenience: ++ PEP: 560 Title: Core support for typing module and generic types Author: Ivan Levkivskyi <levkivs...@gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 03-Sep-2017 Python-Versio

Re: [Python-Dev] PEP 561 rework

Thanks Ethan for all the work! I will be glad to see this accepted and implemented in mypy. -- Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

FWIW, it is common to have syntax checks in ast.c. Especially situations like class ``C(x for x in [1]): ...`` I think would be hard to prohibit in Grammar. Since anyway we have many checks in ast.c already, I wouldn't care much about implementing these corner cases in Grammar. -- Ivan

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

I will be happy to see PEP 544 and PEP 560 in Python 3.7, and maybe also PEP 562 (if we decide on it and I will have time). -- Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 1 November 2017 at 23:48, Lukasz Langa wrote: > Runtime annotation resolution and class decorators > -- > > Metaclasses and class decorators that need to resolve annotations for > the current class will fail for annotations that

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 2 November 2017 at 18:00, Brett Cannon wrote: > > > On Thu, 2 Nov 2017 at 08:46 Steven D'Aprano wrote: > >> On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote: >> [...snip...] > > I think the performance bit is really the big deal here. > > I

Re: [Python-Dev] PEP 560 vs metaclass' class definition protections [was Re: What is the design purpose of metaclasses ...]

On 14 October 2017 at 18:14, Ethan Furman <et...@stoneleaf.us> wrote: > On 10/14/2017 08:57 AM, Ivan Levkivskyi wrote: > >> >> Could you please elaborate more what is wrong with PEP 560 and what do >> you mean by "class definition protections" >>

Re: [Python-Dev] What is the design purpose of metaclasses vs code generating decorators? (was Re: PEP 557: Data Classes)

On 14 October 2017 at 17:49, Ethan Furman wrote: > The problem with PEP 560 is that it doesn't allow the class definition > protections that a metaclass does. > Since the discussion turned to PEP 560, I can say that I don't want this to be a general mechanism, the PEP

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 14 September 2017 at 23:02, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 14 September 2017 at 22:07, Ethan Furman <et...@stoneleaf.us> wrote: > >> For comparison's sake, what would the above look like using __class__ >> assignment? And what is the performa

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 14 September 2017 at 22:07, Ethan Furman wrote: > For comparison's sake, what would the above look like using __class__ > assignment? And what is the performance difference? > > FWIW I found a different solution: # file mod.py from typing_extensions import

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 14 September 2017 at 22:21, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 14 September 2017 at 22:07, Ethan Furman <et...@stoneleaf.us> wrote: > >> >> For comparison's sake, what would the above look like using __class__ >> assignment? An

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 14 September 2017 at 22:07, Ethan Furman wrote: > > For comparison's sake, what would the above look like using __class__ > assignment? And what is the performance difference? > > Actually I tried but I can't implement this without module __getattr__ so that one can just

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

(sorry for obvious mistakes in the example in previous e-mail) On 14 September 2017 at 21:08, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 14 September 2017 at 01:13, Guido van Rossum <gu...@python.org> wrote: > >> >> That last sentence is a key observ

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 14 September 2017 at 01:13, Guido van Rossum wrote: > > That last sentence is a key observation. Do we even know whether there are > (non-toy) things that you can do *in principle* with __class__ assignment > but which are too slow *in practice* to bother? And if yes, is

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

@Guido > One would have to introduce some kind of convention > where you can write properties with a leading _ One doesn't even need the @property decorator in this case. For example: def __getattr__(name): g = globals() name = '_' + name if name in g: return g[name]()

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

@Larry > "@property" 375 hits > "def __getattr__" 28 hits I don't think it is fair to compare occurrences of __getattr__ vs occurrences of @property, since in the first case one would use a single __getattr__ per class, while in the second case @property is required for every attribute.

Re: [Python-Dev] PEP 557: Data Classes

On 10 September 2017 at 23:05, Mike Miller wrote: > [...] > As the problem this PEP is solving is orthogonal to typing improvements > This is not the case, static support for dataclasses is an import point of motivation. It is hard to support static typing for many

Re: [Python-Dev] PEP 557: Data Classes

On 9 September 2017 at 01:00, Guido van Rossum wrote: > I think it would be useful to write 1-2 sentences about the problem with > inheritance -- in that case you pretty much have to use a metaclass, > > It is not the case now. I think __init_subclass__ has almost the same

Re: [Python-Dev] Pygments in PEPs?

On 9 September 2017 at 00:14, Antoine Pitrou <solip...@pitrou.net> wrote: > On Fri, 8 Sep 2017 16:59:57 +0200 > Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > > I already made a PR that would highlight code in PEPs half-year ago, but > it &g

Re: [Python-Dev] Pygments in PEPs?

I already made a PR that would highlight code in PEPs half-year ago, but it was rejected with the reason that they will be moved to RtD soon. -- Ivan 8 Вер 2017 16:56 "Antoine Pitrou" пише: > > Hi, > > Is it possible to install pygments on the machine which builds and >

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 6 September 2017 at 17:26, Guido van Rossum wrote: > > Is there a real use case for @property? Otherwise, if we're going to mess > with module's getattro, it makes more sense to add __getattr__, which would > have made Nathaniel's use case somewhat simpler. (Except for the

Re: [Python-Dev] PEP 550 v4

On 6 September 2017 at 11:13, Nathaniel Smith <n...@pobox.com> wrote: > On Wed, Sep 6, 2017 at 1:49 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > Normal generators fall out from this "scheme", and it looks like their > > behavior is determined by

Re: [Python-Dev] PEP 550 v4

Another comment from bystander point of view: it looks like the discussions of API design and implementation are a bit entangled here. This is much better in the current version of the PEP, but still there is a _feelling_ that some design decisions are influenced by the implementation strategy.

Re: [Python-Dev] PEP 548: More Flexible Loop Control

On 6 September 2017 at 08:42, Serhiy Storchaka wrote: > 06.09.17 03:11, R. David Murray пише: > >> I've written a PEP proposing a small enhancement to the Python loop >> control statements. Short version: here's what feels to me like a >> Pythonic way to spell "repeat

Re: [Python-Dev] To reduce Python "application" startup time

On 5 September 2017 at 15:02, INADA Naoki wrote: > Hi, > > [...] > > For bare (e.g. `python -c pass`) startup time, I'm waiting C > implementation of ABC. > Hi, I am not sure I will be able to finish it this week, also this depends on fixing interactions with ABC

Re: [Python-Dev] PEP 550 v4

A question appeared here about a simple mental model for PEP 550. It looks much clearer now, than in the first version, but I still would like to clarify: can one say that PEP 550 just provides more fine-grained version of threading.local(), that works not only per thread, but even per coroutine

Re: [Python-Dev] Python startup time

I agree the start-up time is important. There is something that is related. ABCMeta is currently implemented in Python. This makes it slow, creation of an ABC is 2x slower than creation of a normal class. However, ABCs are used by many medium and large size projects. Also, both abc and

Re: [Python-Dev] Impact of Namedtuple on startup time

Interesting coincidence, just two days ago I have heard that a team at one large company completely abandoned namedtuple because of the creation time problem. Concerning _source, why it is not possible to make it a property so that all the string formatting will happen on request, thus saving

Re: [Python-Dev] PEP 544: Protocols - second round

On 22 June 2017 at 10:44, Markus Wissinger wrote: > I have to admit I am not happy with separating the concepts of 'runtime' > and 'static' types as implied by pep544. > This is not something new, already PEP 483 makes a clear distinction between types (a static

Re: [Python-Dev] PEP 544: Protocols - second round

On 1 June 2017 at 00:10, Guido van Rossum <gu...@python.org> wrote: > > On Wed, May 31, 2017 at 2:16 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> On 31 May 2017 at 00:58, Guido van Rossum <gu...@python.org> wrote: >> [...] >> >> T

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

On 30 May 2017 at 23:02, Guido van Rossum wrote: > > All in all I'm still leaning towards Naomi's original proposal -- it looks > simpler to implement as well. > > OK, I think having a bit of verbosity is absolutely fine if we win simplicity of implementation (for both static

Re: [Python-Dev] PEP 544: Protocols - second round

On 31 May 2017 at 00:58, Guido van Rossum wrote: [...] Thank you for very detailed answers! I have practically nothing to add. It seems to me that most of the Kevin's questions stem from unnecessary focus on runtime type checking. Here are two ideas about how to fix this: *

Re: [Python-Dev] PEP 544: Protocols - second round

On 28 May 2017 at 19:40, Guido van Rossum <gu...@python.org> wrote: > On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > [...] > Regarding the title, I'd like to keep the word Protocol in the title too, > so I'd go with "Proto

Re: [Python-Dev] PEP 544: Protocols - second round

On 28 May 2017 at 16:13, Kevin Conway wrote: > > Some of the possible options for the title are > It seems like you're talking about something most other languages would > refer to as "Interfaces". What is unique about this proposal that would > call for not using the

Re: [Python-Dev] PEP 544: Protocols - second round

Thanks everyone for interesting suggestions! @Antoine @Guido: Some of the possible options for the title are: * Protocols (structural subtyping) * Protocols (static duck typing) * Structural subtyping (static duck typing) which one do you prefer? @Nick: Yes, explicit imports are not necessary

[Python-Dev] PEP 544: Protocols - second round

://www.python.org/dev/peps/pep-0544/ = PEP: 544 Title: Protocols Version: $Revision$ Last-Modified: $Date$ Author: Ivan Levkivskyi <levkivs...@gmail.com>, Jukka Lehtosalo < jukka.lehtos...@iki.fi>, Łukasz Langa <luk...@langa.pl> Discussions-To: Pyth

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

On 15 May 2017 at 10:48, Koos Zevenhoven wrote: > > Here's the proposed text (wordsmithing suggestions in the PR please): > > > > +Decorators > > +-- > > + > > +Decorators can modify the types of the functions or classes they > > +decorate. Use the ``decorated_type``

Re: [Python-Dev] PEP 484 proposal: don't default to Optional if argument default is None

There is a discrepancy now between PEP 484 and PEP 526: def f(x: int = None): ... # OK x: int = None # Error I think the two rules should be "in sync", in view of this I agree with the proposal. Concerning verbosity and a long name Optional there are many reasonable workarounds. One is

Re: [Python-Dev] Type hinting: TypeError: 'type' object is not subscriptable

You should use List[int] (note capital first letter) and similar for other generic types. Please read https://docs.python.org/3/library/typing.html The fact that this is accepted by PyCharm is a PyCharm bug, and should be reported on their tracker. -- Ivan On 29 April 2017 at 14:32, Edward

Re: [Python-Dev] Is there any docstring format used inside CPython core?

On 13 April 2017 at 13:26, Louie Lu wrote: > Hi everyone, > Is there any docstring format used inside CPython core? e.g. Doxygen. > I don't think there is anything beyond https://www.python.org/dev/peps/pep-0257/ -- Ivan ___ Python-Dev

Re: [Python-Dev] PEP 544: Protocols

On 21 March 2017 at 18:03, Brett Cannon wrote: > I do think it's fine, though, to make it very clear that whether you > subclass or not makes absolutely no difference to tools validating the type > soundness of the code. > There are two places where PEP draft says: "Note that

Re: [Python-Dev] PEP 544: Protocols

On 21 March 2017 at 17:09, Matthias Kramm wrote: > > The one thing that isn't clear to me is how type checkers will distinguish > between > 1.) Protocol methods in A that need to implemented in B so that B is > considered a structural subclass of A. > 2.) Extra methods you get

Re: [Python-Dev] PEP 544: Protocols

On 21 March 2017 at 00:23, Barry Warsaw <ba...@python.org> wrote: > On Mar 20, 2017, at 01:00 PM, Ivan Levkivskyi wrote: > > [SNIP] > > IIUC, the Python 3 way to spell this is with a decorator. > Thanks, I will update this. > [SNIP] > (also, since this i

Re: [Python-Dev] PEP 544: Protocols

On 20 March 2017 at 22:11, Matthias Kramm <kr...@google.com> wrote: > I'm a big fan of this. I really want structural subtyping for > http://github.com/google/pytype. > > I am glad you like it. > > On Mon, Mar 20, 2017 at 5:00 AM, Ivan Levkivskyi <levkivs...@gmail.co

Re: [Python-Dev] PEP 544: Protocols

On 20 March 2017 at 19:07, Brett Cannon wrote: > I'm overall very supportive of seeing something like this make it into > Python to further strengthen duck typing in the language. > Thanks! > Personally, I think even an abstract method should be properly typed. > [SNIP] > or

[Python-Dev] PEP 544: Protocols

Title: Protocols Version: $Revision$ Last-Modified: $Date$ Author: Ivan Levkivskyi <levkivs...@gmail.com>, Jukka Lehtosalo < jukka.lehtos...@iki.fi>, Łukasz Langa <luk...@langa.pl> Discussions-To: Python-Dev <python-dev@python.org> Status: Draft Type: Standards Track Content-

Re: [Python-Dev] Type annotations and metaclasses

Hi Thomas, I think this question is more appropriate for mypy or typing trackers: https://github.com/python/mypy/issues https://github.com/python/typing/issues -- Ivan On 3 March 2017 at 22:56, Thomas Hauk wrote: > I’ve read through PEPs 483, 484, and 526, but I don’t

[Python-Dev] Review request: optimizing typing ABC caches

There is a PR implementing typing ABC cache optimization: https://github.com/python/typing/pull/383 The main idea is straightforward: subscripted generic ABCs like Iterable[int], Iterable[str], etc. should not have separate ABC caches (positive and negative), since they all are equivalent to

Re: [Python-Dev] Investigating Python memory footprint of one real Web application

to master? -- Ivan On 23 January 2017 at 12:25, INADA Naoki <songofaca...@gmail.com> wrote: > On Fri, Jan 20, 2017 at 8:52 PM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 20 January 2017 at 11:49, INADA Naoki <songofaca...@gmail.com> wrote: > >

Re: [Python-Dev] Generator objects and list comprehensions?

On 26 January 2017 at 00:53, Nathaniel Smith wrote: > > I'm not sure this is actually a good idea, given the potential for > ambiguity and backwards compatibility considerations -- I'm kind of leaning > towards the deprecate/error option on balance :-). But it's an option that >

Re: [Python-Dev] Generator objects and list comprehensions?

On 25 January 2017 at 07:01, Chris Angelico wrote: > >>> [(yield 1) for x in range(10)] > > at 0x10cd210f8> > This is an old bug, see e.g. http://bugs.python.org/issue10544 The ``yield`` inside comprehensions is bound to the auxiliary function. Instead it should be bound to

Re: [Python-Dev] Investigating Python memory footprint of one real Web application

1. It looks like there is still a room for performance improvement of typing w.r.t. how ABCs and issubclass() works. I will try to play with this soon. (the basic idea is that some steps could be avoided for parameterized generics). 2. I am +1 on having three separate options to independently

Re: [Python-Dev] Investigating Python memory footprint of one real Web application

On 20 January 2017 at 11:49, INADA Naoki wrote: > * typing may increase memory footprint, through functions > __attributes__ and abc. >* Can we add option to remove or lazy evaluate __attributes__ ? > This idea already appeared few times. I proposed to introduce a

Re: [Python-Dev] collections.abc for data and non-data descriptors

On 18 January 2017 at 16:35, Guido van Rossum wrote: > I'd rather wait until support for protocols has been added to PEP 484. > Sorry for offtopic but do you think this should be an addition to PEP 484 or a separate PEP? I am interested in writing the specification (based on

Re: [Python-Dev] collections.abc for data and non-data descriptors

A random thought: typing has ABCs for protocols, even more than collections.abc has (e.g. typing.SupportsInt). Some support for descriptors has been added to mypy recently. Maybe it makes sense to add support for descriptor protocol in typing? -- Ivan On 18 January 2017 at 05:44, Raymond

Re: [Python-Dev] Is explicit registration of Iterators needed?

On 7 October 2016 at 17:08, Guido van Rossum wrote: > On Fri, Oct 7, 2016 at 7:47 AM, Serhiy Storchaka > wrote: > > On 07.10.16 17:37, Guido van Rossum wrote: > >> > >> On Fri, Oct 7, 2016 at 6:36 AM, Serhiy Storchaka > >> wrote: >

Re: [Python-Dev] cpython: Issue #27999: Make "global after use" a SyntaxError, and ditto for nonlocal.

On 12 September 2016 at 12:24, Christian Heimes wrote: > The code looks suspicious. Can you please > provide a patch that makes it more obvious, e.g. either by using if / > else if / else or a comment? Sure, I will open an issue with a patch and will add you to nosy

Re: [Python-Dev] cpython: Issue #27999: Make "global after use" a SyntaxError, and ditto for nonlocal.

u...@dropbox.com> > > date:Fri Sep 09 09:36:26 2016 -0700 > > summary: > > Issue #27999: Make "global after use" a SyntaxError, and ditto for > nonlocal. > > Patch by Ivan Levkivskyi. > > > > files: > > Doc/reference/simple_

Re: [Python-Dev] PEP 526 (variable annotations) accepted provisionally

Thank you Guido! :-) -- Ivan On 7 September 2016 at 20:18, Guido van Rossum wrote: > I'm accepting PEP 526 provisionally. > > I am personally confident that this PEP is adding a useful new feature > to the language: annotations that can be used by a wide variety of > tools,

[Python-Dev] Make "global after use" a SyntaxError

Hi all, The documentation at https://docs.python.org/3/reference/simple_stmts.html says that: "Names listed in a global statement must not be used in the same code block textually preceding that global statement" But then later: "CPython implementation detail: The current implementation does

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On 6 September 2016 at 18:35, Nick Coghlan <ncogh...@gmail.com> wrote: > On 7 September 2016 at 01:33, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 6 September 2016 at 17:25, Mark Shannon <m...@hotpy.org> wrote: > >> > >> The issue i

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On 6 September 2016 at 17:25, Mark Shannon wrote: > The issue is not whether the checker can tell that the type of the > *expression* is int, but whether it is forced to use the type of the > *variable*. The current wording of PEP 526 strongly implies the latter. > Mark, Could

Re: [Python-Dev] Please reject or postpone PEP 526

On 5 September 2016 at 20:15, Guido van Rossum wrote: > There are actually at least two separate cases: if x is a local > variable, the intention of `x: ` is quite different from when x > occurs in a class. > If I understand you correctly this also matches my mental model. In

Re: [Python-Dev] Please reject or postpone PEP 526

On 4 September 2016 at 19:59, Nick Coghlan wrote: Nick, Thank you for good suggestions. > I mostly agree, but the PEP still needs to address the fact that it's > only a subset of the benefits that actually require new syntax, since > it's that subset which provides the

Re: [Python-Dev] Please reject or postpone PEP 526

On 4 September 2016 at 19:29, Nick Coghlan wrote: > So in this case, attempting to entirely defer specification of the > semantics creates a significant risk of type checkers written on the > assumption of C++ or Java style type declarations actively inhibiting > the dynamism

Re: [Python-Dev] Please reject or postpone PEP 526

On 4 September 2016 at 18:43, Nick Coghlan <ncogh...@gmail.com> wrote: > On 4 September 2016 at 21:32, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > The first form still could be interpreted by type checkers > > as annotation for value (a cast to more precise

Re: [Python-Dev] Please reject or postpone PEP 526

On 4 September 2016 at 15:07, Steven D'Aprano wrote: > > PEP 526 > > variable: annotation = value > > > > Which reads very much as if the annotation refers to the variable. > > Since the PEP makes it clear that the two forms are to be treated the > same, I think that

Re: [Python-Dev] Please reject or postpone PEP 526

On 4 September 2016 at 13:30, Mark Shannon wrote: > It would be a real shame if PEP 526 mandates against checkers doing as > good as job as possible. Forcing all uses of a variable to have the same > type is a major and, IMO crippling, limitation. > > E.g. > def

Re: [Python-Dev] Please reject or postpone PEP 526

On 4 September 2016 at 12:52, Mark Shannon wrote: > The key difference is in placement. > PEP 484 style > variable = value # annotation > > Which reads to me as if the annotation refers to the value. > PEP 526 > variable: annotation = value > > Which reads very much as if the

Re: [Python-Dev] PEP 467: last round (?)

On 4 September 2016 at 00:11, Random832 wrote: > On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote: > > I guess one reason I don't like bchr (nor chrb, really) is that they > > look just like a random sequence of letters in builtins, but not > > recognizable the way

Re: [Python-Dev] [erratum] Emotional responses to PEPs 484 and 526

On 3 September 2016 at 17:18, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Stephen J. Turnbull writes: > > > My version ... furthermore makes mypy into a units checker, > > That isn't true, mypy does want annotations on all the variables it > checks and does not infer them

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On 2 September 2016 at 18:17, Guido van Rossum <gu...@python.org> wrote: > On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > On 2 September 2016 at 04:38, Nick Coghlan <ncogh...@gmail.com> wrote: > >> However, a standalone Ellip

Re: [Python-Dev] Please reject or postpone PEP 526

On 2 September 2016 at 17:59, Guido van Rossum wrote: > On Fri, Sep 2, 2016 at 6:47 AM, Mark Shannon wrote: > > Quoting from the PEP: > > ``` > > a: int > > a: str # Static type checker will warn about this. > > ``` > > In other words, it is illegal for a

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On 1 September 2016 at 22:37, Guido van Rossum <gu...@python.org> wrote: > On Thu, Sep 1, 2016 at 9:30 AM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > There is a convention for function annotations in PEP 484 that a missing > > annotation is equivalent to Any

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On 1 September 2016 at 18:21, Steven D'Aprano wrote: > The simplest way would be to say "go on, one type hint won't hurt, > there's no meaningful runtime cost, just do it". > > from typing import Any > > class X: > NAME: Any > > Since I'm not running a type checker, it

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On 31 August 2016 at 13:09, Nick Coghlan wrote: > I guess as long as they're included somewhere in the AST for the > function body, I don't mind if the translation to bytecode throws them > away - that's essentially saying that a function level type annotation > is

[Python-Dev] review request: anti-registration of ABCs

I have unsuccessfully tried to ping the issue http://bugs.python.org/ issue25958 on "anti-registration" of implicit ABCs by setting attributes to None. Guido said: "But with the indicated fixes, I think this good to go (for Python 3.6)" I have manually "rebased" the previous patch by Andrew

Re: [Python-Dev] AutoNumber Enum

> Presumably you want a bitfield enum, and those should descend from IntEnum. Yes, and probably having an AutoNumberIntEnum would indeed be too much magic in one place. Anyway, it is easy to implement bitfield IntEnum without magic. To be clear, I like the Ethan's original proposal. -- Ivan

Re: [Python-Dev] AutoNumber Enum

It looks like the values in AutoNumberEnum are consecutive integers 1,2,3,... Have you considered an option (keyword argument) to change this to powers of two 1,2,4,8,...? -- Ivan On 29 June 2016 at 21:23, Ethan Furman wrote: > On 06/29/2016 12:11 PM, Guido van Rossum

Re: [Python-Dev] PEP 487: Simpler customization of class creation

I think in any case Type is a bad name, since we now have typing.Type (and it is completely different) I could imagine a lot of confusion. -- Ivan On 25 June 2016 at 00:17, Eric Snow wrote: > On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan

Re: [Python-Dev] Adding NewType() to PEP 484

Type clone sounds good. But I am still inclined more towards "distinct". -- Ivan 29 Тра 2016 01:04 "Chris Jerdonek" пише: > On Fri, May 27, 2016 at 9:26 PM, Guido van Rossum > wrote: > > We discussed this over dinner at PyCon, some ideas we came up

Re: [Python-Dev] Adding NewType() to PEP 484

My final vote goes to "distinct type alias". But how should we call the function? NewType? Or should we change it to DistinctAlias or something? -- Ivan 28 Тра 2016 19:14 "Guido van Rossum" пише: > Oh, another D-word! I really like distinct. > > On Sat, May 28, 2016 at

Re: [Python-Dev] Adding NewType() to PEP 484

There is another interesting idea from Twitter: call them type wrappers. -- Ivan On 28 May 2016 at 11:01, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > On 28 May 2016 at 06:26, Guido van Rossum <gu...@python.org> wrote: > > > Personally I'm still in favor of

Re: [Python-Dev] Adding NewType() to PEP 484

On 28 May 2016 at 06:26, Guido van Rossum wrote: > Personally I'm still in favor of Derived type (but I'm more into > ancient programming languages than most folks here). I could also live > with Distinguished Type. I think both "derived" and "distinguished" are OK, but I am

[Python-Dev] Adding NewType() to PEP 484

Hi, It has been proposed to enhance the typing module with a NewType function that allows to define simple unique types with almost zero runtime overhead. The PR containing actual implementation and PEP 484 update is here: https://github.com/python/typing/pull/226 Review comments are very

[Python-Dev] what is wrong with hg.python.org

Hi, https://hg.python.org/ returns 503 Service Unavailable for an hour or so. Is it a maintenance? When it is expected to end? Best regards, Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Unbound locals in class scopes

On 23 June 2015 at 05:33, Nick Coghlan ncogh...@gmail.com wrote: Also, since classes inside functions are commonly used in unit tests (at least mine :-), I worry that *any* changes in this behavior might break working code (no matter how much that working could be considered an accident,

Re: [Python-Dev] Unbound locals in class scopes

On 20 June 2015 at 18:39, Ron Adam ron3...@gmail.com wrote: On 06/20/2015 12:12 PM, Ron Adam wrote: On 06/20/2015 02:51 AM, Ivan Levkivskyi wrote: Guido said 13 years ago that this behavior should not be changed: https://mail.python.org/pipermail/python-dev/2002-April/023428.html

Re: [Python-Dev] Unbound locals in class scopes

On 21 June 2015 at 22:05, Guido van Rossum gu...@python.org wrote: On Sun, Jun 21, 2015 at 6:22 PM, Ivan Levkivskyi levkivs...@gmail.com wrote: It is still not clear whether Guido's comment still stands for not raising an UnboundLocalError in class definitions but using globals instead. Can

[Python-Dev] Unbound locals in class scopes

Hello, There appeared a question in the discussion on http://bugs.python.org/issue24129 about documenting the behavior that unbound local variables in a class definition do not follow the normal rules. Guido said 13 years ago that this behavior should not be changed:

[Python-Dev] PEP 484 wishes

Looking at PEP 484, I came up with two use cases that I felt were not catered for: 1. Specifying that a parameter should be a subclass of another (example: Type[dict] would match dict or OrderedDict; plain Type would equal type from builtins) I don't understand. What is

<    1   2