Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

On 04/29, Yury Selivanov wrote: > On 2015-04-29 11:29 AM, Ethan Furman wrote: >> Python is not lisp, and await is not a >> function, so parens should not be needed in the common case. > > Which common case you mean? The common case of not wanting to write parenthesis. ;) S

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

On 04/29, Yury Selivanov wrote: > On 2015-04-29 1:25 PM, Ethan Furman wrote: >> cannot also just work and be the same as the parenthesized >> version. > > Because it does not make any sense. I obviously don't understand your position that "it does not make any sens

[Python-Dev] PEP 492 quibble and request

>From the PEP: > Why not a __future__ import > > __future__ imports are inconvenient and easy to forget to add. That is a horrible rationale for not using an import. By that logic we should have everything in built-ins. ;) > Working example > ... The working example only uses async def and a

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

On 04/29, Nathaniel Smith wrote: > (I suspect this may also be the impetus behind Greg's request that it just > be treated the same as unary minus. IMHO it matters much more that the > rules be predictable and teachable than that they allow or disallow every > weird edge case in exactly the right

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

On 04/29, Yury Selivanov wrote: > Because you want operators to be resolved in the > order you see them, generally. > > You want '(await -fut)' to: > > 1. Suspend on fut; > 2. Get the result; > 3. Negate it. > > This is a non-obvious thing. I would myself interpret it > as: > > 1. Get fut.__ne

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

On 04/30, Guido van Rossum wrote: > On Thu, Apr 30, 2015 at 9:15 AM, Ethan Furman wrote: > >> [...] >> Both you and Paul are correct on this, thank you. The proper resolution >> of >> >>await -coro() >> >> is indeed to get the resu

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

On 04/30, Yury Selivanov wrote: > On 2015-04-30 1:56 PM, Ethan Furman wrote: > I still want to see where my current grammar forces to use > parens. See [1], there are no useless parens anywhere. --> await -coro() SyntaxError --> await (-coro()) # not a SyntaxError, there

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 05/01, Stefan Behnel wrote: > Yury Selivanov schrieb am 01.05.2015 um 20:52: >> I don't like the idea of combining __next__ and __anext__. >> In this case explicit is better than implicit. __next__ >> returning coroutines is a perfectly normal thing for a >> normal 'for' loop (it wouldn't to a

Re: [Python-Dev] PEP 492: What is the real goal?

On 05/01, Guido van Rossum wrote: > On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett wrote: >> So does this mean that yield should NOT be used just to yield control >> if a task isn't blocked? (e.g., if its next step is likely to be >> long, or low priority.) Or even that it wouldn't be considere

[Python-Dev] PEP 492 and types.coroutine

According to https://www.python.org/dev/peps/pep-0492/#id31: The [types.coroutine] function applies CO_COROUTINE flag to generator-function's code object, making it return a coroutine object. Further down in https://www.python.org/dev/peps/pep-0492/#id32: [await] uses the yield from imp

Re: [Python-Dev] PEP 492 and types.coroutine

On 05/02, Yury Selivanov wrote: > On 2015-05-02 1:04 PM, Ethan Furman wrote: >> If I'm understanding this correctly, type.coroutine's only purpose is to add >> a flag to a generator object so that await will accept it. >> >> This raises the question of why

Re: [Python-Dev] PEP 492 and types.coroutine

On 05/02, Yury Selivanov wrote: > On 2015-05-02 2:14 PM, Ethan Furman wrote: >> On 05/02, Yury Selivanov wrote: >>> On 2015-05-02 1:04 PM, Ethan Furman wrote: >> And yet in current asyncio code, random generators can be accepted, and not >> even the current asyncio.c

Re: [Python-Dev] Accepting PEP 492 (async/await)

Congratulations, Yury! -- ~Ethan~ ___ 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] PYTHONHTTPSVERIFY env var

On 05/12/2015 04:19 AM, Nick Coghlan wrote: It occurs to me that the subtitle of PEP 493 could be "All software is terrible, but it's often a system administrator's job to make it run anyway" :) +1 QoTW -- ~Ethan~ ___ Python-Dev mailing list Python

Re: [Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 10:04 AM, Larry Hastings wrote: Workflow 1: +1 -- ~Ethan~ ___ 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%40mai

Re: [Python-Dev] PEP 550 v4

On 09/07/2017 04:39 AM, Greg Ewing wrote: 1) Under "Generators" it says: once set in the generator, the context variable is guaranteed not to change between iterations; This suggests that you're not allowed to set() a given context variable more than once in a given generator, but some

Re: [Python-Dev] PEP 550 v4

On 09/07/2017 03:37 AM, Greg Ewing wrote: If I understand correctly, instead of using a context manager, your fractions example could be written like this: def fractions(precision, x, y): ctx = decimal.getcontext().copy() decimal.setcontext(ctx) ctx.prec = precision yield My

Re: [Python-Dev] PEP 550 v4

On 09/06/2017 11:57 PM, Yury Selivanov wrote: On Wed, Sep 6, 2017 at 11:39 PM, Greg Ewing wrote: Here's one way that refactoring could trip you up. Start with this: async def foo(): calculate_something() #in a coroutine, so we can be lazy and not use a cm Where exactly doe

Re: [Python-Dev] PEP 550 v4

On 09/07/2017 06:41 AM, Elvis Pranskevichus wrote: On Thursday, September 7, 2017 9:05:58 AM EDT Ethan Furman wrote: The disagreement seems to be whether a LogicalContext should be created implicitly vs explicitly (or opt-out vs opt-in). As a user trying to track down a decimal context change

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

On 09/08/2017 11:38 AM, Steven D'Aprano wrote: On Fri, Sep 08, 2017 at 10:37:12AM -0700, Nick Coghlan wrote: def __eq__(self, other): if other.__class__ is self.__class__: return (self.name, self.unit_price, self.quantity_on_hand) == (other.name, other.unit_price, other.qua

Re: [Python-Dev] PEP 549 v2: now titled Instance Descriptors

On 09/08/2017 12:44 PM, Larry Hastings wrote: I've updated PEP 549 with a new title--"Instance Descriptors" is a better name than "Instance Properties"--and to clarify my rationale for the PEP. I've also updated the prototype with code cleanups and a new type: "collections.abc.InstanceDescrip

Re: [Python-Dev] PEP 549 v2: now titled Instance Descriptors

On 09/08/2017 01:45 PM, Ethan Furman wrote: I will admit I don't see what reassigning the __class__ attribute on a module did for us. Nathaniel Smith wrote: - > If you have an existing package that doesn't replace itself in > sys.modules, then it's d

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

On 09/11/2017 03:00 PM, Barry Warsaw wrote: On Sep 10, 2017, at 20:08, Nathaniel Smith wrote: I've sometimes wished that attrs let me control whether it generated equality methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the cmp= argument should take an enum with optio

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

On 09/06/2017 08:26 AM, Guido van Rossum wrote: So we've seen a real use case for __class__ assignment: deprecating things on access. That use case could also be solved if modules natively supported defining __getattr__ (with the same "only used if attribute not found otherwise" semantics as i

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

On 09/14/2017 12:08 PM, Ivan Levkivskyi wrote: 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 b

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

On 09/11/2017 03:28 PM, Guido van Rossum wrote: Oddly I don't like the enum (flag names get too long that way), but I do agree with everything else Barry said (it should be a trivalue flag and please don't name it cmp). Hmmm, named constants are one of the motivating factors for having an Enu

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

On 10/12/2017 03:44 PM, Chris Barker wrote: I think we've drifted into a new topic, but... I was thinking about this last spring, when I tried to cram all sorts of python metaprogramming into one 3hr class... Trying to come up with a an exam[ple for metclasses, I couldn't come up with anyth

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

On 10/13/2017 02:35 AM, Martin Teichmann wrote: Metaclasses currently tend to serve two distinct purposes: 1. Actually altering the runtime behaviour of a class and its children in non-standard ways (e.g. enums, ABCs, ORMs) 2. Boilerplate reduction in class definitions, reducing the amount of co

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

On 10/14/2017 07:37 AM, Martin Teichmann wrote: Things that will not work if Enum does not have a metaclass: list(EnumClass) -> list of enum members dir(EnumClass) -> custom list of "interesting" items len(EnumClass) -> number of members member in EnumClass -> True or False - protection from

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

On 10/14/2017 08:57 AM, Ivan Levkivskyi wrote: 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

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

On 10/14/2017 11:30 AM, Ivan Levkivskyi wrote: As a side note, I don't think elimination of metaclasses should be a "goal by itself". This is a powerful and flexible mechanism, but there are specific situations where metaclasses don't work well because of e.g. frequent conflicts or performance

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 10/16/2017 09:11 AM, Yury Selivanov wrote: Question: why do we want EC objects to be mappings? I'd rather make them opaque, which will result in less code and make it more future-proof. The key arguments for keeping ContextVar abstraction: * Naturally avoids name clashes. * Allows to impl

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 10/16/2017 05:29 PM, Nathaniel Smith wrote: On Mon, Oct 16, 2017 at 11:12 AM, Ethan Furman wrote: What would be really nice is to have attribute access like thread locals. Instead of working with individual ContextVars you grab the LocalContext and access the vars as attributes. I don&#

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 10/17/2017 09:40 PM, Nick Coghlan wrote: On 18 October 2017 at 05:55, Yury Selivanov wrote: I actually like what you did in https://github.com/gvanrossum/pep550/blob/master/simpler.py , it seems reasonable. The only thing that I'

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 10/18/2017 10:50 AM, Yury Selivanov wrote: On Wed, Oct 18, 2017 at 1:06 PM, Guido van Rossum wrote: On Tue, Oct 17, 2017 at 9:40 PM, Nick Coghlan wrote: [..] By contrast, "contextvars.set_ctx" would need various wrappers to handle correctly reverting the context change, and would hence be

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On 10/30/2017 10:18 AM, Guido van Rossum wrote: I have read PEP 564 and (mostly) followed the discussion in this thread, and I am happy with the PEP. I am hereby approving PEP 564. Congratulations Victor! Congrats, Victor! ___ Python-Dev mailing lis

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 11/07/2017 05:44 AM, Paul Moore wrote: If you're a user and your application developer didn't do (1) or a library developer developing one of the libraries your application developer chose to use didn't do (2), you're hosed. If you're a user who works in an environment where moving to a new v

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

On 11/10/2017 07:48 AM, Guido van Rossum wrote: I don't mind the long name. Of all the options so far I really only like 'string_annotations' so let's go with that. As someone else mentioned, we have function annotations and variable annotations already, which makes string_annotations sound

Re: [Python-Dev] PEP 562

On 11/15/2017 04:55 AM, Koos Zevenhoven wrote: On Tue, Nov 14, 2017 at 10:34 PM, Ivan Levkivskyi wrote: Rationale = [...] It would be convenient to simplify this procedure by recognizing ``__getattr__`` defined directly in a module that would act like a normal ``__getattr__`` method

[Python-Dev] module customization

So there are currently two ways to customize a module, with PEP 562 proposing a third. The first method involves creating a standard class object, instantiating it, and replacing the sys.modules entry with it. The second way is fairly similar, but instead of replacing the entire sys.modules en

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

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 >> level: given multiple entries in "orig_bases" with __mro_entries__ methods, >> do all such methods get passed the *same*

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

On 11/22/2017 09:15 AM, Paul Moore wrote: 1. List comprehensions expand into nested for/if statements in the "obvious" way - with an empty list created to start and append used to add items to it. 1a. Variables introduced in the comprehension don't "leak" (see below). 2. Generator expression

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

On 11/22/2017 05:03 AM, Serhiy Storchaka wrote: From https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions. g = [(yield i) for i in range(3)] Syntactically this looks like a list comprehension, and g should be a list, right? But actually i

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

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 neither comprehensions nor generator expressions should create a function scope surrounding the `expr

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

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 expression should have no influence on the type of the resulting function (and at le

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

On 11/22/2017 01:40 PM, Ivan Levkivskyi wrote: 22 Лис 2017 22:33 "Ethan Furman" mailto:et...@stoneleaf.us>> пише: Right, the argument is that calling the `list` constructor should return a list -- not a database proxy, not a web page, and not a generator. Then you didn&#

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

On 11/22/2017 11:51 PM, Sven R. Kunze wrote: A "yield" within a comprehension is like a "return" in a comprehension. It makes no sense at all. Also a "yield" and a "return with value" is also rarely seen. Comprehensions build new objects, they are not for control flow, IMO. +1 -- ~Ethan~ __

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

On 11/23/2017 04:01 AM, Ivan Levkivskyi wrote: Lets just forget about two SO questions and dozens people who up-voted it. Questions/answers are routinely up-voted because they are well-written and/or informative, not just because somebody had a need for it or a use for the answer. The SO qu

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

On 11/24/2017 04: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 comprehensions and generator expressions. That's not much different from disallowing `return` or `break`. For m

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

On 11/25/2017 04:20 PM, David Mertz wrote: On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum wrote: Maybe you didn't realize async/await don't need an event loop? Driving an async/await-based coroutine is just as simple as driving a yield-from-based one (`await` does exactly the same thing a

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On 11/28/2017 12:31 PM, Raymond Hettinger wrote: timeout ?? local_timeout ?? global_timeout 'foo' in (None ?? ['foo', 'bar']) requested_quantity ?? default_quantity * price name?.strip()[4:].upper() user?.first_name.upper() Cryptic, indeed. -1 from me. -- ~Ethan~ __

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

On 12/04/2017 09:17 AM, Guido van Rossum wrote: And with this, I'm accepting PEP 557, Data Classes. Congratulations, Eric! Data Classes will be a handy thing to have. :) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.pyt

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

There were some concerns about open() earlier: On Wed, 6 Dec 2017 at 06:10 INADA Naoki wrote: > I think PEP 538 and PEP 540 should behave almost identical except > changing locale or not. So I need very strong reason if PEP 540 > changes default error handler of open(). Brett replied: > I don't

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

On 12/29/2017 02:23 AM, Ethan Smith wrote: The first is that needing both a keyword and method is duplicative and unnecessary. Eric agreed it was a hassle, but felt it was justified considering someone may accidentally override a dataclass method. I disagree with this point of view as dataclas

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

On 12/29/2017 11:55 AM, Ethan Smith wrote: On Fri, Dec 29, 2017 at 11:37 AM, Ethan Furman wrote: It is possible to determine whether an existing __repr__ is from 'object' >> or not, and only provide one if that is the case. I think that should be >> the default, with &

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

On Fri, Dec 29, 2017 at 12:30 PM, Ethan Furman wrote: > Good point. So auto-generate a new __repr__ if: > > - one is not provided, and > - existing __repr__ is either: > - object.__repr__, or > - a previous dataclass __repr__ > > And if the auto default doesn't

Re: [Python-Dev] PEP 567 pre v3

On 01/10/2018 10:23 PM, Yury Selivanov wrote: On Thu, Jan 11, 2018 at 4:44 AM, Nathaniel Smith wrote: It may have gotten lost in that email, but my actual favorite approach is that we make the signatures: ContextVar(name, *, initial_value) # or even (*, name, initial_value) ContextVar.get()

Re: [Python-Dev] Positional-only parameters in Python

On 01/17/2018 08:14 AM, Serhiy Storchaka wrote: 17.01.18 16:34, Victor Stinner пише: In Februrary 2017, I proposed on python-ideas to change the Python syntax to allow to declare positional-only parameters in Python: https://mail.python.org/pipermail/python-ideas/2017-February/044879.html https

Re: [Python-Dev] Intention to accept PEP 567 (Context Variables)

On 01/22/2018 03:52 PM, Guido van Rossum wrote: I am hereby *accepting* the latest version of PEP 567[1]. Congrats! Congratulations, Yury! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

On 01/25/2018 10:53 AM, Brett Cannon wrote: [...] before we get ahead of ourselves and design this we need to get consensus that people like the overall idea of using a bot to do a main > commits as well. -1 on using comments for the main commit. -- ~Ethan~ ___

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

On 01/28/2018 07:45 AM, Eric V. Smith wrote: On 1/6/2018 5:13 PM, Eric V. Smith wrote: On 12/10/2017 5:00 PM, Raymond Hettinger wrote: 2) Change the default value for "hash" from "None" to "False". This might take a little effort because there is currently an oddity where setting hash=False

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

On 01/29/2018 12:57 AM, Eric V. Smith wrote: On 1/29/2018 3:42 AM, Ethan Furman wrote: On 01/28/2018 07:45 AM, Eric V. Smith wrote: I think the hashing logic explained in https://bugs.python.org/issue32513#msg310830 is correct. It uses hash=None as the default, so that frozen=True objects

Re: [Python-Dev] Dataclasses and correct hashability

On 02/02/2018 08:14 AM, Yury Selivanov wrote: Eric, in my opinion we shouldn't copy attrs. [...] We are designing a new API that is going to be hugely popular. Why can't we ship it with dangerous options prohibited in 3.7 (it's easy to do that!) and then enable them in 3.8 when there's an a

Re: [Python-Dev] Dataclasses and correct hashability

On 02/02/2018 08:09 AM, Eric V. Smith wrote: On 2/2/2018 10:56 AM, Elvis Pranskevichus wrote: My point is exactly that there is _no_ valid use case, so (hash=True, frozen=False) should not be a thing! Why are you so insistent on adding a dangerous option which you admit is nearly useless? B

Re: [Python-Dev] Dataclasses and correct hashability

On 02/02/2018 10:44 PM, Guido van Rossum wrote: It appears Eric and I are the only ones in favor of keeping the current behavior. But I still am not convinced by all the worries about "attractive nuisances" and all the other bad names this feature has been called. We don't know that any of the

Re: [Python-Dev] Dataclasses and correct hashability

On 02/06/2018 09:38 AM, Guido van Rossum wrote: Where do you get the impression that one would have to explicitly request __hash__ if frozen=True is set? To the contrary, my proposal is for @dataclass to automatically add a __hash__ method when frozen=True is set. This is what the code current

Re: [Python-Dev] Dataclasses and correct hashability

On 02/06/2018 11:18 AM, Guido van Rossum wrote: We may be in violent agreement. I propose *not* to add a way to *disable* hashing when the rest of the flags to @dataclass() would indicate that it's safe to add a __hash__ method. Okay. I propose that with @dataclass(unsafe_hash=False) (the

Re: [Python-Dev] Dataclasses and correct hashability

On 02/06/2018 12:24 PM, Guido van Rossum wrote: On Tue, Feb 6, 2018 at 11:40 AM, Ethan Furman wrote: It sounds like `unsafe_hash=True` indicates a truly unsafe hash (that is, >> mutable data is involved in the hash calculation), but there still seems >> to be one possib

Re: [Python-Dev] Dataclasses and correct hashability

On 02/06/2018 06:48 PM, Guido van Rossum wrote: That seems a rare case (though I hadn't thought of it). I had thought of the use case where you want a frozen type without a hash; that you can presumably implement using def __hash__(self): raise TypeError("not hashable") We can do a similar th

Re: [Python-Dev] PEP 467 (Minor API improvements for binary sequences) - any thoughts?

On 02/21/2018 11:55 AM, Elias Zamaria wrote: This is about some minor changes to the bytes, bytearray, and memoryview classes. Here is the PEP: https://www.python.org/dev/peps/pep-0467/ The page in the bug tracker can be seen at https://bugs.python.org/issue27923 and the pull request can be s

Re: [Python-Dev] PEP 467 (Minor API improvements for binary sequences) - any thoughts?

ers to Python 3 migration, but it's now more about the general ergonmics of the bytes type, and I don't do enough low level protocol work these days to have a strong opinion on that. That new champion could be Elias, or else perhaps Ethan Furman (who drove the last round of proposed

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

On 02/22/2018 02:12 AM, Antoine Pitrou wrote: Overall it makes contributing more of a PITA than it needs be. Do automatic style *fixes* if you want, but please don't annoy me with automatic style checks that ask me to do tedious grunt work on my spare time. +1 -- ~Ethan~ ___

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On 02/22/2018 11:54 AM, Joao S. O. Bueno wrote: > On 22 February 2018 at 16:04, Serhiy Storchaka wrote: >> Stephan Houben proposed an idiom which looks similar to new hypothetic >> syntax: >> >> result = [y + g(y) for x in range(10) for y in [f(x)]] > > This thing has bitten me in the past -

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

On 02/26/2018 05:40 AM, Eric V. Smith wrote: As long as I'm saving if a dataclass is frozen, I should save all of the dataclass parameters on the class. Since it's per-class, it's not a lot of overhead. That's what Enum does. A bit of pain, but makes so many other things easier. -- ~Ethan~

Re: [Python-Dev] PEP 467 (Minor API improvements for binary sequences) - any thoughts?

On 02/26/2018 11:34 PM, Elias Zamaria wrote: Nick, I'm trying to reply to your message, but I can't figure out how. You mentioned that the PEP needs a "champion". What would that involve? How much time and effort would it take? What kinds of decisions would I make? Being a PEP "champion" inv

Re: [Python-Dev] Hello!

On 03/20/2018 04:15 AM, Agnostic Dev wrote: My name is Matt Eaton (Agnostic Dev) and I am just joining the mailing list so I wanted to reach out and say hello! Hello back! Welcome to the list! Just as a reminder, this list is for discussions of the development OF Python, or how to make Pyth

Re: [Python-Dev] Python version numbers

On 04/03/2018 01:16 PM, Barry Warsaw wrote: On Apr 3, 2018, at 13:08, Brett Cannon wrote: Are we at the PEP/language summit topic point yet in this discussion >> since Guido has said he's not interested in changing the status quo? >> ;) Versioning is like naming variables, so this thread coul

[Python-Dev] in

This behavior was recently brought to my attention [1]: --> 1 in 'hello' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand, not int However, in any other collection (set, dict, list, tuple, etc), the answer would be False. Does anyone re

[Python-Dev] Enum, Flag, __contains__, and False vs TypeError

API question. Background: -- When doing checks such as --> 3 in [4, 5, 6] --> 'test' in {'test':True, 'live':False} the result is True or False. When doing checks such as --> 3 in 'hello world' --> [4, 5, 6] in {'test':True, 'live':False} the result is a TypeError. The general rule

Re: [Python-Dev] Enum, Flag, __contains__, and False vs TypeError

On 04/04/2018 12:40 PM, Barry Warsaw wrote: On Apr 4, 2018, at 11:32, Ethan Furman wrote: (A) A standard Enum class is a container of Enum members. It cannot hold anything else... (B) The waters get even more muddied when Fruit has a str mixin, so `Fruit.APPLE == 'apple' is True

Re: [Python-Dev] Enum, Flag, __contains__, and False vs TypeError

On 04/04/2018 01:24 PM, Glenn Linderman wrote: I think the "in" test should raise TypeError if tested against _anything_ that is not an Enum member. Why? I see a parallel between Enum and mappings. x = {'test':True, 'live':False} So it is True that 'test' in x and 'live' in x and False

Re: [Python-Dev] Enum, Flag, __contains__, and False vs TypeError

On 04/04/2018 02:12 PM, Guido van Rossum wrote: I don't think of "in" as an equality test -- it's special just like <, <=, > >, >= are special, and those can certainly raise TypeError. Good to know, thank you! -- ~Ethan~ ___ Python-Dev mailing list

[Python-Dev] GH-6392: Enum, __contains__, TypeError, and DeprecationWarnings

Oh my! ;) So, after the previous discussion about when __contains__ should raise TypeError instead of returning False, it seems there are a couple cases where a TypeError should be raised now: 1) non-enum-instance in EnumClass 2) anything in enum_instance 3) non-flag-instance in flag insta

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

On 04/17/2018 07:01 AM, Chris Angelico wrote: On Tue, Apr 17, 2018 at 10:17 PM, Nick Coghlan wrote: That ambiguity generally doesn't exist with simple name bindings (I'm excluding execution namespaces with exotic binding behaviour from consideration here, as the consequences of trying to work

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

On 04/17/2018 12:46 AM, Chris Angelico wrote: PEP: 572 Title: Assignment Expressions Author: Chris Angelico +1 Thanks for all the hard work, Chris! Hoping this PEP finally breaks your streak! ;) -- ~Ethan~ ___ Python-Dev mailing list Python-De

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

On 04/17/2018 06:26 AM, Paul Moore wrote: I should also point out that I remain -0 on this proposal (I'd already said this on python-ideas, but I should probably repeat it here). For me, the use cases are mostly marginal, and the major disadvantage is in having two forms of assignment. Explainin

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

On 04/20/2018 08:07 AM, Chris Barker - NOAA Federal wrote: On 04/20/2018 04:25 AM, Christoph Groth wrote: Personally, I even slightly prefer a := 3 to the commonplace a = 3 because it visually expresses the asymmetry of the operation. Careful here! That’s a fine argument for using := in a

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

On 04/20/2018 11:15 AM, Christoph Groth wrote: Nick Coghlan wrote: I also think that if "=" and ":=" both target the same kind of scope, there isn't enough new expressiveness introduced by the latter to justify the syntactic complexity of adding it. OK, but then how about introducing assignme

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

On 04/20/2018 11:31 AM, Christoph Groth wrote: Ethan Furman wrote: On 04/20/2018 11:15 AM, Christoph Groth wrote: OK, but then how about introducing assignment expressions with the "=" operator but *requiring* extra parens (similar to how modern C compilers warn about assignment e

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

On 04/22/2018 10:44 PM, Tim Peters wrote: [Guido] In reality there often are other conditions being applied to the match for which `if expr as name` is inadequate. The simplest would be something like if ...: elif (m := re.match('(.*):(.*)', line)) and m.group(1) == m.group(2):

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

On 04/23/2018 03:04 PM, Tim Peters wrote: [Ethan Furman ] So I really like being able to make the assignment in the expression, but I have a really hard time parsing it with the name first. ... On the other hand, if it were using the "as" keyword: if (x - xbase as diff) and (gcd(d

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

On 04/23/2018 06:42 PM, Chris Jerdonek wrote: On Mon, Apr 23, 2018 at 4:54 PM, Greg Ewing wrote: Tim Peters wrote: if (diff := x - x_base) and (g := gcd(diff, n)) > 1: return g My problem with this is -- how do you read such code out loud? It could be-- "if diff, which we let equal

Re: [Python-Dev] assignment expressions: an alternative proposal

On 04/24/2018 08:19 AM, Yury Selivanov wrote: Yes, because I'm trying to think about this from a pragmatic side of things. My question to myself: "what syntax could I use that would prevent me from making '=' vs '==' mistake when I code?" To me, the answer is that I usually want to compare loca

Re: [Python-Dev] assignment expressions: an alternative proposal

On 04/24/2018 08:35 AM, Yury Selivanov wrote: Yes, it would force users to come up with better names *iff* they want to use this new sugar: if (first_target = get_first_candidate()) ... elif (second_target = get_second_candidate()) ... And then the common code below that only cares abou

Re: [Python-Dev] assignment expressions: an alternative proposal

On 04/24/2018 08:56 AM, Yury Selivanov wrote: On Tue, Apr 24, 2018 at 11:51 AM, Ethan Furman wrote: When I compare to variables from outer scopes they *usually* are on the *right* side of '=='. You mean something like if 2 == x: ? I never write code like that, and I haven

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

On 04/24/2018 12:59 PM, Chris Angelico wrote: On Wed, Apr 25, 2018 at 5:54 AM, Mike Miller wrote: Also, these "binding expressions" are not exactly plain assignment, as it has been known. Aside from the restriction to binding only to a simple name, and the fact that they're also an expressio

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On 04/24/2018 02:21 AM, Victor Stinner wrote: WARNING! I was (strongly) opposed to PEP 448 Unpacking Generalizations (ex: [1, 2, *list]) and PEP 498 f-string (f"Hello {name}"), whereas I am now a happy user of these new syntaxes. So I'm not sure that I have good tastes :-) Cool, you're against

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 04/25/2018 02:55 PM, Tim Peters wrote: This becomes a question of seasoned judgment. For example, here's a real loop summing a series expansion, until the new terms become so small they make no difference to the running total (a common enough pattern in code slinging floats or decimals):

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 04/25/2018 03:15 PM, Ethan Furman wrote: On 04/25/2018 02:55 PM, Tim Peters wrote: This becomes a question of seasoned judgment. For example, here's a real loop summing a series expansion, until the new terms become so small they make no difference to the running total (a common e

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On 04/26/2018 09:02 PM, Alex Walters wrote: http://pyvideo.org/pycascades-2018/bdfl-python-3-retrospective.html link to Guido’s talk, for your convenience Many thanks! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python

<    1   2   3   4   5   6   7   8   9   10   >