[Python-Dev] Re: Tagged pointer experiment: need help to optimize

On Wed, 23 Sep 2020 at 11:42, Mark Shannon wrote: > > > On 23/09/2020 9:47 am, Ivan Levkivskyi wrote: > > > > > > On Wed, 23 Sep 2020 at 01:19, Guido van Rossum > <mailto:gu...@python.org>> wrote: > > > > On Tue, Sep 22, 2020 at 4:58 PM Gr

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

On Wed, 23 Sep 2020 at 01:19, Guido van Rossum wrote: > On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing > wrote: > >> What are you trying to achieve by using tagged pointers? >> >> It seems to me that in a dynamic environment like Python, tagged >> pointer tricks are only ever going to reduce memory

[Python-Dev] Re: PEP 617: New PEG parser for CPython

These are good news. I think the new parser is indeed both simpler and more flexible - great! -- Ivan On Thu, 2 Apr 2020 at 19:19, Guido van Rossum wrote: > Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros > Nikolaou and myself have been working on a new parser for

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On Fri, 24 Jan 2020 at 10:05, Victor Stinner wrote: > > The proposal is to give one year to project maintainers to drop Python > 2.7 support, since Python 2.7 end of support just happened a few weeks > ago (2020-01-01). > IMO creating this kind of "gray areas" in support and deprecation issues

[Python-Dev] Re: Should set objects maintain insertion order too?

On Tue, 17 Dec 2019 at 11:48, Paul Moore wrote: > On Tue, 17 Dec 2019 at 11:13, Larry Hastings wrote: > > I lack this strongly mathematical view of sets others have espoused; > instead I view them more like "dicts without values". I'm therefore > disgruntled by this inconsistency between what

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

Just wanted to add my +1 to this idea. Moving it to ast module will add little maintenance costs, but will make it easier to use. -- Ivan On Tue, 19 Nov 2019 at 00:46, Pablo Galindo Salgado wrote: > Hi, > > What do people feel about exposing Tools/parser/unparse.py in the standard > library?

[Python-Dev] Re: Implementation of PEP-0604

To add some more input about forward references, here are couple of thoughts: 1. I think ideally we should support forward references to the same extent they are currently supported: i.e. Union[None, "ForwardRef"], Union["OtherForwardRef", None], and Union["ForwardRef", "OtherForwardRef"] should

[Python-Dev] Re: Implementation of PEP-0604

On Thu, 31 Oct 2019 at 23:20, Nick Coghlan wrote: > [...snip...] > >> >> It's not enough to move the typing classes, I must move >> functools.lru_cache() and dependencies, collections.abs.Mapping and >> dependencies, and track the frame level. >> >> *It's too big for me.* >> >> > It's certainly

[Python-Dev] Re: Migrate typing in builtin

You will need to rewrite most of things in C. -- Ivan On Tue 8 Oct 2019, 08:53 Philippe Prados, wrote: > Ok, > > But _GenericAlias and dependencies are written with Python > (Lib/typing.py), not with C. > So, I must rewrite the _GenericAlias in C or it's possible to merge the C > and Python

[Python-Dev] Re: Migrate typing in builtin

On Mon, 7 Oct 2019 at 17:16, Guido van Rossum wrote: > Hi Philippe, > > Maybe the implementation of `_GenericAlias` should live in > Objects/typobject.c, and be a part of the public API. Then the "|" overload > on PyType_Type (also there) can reference it directly, it can be exported > from

[Python-Dev] Re: typing: how to use names in result-tuples?

On Mon, 12 Aug 2019 at 11:24, Christian Tismer wrote: > On 12.08.19 10:52, Ivan Levkivskyi wrote: > > On Thu, 8 Aug 2019 at 17:17, Christian Tismer > <mailto:tis...@stackless.com>> wrote: > > > > Yes, that's what I mean. > > Probably retval or w

[Python-Dev] Re: typing: how to use names in result-tuples?

On Thu, 8 Aug 2019 at 17:17, Christian Tismer wrote: > Yes, that's what I mean. > Probably retval or whatever people prefer would be adequate, > with a special rule if that name is taken. > > I think btw. that using StructSequence(somename=sometype, ..., ) that > does a dict lookup is quite

[Python-Dev] Re: Enum and annotations

On Mon, 10 Jun 2019 at 22:37, Ethan Furman wrote: > Greetings! > > I saw my first annotation mix-up with regards to Enum today: > >https://stackoverflow.com/q/56532591/208880 > > #enum import: > from enum import Enum > > # enum definition: > class Status(Enum): >

Re: [Python-Dev] Definition of equality check behavior

On Tue, 7 May 2019 at 22:31, Jordan Adler wrote: > Hey folks! > > Through the course of work on the future polyfills > that mimic > the behavior of Py3 builtins across versions of Python, we've discovered > that the equality check

Re: [Python-Dev] Any core dev event plans for EP19?

Hi, I want to come to EP this year, but didn't register yet, is registration already open? -- Ivan On Thu, 25 Apr 2019 at 15:01, Stefan Behnel wrote: > Hi core devs, > > there are several core dev events happening at the US PyCon this year, so I > was wondering if we could organise

Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm

Mypy doesn't use source code of stlib for analysis and instead uses stub files from typeshed. IIUC PyCharm can also do that (i.e. use the typeshed stubs). The whole idea of typeshed is to avoid changing stlib solely for the sake of static analysis. Please open an issue on typeshed an/or PyCharm

Re: [Python-Dev] Source of truth for C-API

r > > Le mer. 23 janv. 2019 à 16:24, Ivan Levkivskyi a > écrit : > > > > Thanks for advice Victor and Steve! > > > > I looked at the list, and the two functions I mentioned are not in the > list. So I assume the best strategy for now is to wait until first

Re: [Python-Dev] Source of truth for C-API

Thanks for advice Victor and Steve! I looked at the list, and the two functions I mentioned are not in the list. So I assume the best strategy for now is to wait until first alpha-beta releases are out, and see if anyone complains. -- Ivan On Wed, 23 Jan 2019 at 06:58, Steve Dower wrote: >

[Python-Dev] Source of truth for C-API

Hi, I recently modified signatures of two functions PyNode_AddChild() and PyParser_AddToken(). These two functions are not listed in C-API docs on docs.python.org, and are not included in Python.h. However, their names look like they may be part of C-API. So there appeared a question, what is the

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

Do we have a b.p.o. issue about this? If no, then I would recommend to open one, so that we will not loose track of this. -- Ivan On Sat, 22 Sep 2018 at 16:32, David Hagen wrote: > The new postponed annotations have an unexpected interaction with > dataclasses. Namely, you cannot get the

Re: [Python-Dev] switch statement

> There have been several promising posts to python-ideas about the much more powerful idea of a "match" statement I actually even started working on a PEP about this (pattern matching), but then decided to postpone it because it is unlikely that anything of this size can be discussed/accepted in

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On 12 July 2018 at 16:41, Victor Stinner wrote: > 2018-07-12 17:14 GMT+02:00 Abdur-Rahmaan Janhangeer >: > > sorry for reviving the dead but community acceptance, a fundamental pep > > principle has not been respected for 572 > > > > also 29 core devs dislike vs 3 like > > [...] *as the PEP

Re: [Python-Dev] Tone it down on Twitter?

Just to clarify, the club of three in _my_ twit are the three authors of the PEP. Also, how about you not telling me what to say? -- Ivan On 4 July 2018 at 16:48, Stefan Krah wrote: > > Apparently I have made it into "club of three who don't care much about > opinions of others" for the

Re: [Python-Dev] PEP 544 (Protocols): adding a protocol to a class post-hoc

On 30 June 2018 at 23:54, Tin Tvrtković wrote: > [...] > > An attrs class has a special class-level field, __attrs_attrs__, which > holds the attribute definitions. So maybe we can define a protocol: > > class AttrsClass(Protocol): > __attrs_attrs__: ClassVar[Tuple[Attribute, ...]] > > then

Re: [Python-Dev] Intent to accept PEP 561 -- Distributing and Packaging Type Information

Congrats Ethan, Well done! I think PEP 561 will significantly simplify typing third party modules. -- Ivan On 28 June 2018 at 00:11, Guido van Rossum wrote: > Well, with that, I am hereby accepting PEP 561. > > Ethan has done a tremendous job writing this PEP and implementing it, and > I am

Re: [Python-Dev] Python3.7 backwards incompatible

> I'm wondering about your claim that this breaks many "libraries that use > annotations". Most code using annotations would not need to use > issubclass() in this way. Where exactly did you encounter this? > > I'm CC'ing Ivan Levkivskyi, who knows the relevant cod

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 19 June 2018 at 13:02, Nick Coghlan wrote: > On 19 June 2018 at 16:12, INADA Naoki wrote: > > > > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer > wrote: > >> > >> On 2018-06-18 16:55, INADA Naoki wrote: > >> > Speeding up most python function and some bultin functions was very > >> >

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

> But cases not supported before 3.7 (like List[int]) now produce fragile pickles. List[int] pickled in 3.7 can't be un-pickled in 3.6, but I wouldn't worry too much about this because it never worked in 3.6. I remember you proposed using __getitem__ in __reduce__, but I am not sure it is a

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

> 2. Pickle support in typing is not perfect. I was going to fix it (I had almost ready code), but lost a chance of doing this before. It can be changed in 3.7.1, but this means that pickles of some derived typing types created in 3.7.0 will be not compatible with future versions (may be 3.7.1

Re: [Python-Dev] Slow down...

On 7 May 2018 at 17:32, Brett Cannon wrote: > > > On Mon, 7 May 2018 at 08:18 João Santos wrote: > >> Hi, >> >> I would like to see this go even further and have a tick-tock approach to >> python versions, i.e. adopt new syntax and other large changes on one

Re: [Python-Dev] Slow down...

On 7 May 2018 at 03:25, Nick Coghlan wrote: > On 7 May 2018 at 11:30, Dan Stromberg wrote: > >> I'd very much like a live in a world where Jython and IronPython and >> MicroPython and Cython and Pyjamas can all catch up and implement >> Python 3.7, 3.8,

Re: [Python-Dev] PEP 572: Assignment Expressions

On 24 April 2018 at 08:12, Greg Ewing wrote: > Chris Jerdonek wrote: > > if (diff := x - x_base) and (g := gcd(diff, n)) > 1: >>> > "if diff, which we let equal x - x_base, and g, which ..." or >> "if diff, which we set equal to x - x_base, and g, which " or

Re: [Python-Dev] PEP 561 implemented and minor clarification

On 12 April 2018 at 09:59, Ethan Smith wrote: > Hello, > > I've updated PEP 561 to clarify that any installed stub package should > supersede an installed inline package. In other words if there is: > > /global/site-packages/pkg/ > /user/site-packages/pkg-stubs/ > > Even if pkg

Re: [Python-Dev] PEP 572: Assignment Expressions

Replying also to the list. On 22 April 2018 at 09:14, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 20 April 2018 at 21:59, Guido van Rossum <gu...@python.org> wrote: > >> Does the PEP currently propose to *allow* that horrible example? I >> thought Tim Peters

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

On 22 February 2018 at 10:55, Eric V. Smith wrote: > On 2/22/2018 1:56 AM, Raymond Hettinger wrote: > >> Other immutable classes in Python don't behave the same way: > > >> >>> class T(tuple): >> pass >> >> >>> t = T([10, 20, 30]) >> >>> t.cached =

Re: [Python-Dev] How is the GitHub workflow working for people?

> I'm personally hugely happy with the new workflow -- my only regret is that we're not using GitHub for issue tracking yet. I have the same feelings. I like the GitHub issue tracker, and it would be great to migrate there (if possible). -- Ivan On 21 February 2018 at 21:22, Guido van Rossum

Re: [Python-Dev] Dataclasses and correct hashability

Just wanted to add my 5 cents here. I am a bit surprised how people are scared by adding `__hash__` to mutable classes. >From my experience it is quite normal, I was always thinking about `hash()` as hashing a _value_, and never as hashing _identity_, if I would need the latter, there is a

Re: [Python-Dev] Why wont duplicate methods be flagged as error (syntax or anything suitable error)

On 14 January 2018 at 08:20, Chris Angelico wrote: > On Sun, Jan 14, 2018 at 7:10 PM, joannah nanjekye > wrote: > > Hello, > > > > Apparently when you implement two methods with the same name: > > > > def sub(x, y): > > print(x -y) > > > > def

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

I like the Guido's proposal, i.e. if '__repr__' not in cls.__dict__: ... # generate the method etc. I didn't find an issue to track this. Maybe we should open one? -- Ivan ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Documenting types outside of typing

FWIW the same problem was discussed a year ago when documenting typing. At that time the discussion was not conclusive, so that some types use class:: directive while other use data:: directive. At that time Guido was in favour of data:: and now in view of PEP 560 many types in typing will stop

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

On 22 December 2017 at 20:55, Brett Cannon wrote: > > > On Fri, Dec 22, 2017, 11:38 Chris Barker, wrote: > >> On Fri, Dec 22, 2017 at 8:49 AM, Brett Cannon wrote: >> >>> I think it's worth reminding people that if they don't like the

Re: [Python-Dev] Supporting functools.singledispatch with classes.

On 26 December 2017 at 01:41, Nick Coghlan wrote: > On 25 December 2017 at 12:32, Ethan Smith wrote: > > So at the moment, I don't think it is possible to implement > singledispatch > > on classmethod or staticmethod decorated functions. > > I've posted

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

On 21 December 2017 at 11:22, Terry Reedy wrote: > On 12/21/2017 4:22 AM, Eric V. Smith wrote: > >> On 12/21/2017 1:46 AM, Chris Barker wrote: >> > > I suggest that it be clear in the docs, and ideally in the PEP, that the >>> dataclass decorator is using the *annotation"

Re: [Python-Dev] PEP 567 -- Context Variables

On 13 December 2017 at 22:35, Yury Selivanov wrote: > [..] > >> A new standard library module ``contextvars`` is added > > > > Why not add this to contextlib instead of adding a new module? IIRC > > this was discussed relative to PEP 550, but I don't remember the > >

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

On 18 December 2017 at 20:38, Nick Coghlan wrote: > > On 19 Dec. 2017 7:00 am, "Chris Barker" wrote: > > > Are there other options?? > > plain old: > > @dataclass > class C: > a = 1 > b = 1.0 > > would work, though then there would be no way to

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

@David What you propose as `Infer` annotation was proposed some time ago (not only for dataclasses, there are other use cases). The discussion is here https://github.com/python/typing/issues/276 @Chris People are still allowed not to use dataclasses if they really don't like type hints :-)

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 <storch...@gmail.com> 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_subclas

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

Re: [Python-Dev] Last call for PEP approvals before the holidays

There is also PEP 544 (Structural subtyping, a.k.a. static duck typing), but I think we discussed off-list that it is also not time sensitive, given the (limited) provisional status of typing module. (Also mypy already supports it, so the question is mainly when this support is official after

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

On 10 December 2017 at 22:24, Raymond Hettinger wrote: > Without typing (only the first currently works): > > Point = namedtuple('Point', ['x', 'y', 'z']) # underlying > store is a tuple > Point = make_dataclass('Point', ['x', 'y', 'z']) #

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

On 8 December 2017 at 19:28, Raymond Hettinger wrote: > > I'm hoping the typing experts will chime in here. The question is > straight-forward. Where should we look for the signature and docstring for > constructing instances? Should they be attached to the class,

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations (Draft 3)

Congratulations, Łukasz! -- 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] Accepting PEP 560 -- Core support for typing module and generic types

Thank you! It looks like we have a bunch of accepted PEPs today. It is great to see all this! Thanks everyone who participated in discussions here, on python-ideas and on typing tracker. Special thanks to Mark who started this discussion. -- Ivan ___

Re: [Python-Dev] Accepting PEP 562 -- Module __getattr__ and __dir__

Thank you Guido! And thanks everyone for help, discussions, and ideas (in particular Larry who started this discussion). I will submit a PR with implementation soon. -- Ivan On 4 December 2017 at 17:58, Guido van Rossum wrote: > Ivan, > > Congrats on your PEP. I believe the

Re: [Python-Dev] PEP 557 Data Classes 5th posting

Congratulations, Eric! This is a great PEP and I am looking forward to implement support for it in mypy ;-) -- Ivan On 4 December 2017 at 18:17, Guido van Rossum wrote: > And with this, I'm accepting PEP 557, Data Classes. > > Eric, congrats with your efforts in proposing

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 25 November 2017 at 16:57, Guido van Rossum <gu...@python.org> wrote: > On Sat, Nov 25, 2017 at 6:55 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> On 25 November 2017 at 04:30, Guido van Rossum <gu...@python.org> wrote: >> >>> On Fr

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 25 November 2017 at 04:30, Guido van Rossum wrote: > On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum > wrote: > >> The more I hear about this topic, the more I think that `await`, `yield` >> and `yield from` should all be banned from occurring in all

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 25 November 2017 at 01:22, Guido van Rossum wrote: > The more I hear about this topic, the more I think that `await`, `yield` > and `yield from` should all be banned from occurring in all comprehensions > and generator expressions. That's not much different from disallowing

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

OK, so my 24 hours are over :-) On 24 November 2017 at 01:50, Nick Coghlan <ncogh...@gmail.com> wrote: > On 23 November 2017 at 23:04, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> I don't see why this particular case qualifies for such a radical measure >

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 15:30, Paul Moore <p.f.mo...@gmail.com> wrote: > On 23 November 2017 at 14:24, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> My main concern is that comprehension is not equivalent to a for loop > >> for a specific reason - the

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 15:21, Paul Moore <p.f.mo...@gmail.com> wrote: > On 23 November 2017 at 13:04, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > Let us forget for a moment about other problems and focus on this one: > list > > comprehension is curre

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 13:45, Paul Moore <p.f.mo...@gmail.com> wrote: > On 23 November 2017 at 12:28, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 23 November 2017 at 13:11, Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >> On 23

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 13:30, Antoine Pitrou wrote: > On Thu, 23 Nov 2017 14:17:32 +0200 > Serhiy Storchaka wrote: > > > > I used the "yield" statement, but I never used the "yield" expressions. > > And I can't found examples. Could you please present a

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 13:11, Paul Moore <p.f.mo...@gmail.com> wrote: > On 23 November 2017 at 12:01, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > > "I don't use it, therefore it is not needed" is a great argument, > thanks. > > Lets just f

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 12:49, Antoine Pitrou <solip...@pitrou.net> wrote: > On Thu, 23 Nov 2017 12:39:46 +0100 > Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > > > Also I think it makes sense to keep discussion in one place, i.e. either > > here xor a

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 10:50, Paul Moore wrote: > On 23 November 2017 at 09:14, Steve Holden wrote: > > I would urge developers, in their improvements to the language to support > > asynchronous programming, to bear in mind that this is (currently) a >

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 12:38, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 23 November 2017 at 11:55, Nick Coghlan <ncogh...@gmail.com> wrote: > >> On 23 November 2017 at 18:11, Greg Ewing <greg.ew...@canterbury.ac.nz> >> wrote: >> >>> Iva

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 11:55, Nick Coghlan <ncogh...@gmail.com> wrote: > On 23 November 2017 at 18:11, Greg Ewing <greg.ew...@canterbury.ac.nz> > wrote: > >> Ivan Levkivskyi wrote: >> >>> "People sometimes want to refactor for-loops containing `y

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 09:17, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Ivan Levkivskyi wrote: > >> "People sometimes want to refactor for-loops containing `yield` into a >> comprehension >> > > By the way, do we have any real-life examples of peop

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 09:11, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Ivan Levkivskyi wrote: > >> "People sometimes want to refactor for-loops containing `yield` into a >> comprehension but that doesn't work (particularly because of the hidden &

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 09:15, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Ivan Levkivskyi wrote: > >> On 23 November 2017 at 05:44, Greg Ewing <greg.ew...@canterbury.ac.nz >> <mailto:greg.ew...@canterbury.ac.nz>> wrote: >> >>def g():

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 05:44, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Ivan Levkivskyi wrote: > >> The key idea is that neither comprehensions nor generator expressions >> should create a function scope surrounding the `expr` >> > > I don't see ho

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23 November 2017 at 01:00, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Wed, Nov 22, 2017 at 6:46 PM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > [..] > > Just found another example of intuitive behaviour: > > > >>>

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 21:07, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Wed, Nov 22, 2017 at 2:37 PM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 22 November 2017 at 20:33, Guido van Rossum <gu...@python.org> wrote: > >> > >> O

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

22 Лис 2017 22:33 "Ethan Furman" <et...@stoneleaf.us> пише: On 11/22/2017 01:25 PM, Ivan Levkivskyi wrote: > 22 Лис 2017 22:19 "Ethan Furman" пише: > Whether it's inside or outside a function should be irrelevant -- a >> comprehension / generator

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

22 Лис 2017 22:19 "Ethan Furman" <et...@stoneleaf.us> пише: On 11/22/2017 11:01 AM, Ivan Levkivskyi wrote: I think how to formulate these rules more "precisely" so that they will be > all consistent even if there is a > `yield` inside. > The key idea is that n

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 20:33, Guido van Rossum <gu...@python.org> wrote: > On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> On 22 November 2017 at 20:05, Guido van Rossum <gu...@python.org> wrote: >> >>>

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 20:05, Guido van Rossum wrote: > On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra > wrote > >> 2017-11-22 9:58 GMT-08:00 Guido van Rossum : >> > (OTOH, await in the same position must keep working since it's

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 20:15, Guido van Rossum <gu...@python.org> wrote: > On Wed, Nov 22, 2017 at 11:08 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > >> On 22 November 2017 at 19:54, Jelle Zijlstra <jelle.zijls...@gmail.com> >> wrote: >> &

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 19:54, Jelle Zijlstra wrote: > > One proposal is to make it so `g` gets assigned a list, and the `yield` > happens in the enclosing scope (so the enclosing function would have to be > a generator). This was the way things worked in Python 2, I

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 18:15, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 November 2017 at 16:47, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 22 November 2017 at 17:43, Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >> On 22

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 18:15, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 November 2017 at 16:47, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 22 November 2017 at 17:43, Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >> On 22

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 17:50, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 November 2017 at 16:38, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 22 November 2017 at 17:16, Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >> Docs mor

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 17:43, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 November 2017 at 16:30, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 22 November 2017 at 17:24, Antoine Pitrou <solip...@pitrou.net> > wrote: > >> Given a comprehen

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

Sorry, forgot some details in the second "definition": try: def __gen(): for i in range(3): yield (yield i) g = list(__gen()) finally: del __gen -- Ivan ___ Python-Dev mailing list

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 17:16, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 November 2017 at 16:08, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 22 November 2017 at 16:56, Yury Selivanov <yselivanov...@gmail.com> > > wrote: > >> > >

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 17:24, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 22 Nov 2017 17:08:14 +0100 > Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > On 22 November 2017 at 16:56, Yury Selivanov <yselivanov...@gmail.com> > > wrote: > > &g

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 16:56, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 22 November 2017 at 15:47, Paul Moore <p.f.mo...@gmail.com> wrote: > [...] > I'm all for

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 16:53, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 November 2017 at 15:10, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > I think there may be a small misunderstanding here. The situation is > > different for comprehensions and gen

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 15:47, Paul Moore wrote: > I generally don't understand "await" in any context, so I deferred > judgement on that :-) Based on your comment that they are equally > tricky, I'd suggest we prohibit them both ;-) > > Less facetiously, comprehensions are

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 15:46, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 22 Nov 2017 15:15:49 +0100 > Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > There are many things that I would reject in code review, but they are > > still allowed in Python, >

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 15:09, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 November 2017 at 13:53, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > On 22 November 2017 at 14:38, Antoine Pitrou <solip...@pitrou.net> > wrote: > >> > >> On We

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 14:53, Serhiy Storchaka <storch...@gmail.com> wrote: > 22.11.17 15:25, Ivan Levkivskyi пише: > >> I think this is indeed a problem.. For me the biggest surprise was that >> `yield` inside a comprehension does not turn a surrounding function into &g

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 22 November 2017 at 14:38, Antoine Pitrou wrote: > On Wed, 22 Nov 2017 15:03:09 +0200 > Serhiy Storchaka wrote: > > From > > https://stackoverflow.com/questions/45190729/ > differences-between-generator-comprehension-expressions. > > > > g =

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

Serhiy, I think this is indeed a problem. For me the biggest surprise was that `yield` inside a comprehension does not turn a surrounding function into comprehension, see also

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

On 20 November 2017 at 10:22, Mark Shannon <m...@hotpy.org> wrote: > On 19/11/17 22:36, Ivan Levkivskyi wrote: > >> Except that there is no such thing as object._getitem__. Probably you >> mean PyObject_GetItem (which is just what is done by BINARY_SUBSCR opcode). &

Re: [Python-Dev] Comment on PEP 562 (Module __getattr__ and __dir__)

On 20 November 2017 at 20:51, Guido van Rossum wrote: > Yeah, I don't think there's an action item here except *maybe* changes to > the wording of the PEP. Ivan? > Yes, I will make a small PR with a more detailed description of how __getattr__ works. -- Ivan

  1   2   >