[Python-ideas] Re: Additional meanings for "in" operator and ability to customize implementation

On 10/14/2019 12:54 AM, Andrew Barnert via Python-ideas wrote: On Oct 13, 2019, at 22:54, Chris Angelico wrote: Mathematically, what's the difference between '1' and '1+0j' (or '1+0i')? Again, think of Python, but don’t take the analogy too far. You can use `1` almost anywhere you can

[Python-ideas] Re: PEP: add a `no` keyword as an alias for `not`

On 08/01/2019 01:06 PM, Daniel Okey-Okoro wrote: [an idea] Two things: 1) please do not cross-post. 2) a PEP is a very particular thing* -- please do not say you have one unless you do. ;) -- ~Ethan~ * https://www.python.org/dev/peps/pep-0001/

[Python-ideas] Re: for ... except, with ... except

On 07/29/2019 06:35 PM, Steven D'Aprano wrote: 3. syntax that solves a problem, but may mislead people to think it solves a different problem until they learn better; 3.1 syntax that solves a problem, but is misleading to many who are still confused after they "have learnt better" I

[Python-ideas] Re: for ... except, with ... except

On 07/29/2019 12:24 PM, Dominik Vilsmeier wrote: I think the focus shouldn't be on whether such syntax is possibly confusing or not because a) People will always remember that's *either* one way or the other No, they won't. b) It's actually pretty easy to remember which way it is, by just

[Python-ideas] Re: for ... except, with ... except

[redirecting back to the list] On 07/27/2019 09:38 PM, James Lu wrote: On Jul 27, 2019, at 12:44 PM, Ethan Furman wrote: Sure, folks /know/ what it means, but it's a common bug because it doesn't read as "if some_var is assigned 7" but as "if some_var is equal to 7".

[Python-ideas] Re: Cartesian Product on `__mul__`

On 07/27/2019 03:17 AM, Batuhan Taskaya wrote: Its more clear and understandable than itertools.product for people from outside of a programming background. The simplicity is useful when we are working with multiple expressions at sametime. (cset(a & b) * cset(a | b)) So build that

[Python-ideas] Re: for ... except, with ... except

On 07/27/2019 01:19 AM, Serhiy Storchaka wrote: 26.07.19 23:57, Guido van Rossum пише: However, I worry that when people see this syntax, they will think that the except clause is for handling exceptions in the loop body. (That's certainly what I assumed when I read just your subject line.

[Python-ideas] Re: Namespace context managers

On 07/26/2019 09:52 AM, Dan Sommers wrote: There Is Only One Way To Do It. There should be one-- and preferably only one --obvious way to do it. There is very little in Python that can only be done one way. -- ~Ethan~ ___ Python-ideas mailing list

[Python-ideas] Re: PEP's shouldn't require a sponsor

On 07/25/2019 05:31 AM, Batuhan Taskaya wrote: What i see is when you post the ideas channel and it is something that doesnt change much on the frontside people dont care. And when people dont care, they forgot. PEP reviewing process is way better than posting to ideas and try to convince

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

On 06/26/2019 07:34 AM, Anders Hovmöller wrote: I 100% agree that this proposal is a bad idea. But I do have to play Devils advocate here. The the-code-is-understandable-at-face-value ship has already sailed. + doesn't mean add, it means calling a dunder function that can do anything.

[Python-ideas] Re: Overloading assignment concrete proposal (Re: Re: Operator as first class citizens -- like in scala -- or yet another new operator?)

On 06/20/2019 01:25 PM, nate lust wrote: --> class Foo: ... def __init__(self, o): ...         self.o = o ...     def __setself__(self, v): ...         self.v = v ... --> f = Foo(5) --> print(f) <__main__.Foo object at 0x7f486bb8d300> --> print(f.o) 5 >>> print(f.v)

Re: [Python-ideas] Add "default" kwarg to list.pop()

On 10/31/2018 02:29 PM, Chris Angelico wrote: Exactly how a team of core devs can make unified decisions is a little up in the air at the moment I wouldn't worry too much about it. I don't think we have ever made entirely unified decisions. -- ~Ethan~

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

On 09/22/2018 05:52 AM, Anders Hovmöller wrote: And now you made it sound even worse [...] Their use of the word "you" is "everybody who wants to write a PEP", not you "Anders Hovmöller" specifically. (Isn't English a wonderful language? *sigh* ) -- ~Ethan~

Re: [Python-ideas] Moving to another forum system where moderation is possible

On 09/20/2018 07:48 AM, James Lu wrote: Were there any productive parts to that conversation? Out of 85 messages, there was 1 for sure, possibly three more. In the 95 "Retire or reword the namesake of the Language" thread there were 2. Obviously my opinion, but I hope everyone would agree

Re: [Python-ideas] Moving to another forum system where moderation is possible

On 09/20/2018 07:23 AM, Oleg Broytman wrote: On Thu, Sep 20, 2018 at 09:05:33AM -0400, Mark E. Haase wrote: On Thu, Sep 20, 2018 at 8:09 AM Oleg Broytman wrote: On Thu, Sep 20, 2018 at 01:46:10PM +0400, Abdur-Rahmaan Janhangeer wrote: i miss a +1 button It's absence is a big

Re: [Python-ideas] Moving to another forum system where moderation is possible

On 09/18/2018 12:05 PM, Franklin? Lee wrote: On Tue, Sep 18, 2018 at 2:37 PM Jonathan Goble wrote: Perhaps not, but part of that might be because stopping an active >> discussion on a mailing list can be hard to do, so one might not even >> try. Some discussions, I suspect, may have gone on

Re: [Python-ideas] Moving to another forum system where moderation is possible

On 09/17/2018 01:16 PM, James Lu wrote: So... we’re going to be using discourse instead of Python-ideas mailing list? No. None of the mailing lists will be migrated at this time. The plan is to get a test instance set up, tried for a while on a specific issue or two, and evaluate our

Re: [Python-ideas] Revert "RuntimeError: generator raised StopIteration"

On 09/17/2018 11:06 AM, Danilo J. S. Bellini wrote: The idea is simple: restore the "next" built-in and the "StopIteration" propagation behavior from Python 3.6. Unlikely to happen. In 3.6 a deprecation warning started being issued for next inside generators that said it would raise a

Re: [Python-ideas] Keyword only argument on function call

On 09/12/2018 05:17 AM, Steven D'Aprano wrote: > Indeed. Each time you call locals(), it returns a new dict with a snapshot of the current local namespace. Because it all happens inside the same function call, no external thread can poke inside your current call to mess with your local

Re: [Python-ideas] Keyword only argument on function call

On 09/10/2018 12:52 PM, Chris Barker via Python-ideas wrote: I've spent this whole thread thinking: "who in the world is writing code with a lot of spam=spam arguments? If you are transferring that much state in a function call, maybe you should have a class that holds that state? Or pass in

Re: [Python-ideas] Python dialect that compiles into python

On 09/07/2018 04:57 AM, Robert Vanden Eynde wrote: Actually, I might start to write this lib, that looks fun. You should also check out MacroPy: https://pypi.org/project/MacroPy/ Although I freely admit I don't know if does what you are talking about. -- ~Ethan~

Re: [Python-ideas] Python-ideas Digest, Vol 142, Issue 22

On 09/07/2018 12:09 PM, James Lu wrote: [stuff] James, the digest you replied to had four different topics, and I have no idea how many individual messages. You didn't change the subject line, and you didn't trim the text you were not replying to. Which thread/message were you replying to?

Re: [Python-ideas] Keyword only argument on function call

On 09/06/2018 07:05 AM, Anders Hovmöller wrote: On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano wrote: On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote: Wouldn't it be awesome if [...] No. Heh. I did expect the first mail to be uncivil :P Direct

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

On 08/30/2018 01:49 PM, Marko Ristin-Kaufmann wrote: classC(A): # C.some_func also inherits the contracts from A. # It weakens the precondition: # it operates either on sorted lists OR # the lists that are shorter than 10 elements. # # It

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

On 08/29/2018 04:53 PM, Hugh Fisher wrote: From: Marko Ristin-Kaufmann: There seems to be evidence that design-by-contract is useful. Let me cite Bertrand Meyer from his article "Why not program right?" that I already mentioned before: I don't think that being useful by itself should be

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

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? Cases where nested classes should be enum members, and cases where nested classes sho

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

On 06/27/2018 12:04 PM, Elazar wrote: > בתאריך יום ד׳, 27 ביוני 2018, 11:59, מאת Guido van Rossum: >> Sounds to me really strange that the nested class would become a member. >> Probably because everything becomes a member unless it's a function >> (maybe decorated)? > People working with sum

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

On 06/27/2018 11:52 AM, Guido van Rossum wrote: Sounds to me really strange that the nested class would become a member. Probably because everything becomes a member unless it's a function (maybe decorated)? Pretty much. __dunders__, _sunders_, and descriptors do not get transformed.

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

Consider the following Enum definition: class Color(Enum): RED = 1 GREEN = 2 BLUE = 3 @property def lower(self): return self.name.lower() def spam(self): return "I like %s eggs and spam!" % self.lower class SomeClass: pass

[Python-ideas] exception instantiation philosophy and practice [was: Let try-except check the exception instance]

On 05/31/2018 07:36 AM, Nick Coghlan wrote: The exception machinery deliberately attempts to avoid instantiating exception objects whenever it can, but that gets significantly more difficult if we always need to create the instance before we can decide whether or not the raised exception

[Python-ideas] OT: slowing rotation [was: High Precision datetime]

On 05/17/2018 12:13 PM, Tim Peters wrote: Other things can cause the Earth's rotation to speed up temporarily (like some major geological events), but they've only been able to overcome factors acting to slow rotation for brief periods, and never yet got near to overcoming them by a full

Re: [Python-ideas] Verbatim names (allowing keywords as names)

On 05/15/2018 08:03 PM, Carl Smith wrote: On Tue, May 15, 2018 at 8:41 PM, Steven D'Aprano wrote: I'd like to suggest we copy C#'s idea of verbatim identifiers, but using a backslash rather than @ sign: \name would allow "name" to be used as an identifier, even if it clashes with a

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On 05/13/2018 10:57 PM, Greg Ewing wrote: Rob Cliffe via Python-ideas wrote: If you forbid redefining keywords, you remove the whole point of this proposal: I mean the keywords that are in the language as of now. There will never be a need to redefine those, since no current code uses them

Re: [Python-ideas] A comprehension scope issue in PEP 572

On 05/12/2018 11:41 PM, Tim Peters wrote: [Tim, suggests changes to the Reference Manual's 4.2.1] """ An assignment expression binds the target, except in a function F synthesized to implement a list comprehension or generator expression (see XXX). In the latter case, if the target is not in

Re: [Python-ideas] High Precision datetime

On 05/10/2018 10:30 AM, Ed Page wrote: Alternatives - My company create our own datetime library - Continued fracturing of time ... ecosystem (datetime, arrow, pendulum, delorean, datetime64, pandas.Timestamp Or, team up with one of those (if you can). -- ~Ethan~

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On 05/10/2018 09:29 AM, M.-A. Lemburg wrote: On 10.05.2018 15:57, Guido van Rossum wrote: On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg wrote: To a (former Pascal) programmer, a := 1 doesn't read like an operator. It's an assignment expression. If embedded expressions is where Python is

Re: [Python-ideas] A "local" pseudo-function

On 04/29/2018 01:20 PM, Tim Peters wrote: So, e.g., """ a = 42 def showa(): print(a) def run(): global a local a: # assuming this existed a = 43 showa() showa() """ would print 43 and then 42. Which makes "local a:" sound senseless on the face of it

Re: [Python-ideas] A "local" pseudo-function

On 04/28/2018 10:16 AM, Tim Peters wrote: ... but do realize that since PEP 572 dropped any notion of sublocal scopes, that recurring issue remains wholly unaddressed regardless. If we need a sublocal scope, I think the most Pythonic* route to have it would be: with sublocal():

Re: [Python-ideas] A "local" pseudo-function

On 04/27/2018 07:37 PM, Tim Peters wrote: Idea: introduce a "local" pseudo-function to capture the idea of initialized names with limited scope. Note: the thing I'm most interested in isn't debates, but in whether this would be of real use in real code. I keep going back and forth on the

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

On 04/25/2018 03:15 AM, Ivan Levkivskyi wrote: On 25 April 2018 at 11:03, Serhiy Storchaka wrote: Creating a new function is very cheap -- just around 50 ns on my computer. Creating a new class is over two orders costly -- around 7 us for an empty class on my computer. Creating a new Enum

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

On 04/24/2018 10:32 AM, Antoine Pitrou wrote: Also beware the import time cost of having a widely-used module like "warnings" depend on the "enum" module and its own dependencies. With all the recent changes to Python, I should go through and see which dependencies are no longer needed. --

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

On 04/10/2018 10:32 PM, Chris Angelico wrote: PEP: 572 Title: Assignment Expressions Author: Chris Angelico Chris, I think you've gotten all the feedback you need. Pick a symbol (I'd say either ":=" or "as"), and slap this puppy over onto python-dev. -- ~Ethan~

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

On 04/16/2018 10:36 AM, Chris Angelico wrote: Not after it got trimmed, no. Here's what I actually said in my original post: while (read_next_item() -> items[i + 1 -> i]) is not None: print("%d/%d..." % (i, len(items)), end="\r") Now, if THAT is your assignment target, are you still as

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

On 04/14/2018 08:08 PM, Nick Coghlan wrote: New keyword based target first proposal: while (value from read_next_item()) is not None: ... I could get behind this. Current preferencs: "as" +1 "from" +0.85 ":=" +0.5 -- ~Ethan~

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

On 04/13/2018 05:02 AM, Jacco van Dorp wrote: I must admit I like putting the expression first, though. Even if it's just to make it harder to mix it up with normal assignment. Perhaps => could be used - it's a new token, unlike -> which is used to annotate return values, it's not legal syntax

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

On 04/12/2018 09:52 PM, Chris Angelico wrote: foo := a > b # does this capture 'a', or 'a > b'? bar := c + d # 'c' or 'c + d'? I'm open to argument here, but my thinking is that these should capture 'a' and 'c + d'. I think := should act the same as = or there will be plenty of

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

On 04/10/2018 10:32 PM, Chris Angelico wrote: Title: Assignment Expressions Thank you, Chris, for doing all this! --- Personally, I'm likely to only use this feature in `if` and `while` statements; if the syntax was easier to read inside longer expressions then I might use this elsewhere

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

On 04/10/2018 10:32 PM, Chris Angelico wrote: Migration path == The semantic changes to list/set/dict comprehensions, and more so to generator expressions, may potentially require migration of code. In many cases, the changes simply make legal what used to raise an exception, but

Re: [Python-ideas] Move optional data out of pyc files

On 04/10/2018 10:54 AM, Zachary Ware wrote: On Tue, Apr 10, 2018 at 12:38 PM, Chris Angelico wrote: A deployed Python distribution generally has .pyc files for all of the standard library. I don't think people want to lose the ability to call help(), and unless I'm

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 04/05/2018 05:37 PM, Steven D'Aprano wrote: On Thu, Apr 05, 2018 at 05:31:41PM -0700, Ethan Furman wrote: [snip unkind words] Be fair. Strip out the last "from average = 0" and we have little that isn't either in Python or is currently being proposed elsewhere. Ug

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 04/05/2018 03:24 PM, Peter O'Connor wrote: Well, whether you factor out the loop-function is a separate issue. Lets say we do: smooth_signal = [average = compute_avg(average, x) for x in signal from average=0] Is just as readable and maintainable as your expanded version, but saves

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 04/05/2018 09:52 AM, Peter O'Connor wrote: [snip html code snippets] Please don't use html markup. The code was very difficult to read. -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Fixing class scope brainstorm

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 issues for comprehensions and genexprs. Removing the implicit function scope in comprehensions is something I wanted

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/25/2018 09:46 AM, Ethan Furman wrote: On 03/24/2018 09:24 PM, Nick Coghlan wrote: No, the fact that the expression defining the outermost iterable gets evaluated in the outer scope is behaviour that's explicitly tested for in the regression test suite. The language reference spells out

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/24/2018 09:24 PM, Nick Coghlan wrote: No, the fact that the expression defining the outermost iterable gets evaluated in the outer scope is behaviour that's explicitly tested for in the regression test suite. The language reference spells out that this is intentional for generator

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/24/2018 09:00 PM, Chris Angelico wrote: On Sun, Mar 25, 2018 at 2:59 PM, Ethan Furman wrote: On 03/24/2018 08:51 PM, Chris Angelico wrote: Let's suppose we have assignment expressions. I'm going to use "(expr as name)" syntax for this example. a = [(1 as b) for c in (d a

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/24/2018 08:51 PM, Chris Angelico wrote: On Sun, Mar 25, 2018 at 2:48 PM, Ethan Furman wrote: On 03/24/2018 01:35 AM, Nick Coghlan wrote: In comprehensions and generator expressions, we'd need to explain why inline assignments in the outermost iterator expression leak but those in filter

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/24/2018 01:35 AM, Nick Coghlan wrote: In comprehensions and generator expressions, we'd need to explain why inline assignments in the outermost iterator expression leak but those in filter expressions, inner iterator expressions, and result expressions don't. I don't understand --

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 03/24/2018 09:27 AM, Rob Cliffe via Python-ideas wrote: On 24/03/2018 14:44, Steven D'Aprano wrote: On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote: For PEP 572, the most directly comparable example is code like this: # Any previous binding of "m" is lost completely on

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 03/24/2018 07:44 AM, Steven D'Aprano wrote: I don't think we need sub-function scoping. I think it adds more complexity that outweighs whatever benefit it gives. +1 -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/23/2018 07:38 PM, Chris Angelico wrote: On Sat, Mar 24, 2018 at 3:58 AM, Guido van Rossum wrote: On Fri, Mar 23, 2018 at 9:34 AM, Christoph Groth wrote: But wouldn't it be a good alternative to PEP 572 to *add* an assignment operator that is an expression to Python, and is distinct

Re: [Python-ideas] Class autoload

On 03/03/2018 10:46 AM, Jamesie Pic wrote: While i understand it would be harder to make it memory efficient, but this is python not go, and also this sort feature could be easily optional, also, it might even help against circular import issues, whoever hasn't imported a module from inside a

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 03/02/2018 11:11 PM, Nick Coghlan wrote: On 3 March 2018 at 03:51, Ethan Furman wrote: Ah, right. Since the PEP primarily covers comprehensions, but then went on to discuss multi-line statements, I had forgotten the comprehension part. The answer is easy: assignment expressions

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/02/2018 07:30 PM, Chris Angelico wrote: On Sat, Mar 3, 2018 at 12:48 PM, Greg Ewing wrote: Chris Angelico wrote: It would NOT work for anything where the bool() of the desired object doesn't exactly match the loop's condition. while condition(x) where x = something(): ...

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/02/2018 12:47 PM, Robert Vanden Eynde wrote: @Chris @Rohdri (@Jonathan below) For morons like me who didn't know what "top-posting" was, I went on Wikipedia (https://en.m.wikipedia.org/wiki/Posting_style ). You looked it up and researched

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/02/2018 09:34 AM, David Mertz wrote: So right now, I can do these: class bind(object): def __init__(self, *args): self.args = args def __enter__(self): return self.args[0] if len(self.args)==1 else self.args def __exit__(self,

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/02/2018 08:04 AM, Chris Angelico wrote: On Sat, Mar 3, 2018 at 1:53 AM, Rhodri James wrote: On 02/03/18 11:43, Chris Angelico wrote: # Compound statements usually enclose everything... if (re.match(...) as m): print(m.groups(0)) print(m) # NameError This

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/02/2018 03:43 AM, Chris Angelico wrote: PEP: 572 Title: Syntax for Statement-Local Name Bindings Author: Chris Angelico Looks nice, thanks for the updates! Alternative proposals = 6. Allowing ``(EXPR as NAME)`` to assign to any form of name.

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 03/02/2018 02:47 AM, Nick Coghlan wrote: On 2 March 2018 at 16:39, Ethan Furman wrote: On 03/01/2018 09:08 PM, Nick Coghlan wrote: Adding statement local variables into that mix *without* some form of syntactic marker would mean taking an already complicated system, and making it even

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 03/01/2018 09:08 PM, Nick Coghlan wrote: On 1 March 2018 at 19:30, Paul Moore

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 02/28/2018 01:48 PM, Robert Vanden Eynde wrote: We are currently like a dozen of people talking about multiple sections of a single subject. Isn't it easier to talk on a forum? No. *Am I the only one* who thinks mailing list isn't easy when lots of people talking about multiple

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 02/28/2018 12:16 PM, Alex Walters wrote: For what its worth, I'm +1 on it. I actually like that it would allow: while (something() as var): something_else(var) ...without being a bug magnet. The bug magnet isn't the assignment of a name in the condition of a while loop, it's the

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 02/27/2018 02:27 PM, Chris Angelico wrote: PEP: 572 Because: a = (2 as a) does not evaluate to 2 and because some statements, such as 'for' and 'while' can cover many, many lines (leaving plenty of potential for confusion over which variable disappear at the end and which persist):

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 02/28/2018 02:43 AM, Chris Angelico wrote: On Wed, Feb 28, 2018 at 8:04 PM, Robert Vanden Eynde wrote: 3) "C problem that an equals sign in an expression can now create a name binding, rather than performing a comparison." The "=" does variable assignement already, and there is no grammar

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 02/27/2018 09:23 PM, Chris Angelico wrote: On Wed, Feb 28, 2018 at 2:47 PM, Rob Cliffe via Python-ideas wrote: And here's a thought: What are the semantics of a = (42 as a) # Of course a linter should point this out too At first I thought this was also a laborious synonym for "a=42".

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

On 02/18/2018 05:57 PM, Nick Coghlan wrote: On 17 February 2018 at 02:31, Ethan Furman wrote: On 02/15/2018 11:55 PM, Nick Coghlan wrote: However, while I think that looks nicer in general, we'd still have to choose between two surprising behaviours: * implicitly delete the statement locals

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

On 02/15/2018 11:55 PM, Nick Coghlan wrote: On 16 February 2018 at 12:19, rym...@gmail.com wrote: I don't know...to me this looks downright ugly and an awkward special case. It feels like it combines reading difficulty of inline assignment with the awkwardness of a magic word and the ugliness

Re: [Python-ideas] Extending __format__ method in ipaddress

On 02/14/2018 02:29 PM, Eric Osborne wrote: Nick Coghlan suggested I instead extend __format__, which is what the diffs in the current pull request do. This allows a great deal more flexibility: the current code takes 'b', 'n', or 'x' types, as well as the '#' option and support for the '_'

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 01/17/2018 10:59 PM, Steven D'Aprano wrote: On Thu, Jan 18, 2018 at 05:22:06PM +1100, Chris Angelico wrote: I haven't yet seen any justification for syntax here. The nearest I've seen is that this "ensure" action is more like: try: cond = x >= 0 except BaseException: raise

Re: [Python-ideas] make Connections iterable

On 01/09/2018 08:27 AM, Chris Angelico wrote: On Tue, Jan 9, 2018 at 11:12 PM, Random832 wrote: On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote: If you view them as comparable to subprocess pipes, then it can be surprising that they're not iterable when using a

Re: [Python-ideas] Decorator for creating enumeration?

On 12/10/2017 09:50 AM, Guido van Rossum wrote: There's a third-party enum package. Maybe you can contribute an implementation of this idea there. If it becomes popular maybe we can add it to the stdlib enum module. The third-party library in question is aenum (enum34 isn't getting new

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

On 12/08/2017 04:33 AM, Erik Bray wrote: More importantly not as many objects that coerce to int actually implement __index__. They probably *should* but there seems to be some confusion about how that's to be used. __int__ is for coercion (float, fraction, etc) __index__ is for true

Re: [Python-ideas] a sorting protocol dunder method?

On 12/04/2017 10:01 AM, brent bejot wrote: This is certainly a good pattern to use in the current and older versions, but I think we can all agree that defining __key__ and calling "sorted(list_of_attrdicts)" has that syntactic sugar that is oh-so-sweet-and-tasty. Actually, no, we do not

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 11/28/2017 08:03 AM, Ivan Pozdeev via Python-ideas wrote: On 28.11.2017 16:36, Nick Coghlan wrote: it doesn't need to be a statement any more > Another benefit of a statement vs function is only evaluating the error-related arguments when there's an error The bulk of any processing

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

On 11/16/2017 05:56 AM, bunslow wrote: I realize at the end of the day this is a pretty trivial and ultimately meaningless nit to pick, Not at all -- documentation is extremely important. but I've never contributed before and have a variety of similar minor pain points in the docs/stdlib,

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

On 11/15/2017 10:10 PM, Greg Ewing wrote: Steven D'Aprano wrote: These are not equivalent: B < S, E B < E, S Not in general, but in many cases they will be, e.g. if E and S have no method names in common. I think the OP is implying that his case is one of those. Maybe what's really wanted

Re: [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?

On 11/07/2017 03:12 PM, Soni L. wrote: exec("def one(x):\n [r] = x\n return r") # who says python doesn't have one-liners? (ofc, some would argue you should use: one = (lambda x: (lambda y: y)(*x)) Most would argue that def one(x): [r] = x return r is the appropriate code. --

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

On 11/06/2017 06:48 AM, brent bejot wrote: On Mon, Nov 6, 2017 at 9:21 AM, Gyro Funch wrote: Would this mean that other packages in the stdlib with development cycles faster than those of python could use the same bundling mechanism? This is pretty much how I thought things worked for all

Re: [Python-ideas] Hello from a new lurker

On 11/01/2017 10:49 AM, brent bejot wrote: The python-dev website said I should introduce myself before lurking around for a while. So hi! I've been using python for 7 or so years now, live on the east coast of the U.S., grew up in Nebraska, and occasionally play the tuba and table-top

Re: [Python-ideas] PEP draft: context variables

On 10/13/2017 03:30 PM, Yury Selivanov wrote: At this time, we have so many conflicted examples and tangled discussions on these topics, that I myself just lost what everybody is implying by "this semantics isn't obvious to *me*". Which semantics? It's hard to tell. For me, it's not apparent

Re: [Python-ideas] PEP draft: context variables

On 10/13/2017 09:48 AM, Steve Dower wrote: On 13Oct2017 0941, Yury Selivanov wrote: Actually, capturing context at the moment of coroutine creation (in PEP 550 v1 semantics) will not work at all. Async context managers will break. class AC: async def __aenter__(self):

Re: [Python-ideas] Make map() better

On 09/15/2017 11:03 AM, Jason H wrote: From: "Steven D'Aprano" >> Um... what's in it for *us*? What benefit do we get? > How that question is answered, depends on who is 'us'? If you're a bunch of > python purist greybeards, then conceivably nothing. How about refugees

Re: [Python-ideas] PEP 550 v2

On 08/23/2017 08:41 AM, Guido van Rossum wrote: If we're extending the analogy with thread-locals we should at least consider making each instantiation return a namespace rather than something holding a single value. +1 -- ~Ethan~ ___ Python-ideas

Re: [Python-ideas] PEP 550 v2

On 08/16/2017 08:43 AM, Yury Selivanov wrote: To be honest, I really like Execution Context and Local Context names. I'm curious if other people are confused with them. +1 confused :/ -- ~Ethan~ ___ Python-ideas mailing list

Re: [Python-ideas] PEP 550 v2

On 08/17/2017 02:40 AM, Nick Coghlan wrote: On 17 August 2017 at 04:38, Yury Selivanov wrote: ck.get_value() attempts to look up the value for that key in the currently active execution context. If it doesn't find one, it then tries each of the execution contexts in the currently

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

On 07/26/2017 09:05 AM, Nick Coghlan wrote: On 26 July 2017 at 11:05, Steven D'Aprano wrote: I don't see any way that this proposal can be anything by a subtle source of bugs. We have two *incompatible* requirements: - we want to define the order of the fields according

[Python-ideas] namedtuple redesign goals

On 07/23/2017 10:47 AM, Michel Desmoulin wrote: > I'm not sure why everybody have such a grip on the type. If I understand the goal of "a new namedtuple" correctly, it is not to come up with yet another namedtuple type -- it is to make the existing collections.namedtuple a faster experience,

Re: [Python-ideas] a new namedtuple

On 07/18/2017 09:09 AM, Guido van Rossum wrote: On Tue, Jul 18, 2017 at 8:56 AM, Ethan Furman wrote: I certainly don't expect the signature to change, but why is using a metaclass out? The use (or not) of a metaclass /is/ an implementation detail. It is until you try to subclass

Re: [Python-ideas] a new namedtuple

On 07/17/2017 06:25 PM, Eric Snow wrote: On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman wrote: Guido has decreed that namedtuple shall be reimplemented with speed in mind. FWIW, I'm sure that any changes to namedtuple will be kept as minimal as possible. Changes would be limited

Re: [Python-ideas] a new namedtuple

On 07/17/2017 06:34 PM, Steven D'Aprano wrote: On Mon, Jul 17, 2017 at 05:01:58PM -0700, Ethan Furman wrote: Guido has decreed that namedtuple shall be reimplemented with speed in mind. I haven't timed it (I'm hoping somebody will volunteer to be the bench mark guru), I'll offer my

<    1   2   3   4   >