[Python-ideas] Re: Keyword arguments self-assignment

On Mon, 20 Apr 2020 at 12:19, Eric V. Smith wrote: > On 4/20/2020 7:00 AM, Steven D'Aprano wrote: > > On Mon, Apr 20, 2020 at 10:03:50AM +0200, M.-A. Lemburg wrote: > >> Guys, is it really worth saving a few hits on the auto-complete key > >> by adding even more mysterious twists to the existing

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

IIRC, black actually uses the first style you mention, so maybe you should rather discuss it there first. Otherwise this will create a weird situation where one of the most popular auto-formatter formats code in violation of PEP 8. -- Ivan On Wed, 27 Nov 2019 at 11:42, Stefano Borini wrote:

[Python-ideas] Re: Add Subscriptable ABC

Just FYI there is a closely related issue on b.p.o. https://bugs.python.org/issue25988. FWIW I am in favor of the idea, but some people are against it (see e.g. the issue). -- Ivan On Fri, 27 Sep 2019 at 17:12, Steven D'Aprano wrote: > I keep finding myself needing to test for objects that

[Python-ideas] Re: Need a core developer sponsor for a PEP

Note that there is a related PEP 585, and the outcome for this one may depend on that PEP. Anyway, I agree this should go to typing-sig list. -- Ivan On Tue, 17 Sep 2019 at 07:58, Philippe Prados wrote: > Hello, > > I would like to publish a new PEP (see here >

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

On Thu, 29 Aug 2019 at 23:48, Guido van Rossum wrote: > On Thu, Aug 29, 2019 at 3:33 PM Chris Angelico wrote: > >> On Fri, Aug 30, 2019 at 8:28 AM Guido van Rossum >> wrote: > > [...] > > > I do tink we should probably review PEP 585 before doing anything about > unions specifically -- likely

[Python-ideas] Re: Custom string prefixes

On Mon, 2 Sep 2019 at 07:04, Pasha Stetsenko wrote: > > Don't say that this proposal won't be abused. Every one of the OP's > > motivating examples is an abuse of the syntax, returning non-strings > > from something that looks like a string. > > If you strongly believe that if something looks

[Python-ideas] Re: Extend ast with types for * instead of using raw lists

On one hand I can see how this may cause little inconvenience, but on other hand this would be a breaking change, so I don't think it is realistic. Also I think this is often alleviated by using super(). Maybe it is possible to preserve backwards compatibility by making ast_list a subclass of

Re: [Python-ideas] A proper way to bring real interfaces to Python

On Mon, 6 May 2019 at 03:23, Serge Matveenko wrote: > On Sun, May 5, 2019 at 8:23 PM Stephen J. Turnbull > wrote: > > > > Serge Matveenko writes: > > > > > So, I would like to propose adding a third main object called > > > `interface` in addition to `object` and `type` and to use it to

Re: [Python-ideas] Using rightarrow "->" for typing annotation of functions

TBH, I don't think it is so bad that it requires a new syntax. But I am not strongly against it either. What I would like to add here is that if we will go with the replacement: Callable[[X, Y], Z] becomes (X, Y) -> Z then we should also go with Union[X, Y] becomes X | Y Tuple[X, Y] becomes (X,

Re: [Python-ideas] Dict joining using + and +=

On Sat, 2 Mar 2019 at 19:15, Raymond Hettinger wrote: > > > On Mar 1, 2019, at 11:31 AM, Guido van Rossum wrote: > > > > There's a compromise solution for this possible. We already do this for > Sequence and MutableSequence: Sequence does *not* define __add__, but > MutableSequence *does*

Re: [Python-ideas] Dict joining using + and +=

On Fri, 1 Mar 2019 at 14:50, Eric V. Smith wrote: > On 3/1/2019 9:38 AM, INADA Naoki wrote: > > Sorry, I'm not good at English enough to explain my mental model. > > > > I meant no skip, no ignorance, no throw away. > > > > In case of 1+2=3, both of 1 and 2 are not skipped, ignored or thrown >

Re: [Python-ideas] Dict joining using + and +=

On Fri, 1 Mar 2019 at 13:48, INADA Naoki wrote: > > > > > > Is that an invariant you expect to apply to other uses of the + > > operator? > > > > py> x = -1 > > py> x <= (x + x) > > False > > > > py> [999] <= ([1, 2, 3] + [999]) > > False > > > > Please calm down. I meant each type implements

Re: [Python-ideas] Dict joining using + and +=

On Thu, 28 Feb 2019 at 07:18, Serhiy Storchaka wrote: > [...] > > I do not understand why we discuss a new syntax for dict merging if we > already have a syntax for dict merging: {**d1, **d2} (which works with > *all* mappings). Is not this contradicts the Zen? > FWIW there are already three

Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions

On Tue, 19 Feb 2019 at 21:07, Miikka Salminen wrote: > Hi! > > To help automatic document generators and static type checkers reason more > about the code, the possible side-effects and raised exceptions could also > be annotated in a standardized way. > The idea about "checked exceptions"

Re: [Python-ideas] Discussion: Duck typing with “concepts”

I think you may be a bit late. Have you heard about PEP 544? -- Ivan On Tue, 22 Jan 2019 at 11:50, James Lu wrote: > So here’s an interesting idea, not a proposal yet. > > In C++20, a Concept is a list of Boolean expressions with a name that can > be used in place of a type in a templated

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

On Sat, 5 Jan 2019 at 02:46, David Mertz wrote: > Like everyone other than Abe in this thread, I find judicious use of > CONSTANTS to be highly readable and useful. > > Yes, there is a little wiggle room about just how constant a constant has > to be since Python doesn't have a straightforward

Re: [Python-ideas] Introduce typing.SupportsFsPath

On Tue, 9 Oct 2018 at 15:17, Eric Fahlgren wrote: > On Tue, Oct 9, 2018 at 3:16 AM Ivan Levkivskyi > wrote: > >> class PathLike(Protocol[AnyStr]): >> > > I had been working on this same problem intermittently for several months, > so thanks, but... > > er

Re: [Python-ideas] Introduce typing.SupportsFsPath

On Tue, 9 Oct 2018 at 03:13, Guido van Rossum wrote: > In typeshed there is os.PathLike which is close. You should be able to use > Union[str, os.PathLike[str]] for what you want (or define an alias). > > We generally don't want to add more things to typing that aren't closely > related to the

Re: [Python-ideas] f-string "debug" conversion

On Wed, 3 Oct 2018 at 11:45, Eric V. Smith wrote: > On 10/3/2018 3:54 AM, Steven D'Aprano wrote: > > On Tue, Oct 02, 2018 at 08:27:03PM -0400, Eric V. Smith wrote: > > > >> Here’s the idea: for f-strings, we add a !d conversion operator, which > >> is superficially similar to !s, !r, and !a. The

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, 3 Sep 2018 at 23:51, Greg Ewing wrote: > Jonathan Fine wrote: > > I've just read and article which makes a good case for providing > > pre-conditions and post-conditions. > > > > http://pgbovine.net/python-unreadable.htm > > There's nothing in there that talks about PBC-style executable

Re: [Python-ideas] Pre-conditions and post-conditions

replying to the list now... On Thu, 30 Aug 2018 at 00:11, Ivan Levkivskyi wrote: > On Wed, 29 Aug 2018 at 13:18, Steven D'Aprano wrote: > >> I didn't want to embarass Ivan any further by seemingly picking on his >> opinion about contracts being always statically checked, b

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, 27 Aug 2018 at 11:39, Steven D'Aprano wrote: > On Mon, Aug 27, 2018 at 09:24:20AM +0100, Ivan Levkivskyi wrote: > > TBH, I think one of the main points of design by contract is that > contracts > > are verified statically. > > No, that's not correct. Contracts ma

Re: [Python-ideas] Pre-conditions and post-conditions

TBH, I think one of the main points of design by contract is that contracts are verified statically. For runtime contract checking I would rather recommend hypothesis library (or similar). -- Ivan On Mon, 27 Aug 2018 at 08:05, Jacco van Dorp wrote: > Total noob speaking here, but > >

Re: [Python-ideas] Consider adding an iterable option to dataclass

On 11 August 2018 at 01:29, Eric V. Smith wrote: > On 8/10/2018 7:01 PM, Neil Girdhar wrote: > >> [...] > > [...] > >> sequence would simply inherit from collections.abc.Sequence and implement >> the two methods __len__ and __getitme__. >> > > Unless I'm misunderstanding you, this falls in to

Re: [Python-ideas] PEP 505: None-aware operators

I think I am with Michael here. I like the parallel between `??` and `or`, we don't have `or=`, so `??=` is also not needed. Although I understand a parallel between `obj.attr` and `obj['attr']`, I think there is an additional point (in addition to two valid points by Michael) why I don't like

Re: [Python-ideas] Where should grouping() live (was: grouping / dict of lists)

On 4 July 2018 at 11:25, Steven D'Aprano wrote: > On Wed, Jul 04, 2018 at 11:08:05AM +0100, Ivan Levkivskyi wrote: > > Replying to the question in subject, I think it would be better in > > collections as a class. > > Having it just as a function doesn't buy much, because

Re: [Python-ideas] Where should grouping() live (was: grouping / dict of lists)

Replying to the question in subject, I think it would be better in collections as a class. Having it just as a function doesn't buy much, because one can do the same with three lines and a defaultdict. However, if this is a class it can support adding new elements, merge the groupeddicts, etc.

Re: [Python-ideas] Should nested classes in an Enum be Enum members?

On 1 July 2018 at 20:47, Ethan Furman wrote: > On 07/01/2018 06:03 AM, Ivan Levkivskyi wrote:> On 27 June 2018 at 15:46, > Ethan Furman wrote: > > [...] >>> So I'm asking the community: What real-world examples can you offer for >>> either behavior? Case

Re: [Python-ideas] Should nested classes in an Enum be Enum members?

Replying to the list this time. On 27 June 2018 at 15:46, Ethan Furman wrote: > [...] > So I'm asking the community: What real-world examples can you offer for > either behavior? Cases where nested classes should be enum members, and > cases where nested classes should not be members. > I

Re: [Python-ideas] Add a __cite__ method for scientific packages

On 28 June 2018 at 01:19, Nathaniel Smith wrote: > On Wed, Jun 27, 2018 at 2:20 PM, Andrei Kucharavy > wrote: > > To remediate to that situation, I suggest a __citation__ method > associated > > to each package installation and import. Called from the __main__, > > __citation__() would scan

Re: [Python-ideas] Copy (and/or pickle) generators

> > [snip] > > As Python is being increasingly used for data science, this use case will > be increasingly common. Being able to copy generators will save a lot of > work. > > Keep in mind, I don't necessarily propose that generators should be fully > picklable; there are obviously a number of

Re: [Python-ideas] Check type hints in stack trace printing

On 14 June 2018 at 12:03, Daniel Sánchez Fábregas < daniel.sanchez.fabre...@xunta.gal> wrote: > My idea consist in: > Adding a method to perform type checking in traceback objects > When printing stack traces search for mistyped arguments and warn about > them to the user. > > Don't know if it is

Re: [Python-ideas] Change magic strings to enums

On 25 April 2018 at 12:01, Serhiy Storchaka <storch...@gmail.com> wrote: > 25.04.18 13:15, Ivan Levkivskyi пише: > >> Hm, this is what I wanted to know. I think by rewriting EnumMeta in C we >> can reduce the creation time of an Enum class >> (almost) down to the c

Re: [Python-ideas] Change magic strings to enums

On 25 April 2018 at 11:03, Serhiy Storchaka <storch...@gmail.com> wrote: > 25.04.18 10:57, Ivan Levkivskyi пише: > >> On 25 April 2018 at 06:03, INADA Naoki <songofaca...@gmail.com > songofaca...@gmail.com>> wrote: >> enum class creation cost is muc

Re: [Python-ideas] Change magic strings to enums

On 25 April 2018 at 06:03, INADA Naoki wrote: > On Wed, Apr 25, 2018 at 12:04 PM, Nick Coghlan wrote: > > On 25 April 2018 at 04:56, Ethan Furman wrote: > >> On 04/24/2018 10:32 AM, Antoine Pitrou wrote: > >> > >>> Also beware the

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 19:47, Paul Moore <p.f.mo...@gmail.com> wrote: > On 27 March 2018 at 19:43, Ethan Furman <et...@stoneleaf.us> wrote: > > On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote: > >> > >> On 27 March 2018 at 18:19, Guido van Rossum wrote: > >

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 19:43, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote: > >> On 27 March 2018 at 18:19, Guido van Rossum wrote: >> > > Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope >>>

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 18:19, Guido van Rossum wrote: > On Tue, Mar 27, 2018 at 6:56 AM, Nick Coghlan wrote: > >> [...] The implicit functions used in the >> comprehension & generator expression cases are just potentially >> simpler to handle, as we don't care

Re: [Python-ideas] Dataclasses, keyword args, and inheritance

It is possible to pass init=False to the decorator on the subclass (and supply your own custom __init__, if necessary): @dataclass class Foo: some_default: dict = field(default_factory=dict) @dataclass(init=False) # This works class Bar(Foo): other_field: int -- Ivan On 23 January

Re: [Python-ideas] Improve ABCs _dump_registry() readability

On 31 December 2017 at 20:05, Antoine Pitrou <solip...@pitrou.net> wrote: > On Sun, 31 Dec 2017 19:31:06 +0100 > Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > > On 31 December 2017 at 19:24, Yahya Abou 'Imran via Python-ideas < > > python-ideas@pyth

Re: [Python-ideas] Improve ABCs _dump_registry() readability

On 31 December 2017 at 19:24, Yahya Abou 'Imran via Python-ideas < python-ideas@python.org> wrote: > > >I guess a PR to fix the registry output would make sense (first file a > bug on bugs.python.org for it). > > Ok, I will! > > Please don't hurry with this. I am going to rewrite ABCMeta in C

Re: [Python-ideas] Repr of lambda

Serhiy, I like the idea, but in typeshed we have an agreement to always show a default value by an ellipsis. For example, definition like this: def fun(x, y, z=0): return x + y + z can be represented like this fun(x, y, z=...) or if one has annotations in the definition, then fun(x: int,

Re: [Python-ideas] Stub class for Generic to further improve PEP 560

On 1 December 2017 at 00:34, Ilya Kulakov wrote: > Anyway, my expectation is that going along this way (i.e. removing all > runtime API apart from a necessary minimum) > will give a minor speed-up as compared to PEP 560 at the cost of a > breaking change (even for small

Re: [Python-ideas] Stub class for Generic to further improve PEP 560

On 30 November 2017 at 22:38, Ilya Kulakov wrote: > A very rough implementation: > > typing.py: > > class _GenericMetaNoop(type): > def __getitem__(self, params): > return self > > class _GenericNoop(metaclass=_GenericMetaNoop) > pass >

Re: [Python-ideas] Stub class for Generic to further improve PEP 560

On 30 November 2017 at 22:25, Ilya Kulakov wrote: > My point is to have a class with public interface identical to > typing.Generic, but without all runtime overhead. > It's based on the assumption that few developers benefit with > typing.Generic addition during

Re: [Python-ideas] Add a dict with the attribute access capability

On 29 November 2017 at 20:11, Barry Warsaw wrote: > Serhiy Storchaka wrote: > > In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it > > already was deprecated when the plistlib module was added to the regular > > stdlib in Python 2.6. > > > > Raymond noticed

Re: [Python-ideas] Should Python have user-defined constants?

On 21 November 2017 at 14:22, Kirill Balunov wrote: > It is not set in stone, but it looks like most people like Final (although >> the initial proposal was Const, see https://github.com/python/mypy >> /issues/1214) >> > > > Ivan, you mean this thread "Can't index named

Re: [Python-ideas] Should Python have user-defined constants?

On 21 November 2017 at 12:12, Stéfane Fermigier wrote: > That's one way to do it with no changes to the language, though > syntaxically I find it lacking a bit of elegance (maybe a matter of getting > accustomed with it?). > > Also, I'm not sure "Final" really conveys what it

Re: [Python-ideas] Should Python have user-defined constants?

On 21 November 2017 at 10:47, Paul Moore wrote: > -1. I don't see how this would improve any programs I've written or > seen. Tools like mypy or linters might benefit from a feature to track > constants and ensure they don't get changed > It is actually likely that

Re: [Python-ideas] Terminology of types / typing [was: PEP 560 (second post)]

At some point it was proposed to distinguish two things: types (static) and classes (runtime). I don't think we need more fine grained terminology here. -- Ivan On 15 November 2017 at 17:54, Koos Zevenhoven wrote: > On Wed, Nov 15, 2017 at 1:41 PM, Koos Zevenhoven

Re: [Python-ideas] Complete typing.Union with the rest of set-like functions

Intersection has already been proposed, see https://github.com/python/typing/issues/213 But it is not yet implemented. You can show your use cases on the typing issue tracker, maybe they can be covered by Intersection (which will be most probably added at some point). -- Ivan On 13 November

Re: [Python-ideas] PEP 562

On 10 November 2017 at 22:27, Guido van Rossum wrote: > Picking up this thread as part of the PEP 562 and PEP 549 review. I like > PEP 562 most, but I propose to add special-casing for `__dir__`. Not quite > as proposed above (making the C level module_dir() look for `__all__`)

Re: [Python-ideas] PEP 560 (second post)

On 10 November 2017 at 21:19, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Fri, Nov 10, 2017 at 8:33 PM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> On 10 November 2017 at 18:39, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> >>> O

Re: [Python-ideas] PEP 560 (second post)

On 10 November 2017 at 18:39, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> ​ >> > ​ >> After creating the class, >> the original bases are saved in ``

Re: [Python-ideas] PEP 560 (second post)

On 10 November 2017 at 17:43, Guido van Rossum wrote: > Hey Ivan, > > There seem to be some action items from this thread that I haven't seen > reflected in the PEP source code yet. > [...snip...] > Then the next step I propose is a PR with a full implementation. After > that

Re: [Python-ideas] install pip packages from Python prompt

Just another random idea: What about simply having two menu items in IDLE: * Install/update package manager * Open package manager The first one will install the pipgui from PyPI (and pip if not already installed). The second one will run the GUI. This way it looks like pipgui can be simply

Re: [Python-ideas] install pip packages from Python prompt

I think it was proposed several times before, but I just wanted to revive the idea that we could add a GUI interface to install/update packages from IDLE (maybe even with some package browser). -- Ivan ___ Python-ideas mailing list

Re: [Python-ideas] PEP 561: Distributing Type Information V3

Thanks Ethan! The PEP draft now looks good to me. I think it makes sense to make a PoC implementation of the PEP at this point to see if everything works smoothly in practice. (You could also link few examples with your PoC implementation in the PEP) -- Ivan On 6 October 2017 at 22:00, Ethan

Re: [Python-ideas] PEP 560 (second post)

On 29 September 2017 at 08:57, Nick Coghlan <ncogh...@gmail.com> wrote: > On 29 September 2017 at 08:04, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> How would you feel about calling it "__mro_entry__", as a mnemonic for > >> "the

Re: [Python-ideas] PEP 560 (second post)

On 29 September 2017 at 10:14, Victor Stinner wrote: > > Title: Core support for generic types > > Would it be possible to mention "typing" somewhere in the title? If > you don't know the context, it's hard to understand that the PEP is > related to type annotation and

Re: [Python-ideas] PEP 560 (second post)

On 28 September 2017 at 08:27, Nick Coghlan <ncogh...@gmail.com> wrote: > On 27 September 2017 at 19:28, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > If an object that is not a class object appears in the bases of a class > > definition, the ``_

Re: [Python-ideas] PEP 560 (second post)

On 27 September 2017 at 18:08, Terry Reedy <tjre...@udel.edu> wrote: > On 9/27/2017 5:28 AM, Ivan Levkivskyi wrote: > > It is proposed to add two special methods ``__class_getitem__`` and >> ``__subclass_base__`` to the core CPython for better support of >> ge

[Python-ideas] PEP 560 (second post)

: 560 Title: Core support for generic types Author: Ivan Levkivskyi <levkivs...@gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 03-Sep-2017 Python-Version: 3.7 Post-History: 09-Sep-2017 Abstract Initially PEP 484 was designed in such way that it

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

> The difference in allocated memory is over 22 MB. > The import time with annotations is over 2s longer. > The problem with those numbers that we still have 80% functions to cover. This will not be a problem with PEP 560 (I could imagine that string objects may take actually more memory than

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

In principle, I like this idea, this will save some keystrokes and will make annotated code more "beautiful". But I am quite worried about the backwards compatibility. One possible idea would be to use __future__ import without a definite deprecation plan. If people will be fine with using

Re: [Python-ideas] PEP 562

@Anthony > module.__getattr__ works pretty well for normal access, after being > imported by another module, but it doesn't properly trigger loading by > functions defined in the module's own namespace. The idea of my PEP is to be very simple (both semantically and in terms of implementation).

[Python-ideas] PEP 560

I have written another short PEP that proposes some minor changes to core CPython interpreter for better support of generic types. I will be grateful for comments and suggestions: https://www.python.org/dev/peps/pep-0560/ -- Ivan ___ Python-ideas

[Python-ideas] PEP 562

I have written a short PEP as a complement/alternative to PEP 549. I will be grateful for comments and suggestions. The PEP should appear online soon. -- Ivan *** PEP: 562 Title: Module __getattr__ Author: Ivan Levkivskyi <levk

Re: [Python-ideas] More Metadata for Variable Annotations

Hi Bagrat, Thanks for a detailed proposal! Indeed, some projects might want to have some additional metadata attached to a variable/argument besides its type. However, I think it would be more productive to first discuss this on a more specialized forum like

Re: [Python-ideas] namedtuple nit...

This error message is the same for types with __slots__, and probably it is indeed a bit too terse. -- Ivan On 27 July 2017 at 18:26, Chris Barker wrote: > Since we are talking about namedtuple and implementation, I just noticed: > > In [22]: Point =

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

On 20 July 2017 at 19:51, INADA Naoki <songofaca...@gmail.com> wrote: > On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > To be honest, I am not very happy with addition of a new special class. > > Imagine that the PEP 544 w

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

To be honest, I am not very happy with addition of a new special class. Imagine that the PEP 544 will be accepted (and I hope so). Then we would have, abstract classes, abstract base classes, and protocols. I think users will be overwhelmed by having three similar concepts instead of one. I think

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

Something probably not directly related, but since we started to talk about syntactic changes... I think what would be great to eventually have is some form of pattern matching. Essentially pattern matching could be just a "tagged" unpacking protocol. For example, something like this will

Re: [Python-ideas] a new namedtuple

Just FYI, typing.NamedTuple is there for almost a year and already supports default values, methods, docstrings etc. Also there is ongoing work towards dataclasses PEP, see https://github.com/ericvsmith/dataclasses So that would keep namedtuple API as it is, and focus only on performance

Re: [Python-ideas] Runtime types vs static types

@ Koos Zevenhoven > and there should at least *exist* a well-defined answer to whether an object is in 'instance' of a given type. (Not sure if 'instance' should be world used here) Let me illustrate why being an "instance" (or any other word) does not apply well to runtime objects. Consider a

Re: [Python-ideas] Runtime types vs static types

Sorry, I was not able to completely digest the OP, but I think there are some points I need to clarify. 1. Distinction between runtime classes and static types is quite sane and a simple idea. A runtime class is something associated with an actual object, while static type is something associated

Re: [Python-ideas] ImportError raised for a circular import

On 14 June 2017 at 09:59, Paul Moore wrote: > On 13 June 2017 at 23:36, Chris Angelico wrote: > > On Wed, Jun 14, 2017 at 8:10 AM, Mahmoud Hashemi > wrote: > >> I didn't interpret the initial email as wanting an error on *all* >

Re: [Python-ideas] π = math.pi

On 3 June 2017 at 21:55, MRAB wrote: > [...] >> > > Interestingly, '_' doesn't have that property, although Python does allow > identifiers to start with it. Yes, it is special cased: if (!_PyUnicode_IsXidStart(first) && first != 0x5F /* LOW LINE */)

Re: [Python-ideas] π = math.pi

On 3 June 2017 at 01:29, Guido van Rossum wrote: > Are those characters not considered Unicode letters? Maybe we could add > their category to the allowed set? > > Yes, they are not considered letters, they are in category Sm. Unfortunately, +, -, |, and other symbol that

Re: [Python-ideas] π = math.pi

On 3 June 2017 at 00:55, Guido van Rossum wrote: > [...] > So, I am still in favor of the rule "only ASCII in the stdlib". > But what about the other question? Currently, integral, sum, infinity, square root etc. Unicode symbols are all prohibited in identifiers. Is it

Re: [Python-ideas] π = math.pi

On 2 June 2017 at 12:17, Giampaolo Rodola' wrote: > On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka > wrote: > >> What you are think about adding Unicode aliases for some mathematic names >> in the math module? ;-) >> >> math.π = math.pi >> math.τ =

Re: [Python-ideas] π = math.pi

Although it is trivial, I like the idea (except for math.e maybe). (And it would be cool to be able to also write ∑ = sum, etc.) -- Ivan On 1 June 2017 at 08:47, Serhiy Storchaka wrote: > What you are think about adding Unicode aliases for some mathematic names > in the

Re: [Python-ideas] PEP 526: why ClassVar instead of ClassAttr?

On 18 May 2017 at 17:25, Brett Cannon <br...@python.org> wrote: > On Wed, May 17, 2017, 09:33 Ivan Levkivskyi, <levkivs...@gmail.com> wrote: > >> On 17 May 2017 at 11:03, Steven D'Aprano <st...@pearwood.info> wrote: >> >>> On Tue, May 16, 201

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

On 17 May 2017 at 20:09, Sven R. Kunze wrote: > Hi Stephan, > > On 17.05.2017 08:49, Stephan Houben wrote: > >> 2. Not subclassed from tuple. I have been bitten by this subclassing >> when trying to set up >> singledispatch on sequences and also on my classes. >> > > Would

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

On 17 May 2017 at 19:40, Juancarlo Añez <apal...@gmail.com> wrote: > > On Wed, May 17, 2017 at 12:48 PM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> class Foo(NamedTuple): >> """Foo is a very important class and >> you sho

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

On 17 May 2017 at 18:38, Stephan Houben wrote: > Hi Sven, > > > But even given that (and I am only speaking for my team), I haven't even > > seen a use-case for namedtuples in a year. Every time we considered it, > > people said: "please make it its own class for

Re: [Python-ideas] Optional parameters without default value

On 2 March 2017 at 13:20, Paul Moore wrote: > On 2 March 2017 at 11:31, Stephan Houben wrote: > > NoDefault would be special syntax so that this would be disallowed: > > > > f(NoDefault) > > [...] > > So I guess I'm +0.5 on the proposed "positional

Re: [Python-ideas] Optional parameters without default value

On 2 March 2017 at 09:36, M.-A. Lemburg wrote: > On 02.03.2017 09:03, Serhiy Storchaka wrote: > > Function implemented in Python can have optional parameters with default > [...] > Why a new syntax ? Can't we just have a pre-defined sentinel > singleton NoDefault and use that

Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins

On 28 February 2017 at 23:19, Victor Stinner wrote: > 2017-02-28 13:17 GMT+01:00 Michel Desmoulin : > > We have the immutable frozenset for sets and and tuples for lists. > > > > But we also have something to manipulate dict as immutable >

Re: [Python-ideas] List indexing multiple elements

On 20 February 2017 at 22:05, Jonathan Goble wrote: > On Mon, Feb 20, 2017 at 3:55 PM Ryan Gonzalez wrote: > >> - Right now, a[b,c] is already valid syntax, since it's just indexing a >> with the tuple (b, c). The proposal is to make this a specialization

[Python-ideas] Built-in function to run coroutines

Hi, async/await syntax is a very nice recent feature, but there is something that I miss for coroutines defined with async def, as compared to generators. Coroutines represent an interesting mental model that goes beyond only asynchronous IO, so that I play with them in REPL often. But there is

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 16 October 2016 at 06:47, Chris Angelico wrote: > On Sun, Oct 16, 2016 at 3:44 PM, Greg Ewing > wrote: > > Steven D'Aprano wrote: > > > >> This thread is a huge, multi-day proof that people do not agree that > this > >> is a "reasonable"

Re: [Python-ideas] Improve error message when missing 'self' in method definition

On 5 October 2016 at 20:55, Yury Selivanov wrote: > > Speaking of, I'm not much of a C hacker, and messing with CPython internals >> is a little daunting. If anyone wants to take this on, you have my >> blessing. I also may take a shot at implementing this idea in the

Re: [Python-ideas] Delay evaluation of annotations

On 22 September 2016 at 22:02, אלעזר wrote: > On Thu, Sep 22, 2016 at 10:58 PM David Mertz wrote: > >> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote: >> >>> I think we're talking about different things here. I just referred to >>> the

Re: [Python-ideas] Generics Syntax

On 15 September 2016 at 11:21, אלעזר wrote: > This suggestion is so obvious that it's likely has been discussed, but I > can't find any reference (It's not what PEP-3124 talks about). > > You might want to read this tread https://github.com/python/typing/issues/211 and another

Re: [Python-ideas] Fwd: Null coalescing operator

On 12 September 2016 at 09:05, Michel Desmoulin wrote: > In the form of: > > val = do_thing() except ThingError: "default" > > [...] > > But it also can deal with many common operations in Python without the > need to add more operators or variants: > > val =

Re: [Python-ideas] Typecheckers: there can be only one

On 8 September 2016 at 00:00, Paul Moore wrote: > > Type annotations are code, not tests. > > Not in Python they aren't. > Well, to a certain extent. One can try something like this in REPL: from typing import get_type_hints import __main__ s: str class C: x: int

Re: [Python-ideas] SI scale factors in Python

On 26 August 2016 at 18:35, Steven D'Aprano wrote: > I think that units are orthogonal to types: I can have a float of unit > "gram" and a Fraction of unit "gram", and they shouldn't necessarily be > treated as the same type. I think you are mixing here what I sometimes call

Re: [Python-ideas] SI scale factors in Python

On 26 August 2016 at 14:49, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 26 August 2016 at 13:01, Steven D'Aprano <st...@pearwood.info> wrote: > >> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote: >> > On 8/25/16, Ken Kundert &l

Re: [Python-ideas] SI scale factors in Python

On 26 August 2016 at 13:01, Steven D'Aprano wrote: > On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote: > > On 8/25/16, Ken Kundert wrote: > > > > [...] > > > > > Just allowing the units to be present, even it not > > > > > > retained,

  1   2   >