[Python-Dev] Re: PEP 701 – Syntactic formalization of f-strings

Great stuff! 😁 Rob Cliffe On 19/12/2022 17:59, Pablo Galindo Salgado wrote: Hi everyone, I am very excited to share with you a PEP thatBatuhan Taskaya, Lysandros Nikolaou and myself have been working on recently:PEP 701 - PEP 701 – Syntactic formalization of f-strings

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

wrote: On Thu, Dec 01, 2022 at 10:18:49PM +, Rob Cliffe via Python-Dev wrote: Wild suggestion:     Make None.__hash__ writable. E.g.     None.__hash__ = lambda : 0 # Currently raises AttributeError: 'NoneType' object attribute '__hash__' is read-only You would have to

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

You're right of course.  Oh well, it *was* a wild idea.😁 Rob Cliffe On 04/12/2 On 04/12/2022 18:16, Chris Angelico wrote: On Mon, 5 Dec 2022 at 05:11, Rob Cliffe via Python-Dev wrote: Wild suggestion: Make None.__hash__ writable. E.g. None.__hash__ = lambda : 0 # Curr

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

Wild suggestion:     Make None.__hash__ writable. E.g.     None.__hash__ = lambda : 0 # Currently raises AttributeError: 'NoneType' object attribute '__hash__' is read-only Best wishes Rob Cliffe On 01/12/2022 11:02, Oscar Benjamin wrote: On Thu, 1 Dec 2022 at 06:56, Chris Angelico wrote: On

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

Thank you for this very clear analysis, Oscar. It seems to me that this strengthens the OP's case.  I am curious as to whether others agree. Best wishes Rob Cliffe On 30/11/2022 13:35, Oscar Benjamin wrote: On Tue, 29 Nov 2022 at 23:46, Steven D'Aprano wrote: On Tue, Nov 29, 2022 at 08:51:09

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

On 26/04/2022 20:48, Carl Meyer via Python-Dev wrote: On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote: I also would like to hear more about the problem this is trying to solve, when th real-world examples. (E.g. from pydantic?) Yes please. I think these threads have jumped far too q

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

One reason I dislike this whole proposal is that I can see forward declarations (FDs) ending up in code that doesn't need them.  This could happen if     (a) The FDs were needed at some point, but then the type declarations were taken out.  This could happen with someone modifying their own cod

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

UGH! I thought there was a general understanding that when typing was added to Python, there would be no impact, or at least minimal impact, on people who didn't use it.  (Raises hand.) Now we see an(other) instance of intention creep. Rob Cliffe On 23/04/2022 02:13, Larry Hastings wrote:

[Python-Dev] Re: The current state of typing PEPs

I assume you accidentally pressed Send prematurely. Still, maybe you have inadvertently listed everything that is agreed about typing PEPs. 😂 Rob Cliffe On 02/12/2021 23:20, Christopher Barker wrote: >for library authors. Providing high quality stubs and the best user experience is not

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

Heh. We could update PEP 8 to ban type annotations, then watch as the people who over-zealously apply PEP 8 to everything AND over-zealously insist on adding type annotations to everything have their heads explode. -- Steve I love it! "Surtout, pas trop de zèle"

[Python-Dev] Re: Optimizing literal comparisons and contains

I am slightly surprised that it seems to be *easier* to fold selected constant expressions than to have more generic code to fold them all. Or at least, all those that don't contain containers, such as     1 in [0,1,2] Rob Cliffe On 28/11/2021 21:10, Eric V. Smith wrote: On Nov 28, 2021, at 3:0

[Python-Dev] Re: The current state of typing PEPs

My 2¢ from a position of *extreme ignorance*, not to mention zero interest in annotations (all welcome to shoot me down in flames, or treat me with contemptuous silence.  But *occasionall*y the "idiot's" point of view is worth considering, so here goes). ISTM that typing/annotations have been

[Python-Dev] Re: The current state of typing PEPs

On 25/11/2021 15:15, Stephen J. Turnbull wrote: Executive summary: The typing-suspicious crowd has a valid complaint about PEPs 563 and 649, but it's not that they weren't warned. “As you will no doubt be aware, the plans for development of the outlying regions of the Galaxy require the bui

[Python-Dev] Re: The current state of typing PEPs

On 21/11/2021 11:04, Paul Moore wrote: On Sun, 21 Nov 2021 at 07:50, Christopher Barker wrote: It's becoming harder and harder for people not particularly interested in static typing to simply ignore it (Raises hand.)  +1 Rob Cliffe ___ Python-Dev

[Python-Dev] Re: containment and the empty container

On 08/11/2021 21:43, Ethan Furman wrote: When is an empty container contained by a non-empty container? For example: These examples are not at all analogous.  `a in b` has different meanings for different classes of b. {} in {1:'a', 'b':2]   <-- TypeError because of hashability `x in aDict`

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

Data point: I find all the examples in PEP 505 less readable using the proposed new operators. Trying to explain why: The syntax feels *too* compact (Perl-like?) - when reading it, every time you see a None-aware operator (*if* you notice it), you have to jerk to a halt and say, "Whoa!  What's g

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

This is very reminiscent of the (rejected) PEP 463, Exception-catching expressions (which I still hope will be resurrected some day).  It would allow you to write     y = (config["handler"]["parameters"]["y"] except KeyError: None) (possibly the parentheses might not be required) which IMO is ev

[Python-Dev] Re: PEP 654 except* formatting

On 04/10/2021 00:57, Barry Warsaw wrote: On Oct 3, 2021, at 10:42, Łukasz Langa wrote: Speaking just for myself, the `except *` syntax always bothered me, but I couldn’t come up with anything better and it wasn’t enough for me to vote against PEP 654. `except group` is nicer though, and I

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On 09/09/2021 18:54, raymond.hettin...@gmail.com wrote: I would rather keep `bchr` and lose the `.fromint()` methods. For me, "bchr" isn't a readable name. If I expand mentally expand it to "byte_character", it becomes an oxymoron that opposes what we try teach about bytes and characters be

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On 08/09/2021 21:21, Christopher Barker wrote: [snip] NOTE: my objection to “bchr”, whether as a builtin or not is not the functionality, it’s the name. [snip] Why not byte() ? I happened to need to convert an integer to a byte recently and I settled on     bytes((i,)) I don't know if I

[Python-Dev] Re: Need help to debug a ssl crash on Windows which prevents merging PRs

Well done Victor! This stuff is way over my head, but rest assured that humble Python programmers like me appreciate all the effort put in from guys like you into improving Python. Rob Cliffe On 01/06/2021 23:14, Victor Stinner wrote: On Fri, May 28, 2021 at 6:40 PM Victor Stinner wrote: In

[Python-Dev] Re: PEP 563 in light of PEP 649

On 19/04/2021 22:01, Antoine Pitrou wrote: Almost nobody uses -O. Optimizations that are enabled only in -O are useless. Data point: I use -O.¹  Not frequently, not usually, but I have a few large² programs that I add features to from time to time and will doubtless continue to do so.  I need

[Python-Dev] Re: Typing syntax and ecosystem

On 13/04/2021 23:21, Barry Warsaw wrote: I would still be opposed to requiring type hinting in Python. -Barry (Gasps in horror.)  I can only hope I've misunderstood this sentence.  Has it ever been even tentatively suggested that type hinting become mandatory?  (What would that even mean: t

[Python-Dev] Re: NamedTemporaryFile and context managers

Well this works: from tempfile import NamedTemporaryFile import os with NamedTemporaryFile(delete=False) as fp:   fp.write(b'some data')   fp.close()   with open(fp.name, 'rb') as fp2:     data = fp2.read()   os.remove(fp.name) assert data == b'some data' Of course it is

[Python-Dev] Re: 3.10 change (?) for __bool__

On 12/01/2021 15:53, Mark Shannon wrote: Hi everyone, In master we convert `if x: pass` to `pass` which is equivalent, unless bool(x) has side effects the first time it is called. This is a recent change. Suppose x is not a currently valid variable name at runtime.  Will the NameError s

[Python-Dev] Re: os.scandir bug in Windows?

On 19/10/2020 12:42, Steve Dower wrote: On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote: TLDR: In os.scandir directory entries, atime is always a copy of mtime rather than the actual access time. Correction - os.stat() updates the access time to _now_, while os.scandir() returns the

[Python-Dev] Re: os.scandir bug in Windows?

, 2020 at 7:25 PM Rob Cliffe via Python-Dev mailto:python-dev@python.org>> wrote: TLDR: In os.scandir directory entries, atime is always a copy of mtime rather than the actual access time. Demo program: Windows 10, Python 3.8.3: # osscandirtest.py import time,

[Python-Dev] os.scandir bug in Windows?

TLDR: In os.scandir directory entries, atime is always a copy of mtime rather than the actual access time. Demo program: Windows 10, Python 3.8.3: # osscandirtest.py import time, os with open('Test', 'w') as f: f.write('Anything\n') # Write to a file time.sleep(10) with open('Test', 'r') as f

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 30/07/2020 00:34, Nick Coghlan wrote: the proposed name binding syntax inherently conflicts with the existing assignment statement lvalue syntax in two areas: * dotted names (binds an attribute in assignment, looks up a constraint value in a match case) * underscore targets (binds in ass

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 03/08/2020 17:37, MRAB wrote: [snip] A thought occurred to me. By default, the current rules of the PEP could apply, but why not allow prefixing with "as" for a capture and "is" for a value? Yes, I know, comparison of the values is not by identity, but "is" is a short keyword that alrea

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Welcome to python-dev, Rik!  Of course you can email to this list. On 30/07/2020 14:30, Rik de Kort via Python-Dev wrote: I think adding the Walrus operator is trying to solve a problem that doesn't exist. Compare the example from the PEP:     [snip] case (x, y, z): [snip] To the

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 31/07/2020 17:24, Rik de Kort via Python-Dev wrote: 1. Semantic operator overloading in generic contexts is very different from this use case. It's surrounded by a clear context. 2. Python programmer intuition varies across python programmers, and I would find it hella unintuitive if I had

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 08/07/2020 16:02, Guido van Rossum wrote: Today I’m happy (and a little trepidatious) to announce the next version of PEP 622, Pattern Matching. After all the discussion on the issue, I can still not stop thinking that there needs to be a visual distinction between "capture" and "match" va

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

I think we are storing up trouble unless we     1) Allow arbitrary expressions after `case`, interpreted *as now*     2) Use *different* syntaxes, not legal in expressions, for             alternative matching values (i.e. not `|` or `or`) (NB simply stacking with multiple `case` lines is one pos

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 24/06/2020 20:38, Guido van Rossum wrote: Everyone, If you've commented and you're worried you haven't been heard, please add your issue *concisely* to this new thread. Note that the following issues are already open and will be responded to separately; please don't bother commenting on

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

Without arguing for or against allowing a capture variable, IMO rather than syntax like     match into : it would be far better (and not require a new keyword) to write this as     with as match : Rob Cliffe On 24/06/2020 20:38, Guido van Rossum wrote: Everyone, If you've commented and you'r

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 18/07/2020 11:23, emmanuel.coir...@caissedesdepots.fr wrote: Ethan Furman wrote: The problem with any kind of sigil/keyword is that it becomes line noise -- we would have to train ourselves to ignore them in order to see the structure and variables we are actually interested in. Once we be

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 16/07/2020 18:13, MRAB wrote: On 2020-07-16 17:37, Steve Holden wrote: While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with try/except/except/.../finally/e

[Python-Dev] Re: PEP 622 constant value syntax idea

On 16/07/2020 08:16, Baptiste Carvello wrote: Hello, Le 15/07/2020 à 13:37, Mohammad Foroughi via Python-Dev a écrit : Hi, I had an idea regarding the pattern matching issue of comparing with a previous constant variable instead of assigning to a new local variable. I'm not sure if this has b

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 08/07/2020 16:15, MRAB wrote: On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote: Why not use '=' to distinguish binding from equality testing:       case Point(x, =y): # matches a Point() with 2nd parameter equal to y; if it does, binds to x. This would allow a future (

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 12/07/2020 02:04, Guido van Rossum wrote: On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico > wrote: Hang on. Matching happens before assignment, so this should use the previous value of x for the matching. At least, that's my understanding. If you do some

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

One thing I don't understand about the PEP:     case [x,y]: IIUC matches any 2-element sequence. How would you match specifically a 2-item list (say)? Would it be     case list([x,y]): I would appreciate it if some kind person could enlighten me. TIA Rob Cliffe

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 08/07/2020 16:02, Guido van Rossum wrote: ```     USE_POLAR = "polar"     USE_RECT = "rect" ``` Now we would like to be able to replace those literals with the corresponding names throughout our code and have everything work like before: ```     match t:         case (USE_RECT, real, imag):

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

Why not use '=' to distinguish binding from equality testing:     case Point(x, =y): # matches a Point() with 2nd parameter equal to y; if it does, binds to x. This would allow a future (or present!) extension to other relative operators:     case Point(x, >y): (although the syntax doesn't AF

[Python-Dev] Re: PEP 622 railroaded through?

I would like to thank everyone who responded to me for their civilised and courteous replies.  I actually expected to get a lot of slagging off, but was prepared to accept that for what seemed to me at the time to be a legitimate concern. If my fears were unfounded, I am delighted. If I have be

[Python-Dev] PEP 622 railroaded through?

Whoa! I have an uneasy feeling about this PEP. AFAIK the usual procedure for adding a new feature to Python is:     An idea is raised and attracts some support.     Someone sufficiently motivated writes a PEP.     The PEP is thoroughly discussed.     Eventually a consensus (or at least an "agree

[Python-Dev] Re: Flexible assignment targets

On 03/07/2020 00:12, Nick Coghlan wrote: On Fri., 3 Jul. 2020, 2:27 am MRAB, > wrote: IMHO, the assignment statement should remain as it is, not sometimes assign and sometimes not. There could be another form that does matching:      try ?x

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Yes, my brain went through the same path. Another minor nitpick: It would be kinda nice if the various types of pattern were listed in the grammar in the same order as the corresponding paragraphs subsequently appear. On 26/06/2020 11:53, Daniel Moisset wrote: Just a minor editorial thing on

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 23/06/2020 20:35, Chris Angelico wrote: On Wed, Jun 24, 2020 at 5:30 AM Rob Cliffe via Python-Dev wrote: The PEP is great, but this strikes me as horribly confusing, given that 401|403|404 is already legal syntax. IIUC any legal expression can come between `case` and `:`, but expressions

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Some proof-reading of the PEP.  I apologise if this is out of date. 1) In the beginning of the "Mapping Pattern" section:         "{" (pattern ":" pattern)+ "}"     This is spelt inconsistently: there is a `+` before the closing `}` but not after the opening `{`. 2) The second code snippe

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

Without arguing for or against allowing a capture variable, IMO rather than syntax like     match into : it would be far better (and not require a new keyword) to write this as     with as match : Rob Cliffe PS:  Or     = match On 24/06/2020 20:38, Guido van Rossum wrote: Everyone, If you'

[Python-Dev] Re: PEP 622: Structural Pattern Matching

I also (with others) prefer `else:` or perhaps `case else:` to using the`_` variable. The latter is obscure, and woudn't sit well with code that already uses that variable for its own purposes. I think that's done for consistency. '_' is a wildcard and you can have:     case (_, _): to mat

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 23/06/2020 17:01, Guido van Rossum wrote: You can combine several literals in a single pattern using `|` ("or"): ```py         case 401|403|404:             return "Not allowed" The PEP is great, but this strikes me as horribly confusing, given that 401|403|404 is already legal syntax. II

[Python-Dev] REPL output bug

If I run the following program (using Python 3.8.3 on a Windows 10 laptop): import sys, time for i in range(1,11):     sys.stdout.write('\r%d' % i)     time.sleep(1) As intended, it displays '1', replacing it at 1-second intervals with '2', '3' ... '10'. Now run the same code inside the REPL:

[Python-Dev] Re: Improvement to SimpleNamespace

Here's another revolutionary thought:  add a new operator and associated dunder method (to object?) whose meaning is *undefined*.  Its default implementation would do *nothing* useful (raise an error? return None?). E.g. suppose the operator were `..` Then in a specific class you could implement

[Python-Dev] Re: Comments on PEP 554 (Multiple Interpreters in the Stdlib)

On 22/04/2020 19:40, Ned Batchelder wrote: On 4/21/20 12:32 PM, Mark Shannon wrote: Hi, I'm generally in favour of PEP 554, but I don't think it is ready to be accepted in its current form. BTW, thanks for including the name of the PEP in the subject.  As a casual reader of this list, i

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 28/03/2020 17:02, Victor Stinner wrote: What do you think of adding a Version History section which lists most important changes since your proposed the first version of the PEP? I recall: * Version 3: don't accept tuple * Version 2: Rename cutprefix/cutsuffix to removeprefix/removesuffix,

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

Sorry, another niggle re handling an empty affix:  With your Python implementation, 'aba'.cutprefix(('', 'a')) == 'aba' 'aba'.cutsuffix(('', 'a')) == 'ab' This seems surprising. Rob Gadfly Cliffe On 22/03/2020 23:23, Dennis Sweeney wrote: Much appreciated! I will add that single quote and chan

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 22/03/2020 22:25, Dennis Sweeney wrote: Here's an updated version. Online: https://www.python.org/dev/peps/pep-0616/ Source: https://raw.githubusercontent.com/python/peps/master/pep-0616.rst Changes: - More complete Python implementation to match what the type checking in the C imple

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 21/03/2020 20:16, Ned Batchelder wrote: On 3/21/20 12:51 PM, Rob Cliffe via Python-Dev wrote: On 21/03/2020 16:15, Eric V. Smith wrote: On 3/21/2020 11:20 AM, Ned Batchelder wrote: On 3/20/20 9:34 PM, Cameron Simpson wrote: On 20Mar2020 13:57, Eric Fahlgren wrote: On Fri, Mar 20

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 21/03/2020 16:15, Eric V. Smith wrote: On 3/21/2020 11:20 AM, Ned Batchelder wrote: On 3/20/20 9:34 PM, Cameron Simpson wrote: On 20Mar2020 13:57, Eric Fahlgren wrote: On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney wrote: If ``s`` is one these objects, and ``s`` has ``pre`` as a pref

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 20/03/2020 22:21, Victor Stinner wrote: Motivating examples from the Python standard library The examples below demonstrate how the proposed methods can make code one or more of the following: (...) IMO there are too many examples. For

[Python-Dev] Python Profilers documentation - typo?

The documentation at     https://docs.python.org/3.2/library/profile.html contains the sentence     For example, if your_integer_time_func() returns times measured in thousands of seconds, you would construct the Profile instance as follows: "thousands of seconds" should ISTM be "thousandths of

[Python-Dev] Re: The Python 2 death march

On 24/09/2019 04:21:45, Benjamin Peterson wrote: On Fri, Sep 13, 2019, at 18:18, Sumana Harihareswara wrote: Hi. I've joined python-dev to participate in this thread (I don't have email delivery turned on; I'll be checking back via the web). sorry :) Benjamin, I am sorry that I didn't chec

[Python-Dev] Re: PEP 601: discussion-to discuss.python.org

On 04/09/2019 14:53:41, Victor Stinner wrote: A litte bit more context. PEP 601: "Forbid return/break/continue breaking out of finally" https://www.python.org/dev/peps/pep-0601/ Abstract This PEP proposes to forbid return, break and continue statements within a finally suite where they woul

[Python-Dev] Re: What to do about invalid escape sequences

On 15/08/2019 12:17:36, Petr Viktorin wrote: On 8/15/19 10:40 AM, Greg Ewing wrote: If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran: s = 31HThis is a "totally raw" string! Or from Rust: let s = r"Here's a r

[Python-Dev] Re: What to do about invalid escape sequences

On 10/08/2019 23:30:18, Greg Ewing wrote: Rob Cliffe via Python-Dev wrote: Also, the former is simply more *informative* - it tells the reader that baz is expected to be a directory, not a file. On Windows you can usually tell that from the fact that filenames almost always have an

[Python-Dev] Re: What to do about invalid escape sequences

On 10/08/2019 11:50:35, eryk sun wrote: On 8/9/19, Steven D'Aprano wrote: I'm also curious why the string needs to *end* with a backslash. Both of these are the same path: C:\foo\bar\baz\ C:\foo\bar\baz Also, the former is simply more *informative* - it tells the reader that baz i

[Python-Dev] Re: What to do about invalid escape sequences

On 06/08/2019 23:41:25, Greg Ewing wrote: Rob Cliffe via Python-Dev wrote: Sorry, that won't work.  Strings are parsed at compile time, open() is executed at run-time. It could check for control characters, which are probably the result of a backslash accident. Maybe even auto-co

[Python-Dev] Re: PEP 572 TargetScopeError

On 09/08/2019 12:50:14, Steven D'Aprano wrote: On Thu, Aug 08, 2019 at 04:28:28PM -0700, Barry Warsaw wrote: I find it difficult to imagine a more meaningful distinction than that between syntax and semantics. The distinction between syntax and semantics can sometimes be blurred. Certainly in

[Python-Dev] Re: PEP 572 TargetScopeError

On 08/08/2019 22:58:15, Steven D'Aprano wrote: On Thu, Aug 08, 2019 at 10:00:01AM -0700, Barry Warsaw wrote: "The two invalid cases listed above raise TargetScopeError, a new subclass of SyntaxError (with the same signature).” The PEP doesn’t really go into the rationale for why a new except

[Python-Dev] Re: What to do about invalid escape sequences

On 07/08/2019 01:14:08, Chris Angelico wrote: On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano wrote: - Keep the SyntaxWarning silent by default for 3.8. That gives us another year or more to gently pressure third-party libraries to fix their code, and to find ways to encourage developers to r

[Python-Dev] Re: What to do about invalid escape sequences

On 06/08/2019 07:14:35, Michael wrote: For "filenames" you could, perhaps, make an exception in the calls that use them. e.g., when they are hard-coded in something such as open("..\training\new_memo.doc"). Sorry, that won't work.  Strings are parsed at compile time, open() is executed at ru

[Python-Dev] Re: Comparing dict.values()

(but then again, if I don't mention this possibility, maybe someone even more idiotic than me will suggest it ). On 25/07/2019 00:49:56, Rob Cliffe via Python-Dev wrote: On 25/07/2019 00:09:37, David Mertz wrote: I agree with Greg. There are various possible behaviors that might make

[Python-Dev] Re: Comparing dict.values()

On 25/07/2019 00:09:37, David Mertz wrote: I agree with Greg. There are various possible behaviors that might make sense, but having `d.values() != d.values()` is about the only one I can see no sense in. +1 This really feels like a good cade for reading a descriptive exception. If someo

[Python-Dev] Re: Comparing dict.values()

On 24/07/2019 10:31:46, Steven D'Aprano wrote: How does this seem to you? Two dict.values objects are equal if: - they are in fact the same object (identity test on the views); - they are both views of the same dict (identity test on the dicts); - they are views of distinct, but equal, dic

Re: [Python-Dev] Overloading comparison operator for lists

On 27/05/2019 04:52:17, Montana Burr wrote: NumPy arrays have this awesome feature, where array == 3 does an element-wise comparison and returns a list. For example: np.array([1,2,3,4,5])==3 returns [False,False,True,False,False] It would be cool if Python had similar functionality for lis

Re: [Python-Dev] datetime.timedelta total_microseconds

A function with "microseconds" in the name IMO misleadingly suggests that it has something closer to microsecond accuracy than a 1-second granularity. Rob Cliffe On 14/02/2019 05:05:54, Richard Belleville via Python-Dev wrote: In a recent code review, the following snippet was called out as re

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

I apologise for not replying in the form of a Pull Request - I don't know how to make one. On 10/07/2018 02:00, Guido van Rossum wrote: Rationale = Naming the result of an expression is an important part of programming, allowing a descriptive name to be used in place of a longer expre

Re: [Python-Dev] Assignment expression and coding style: the while True case

On 05/07/2018 00:15, Nathaniel Smith wrote: On Wed, Jul 4, 2018 at 3:51 PM, Victor Stinner wrote: My question is now: for which "while True" patterns are the assignment expression appropriate? There identified different patterns. == Pattern 1, straighforward == while True: line = inpu

Re: [Python-Dev] Assignment expression and coding style: the while True case

On 05/07/2018 01:25, Tim Peters wrote: == Pattern 5, two variables == while True:     m = match()     if not m:         break     j = m.end()     if i == j:         break     ... replaced with: while (m := match()) and (j := m.end()) == i: I ass

Re: [Python-Dev] Examples for PEP 572

On 04/07/2018 02:54, Terry Reedy wrote: The 2-argument form of iter is under-remembered and under-used. The length difference is 8.     while (command := input("> ")) != "quit":     for command in iter(lambda: input("> "), "quit"): A general principle that Chris Angelico has repeatedly menti

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 03/07/2018 06:47, Tim Peters wrote: [Rob Cliffe] > It's late to raise this, By months, yes ;-) > but what exactly are the objections to the syntax >         expr -> name  # or variations such as  expr => name > instead of >         name := expr > > The PEP mentions that this syntax does not

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 02/07/2018 19:19, Guido van Rossum wrote: Thank you all. I will accept the PEP as is. I am happy to accept *clarification* updates to the PEP if people care to submit them as PRs to the peps repo (https://github.com/python/peps), and that could even (to some extent) include summaries of di

Re: [Python-Dev] Python3 compiled listcomp can't see local var - bug or feature?

development with Python, rather than development of Python.  (My original use case was a scripting language that could contain embedded Python code).  Thanks to Nick for his original answer. Rob Cliffe On 11/06/2018 23:31, Eric Fahlgren wrote: On Mon, Jun 11, 2018 at 3:10 PM Rob Cliffe via Python-Dev

Re: [Python-Dev] Python3 compiled listcomp can't see local var - bug or feature?

Skip, I think you have misunderstood the  point I was making.  It was not whether the loop variable should leak out of a list comprehension.  Rather, it was whether a local variable should, so to speak, "leak into" a list comprehension.  And the answer is: it depends on whether the code is exec

[Python-Dev] Python3 compiled listcomp can't see local var - bug or feature?

Is this a bug or a feature? Consider the following program: # TestProgram.py def Test():   # global x     x = 1     exec(compile('print([x+1,x+2])', 'MyTest', 'exec'))     exec(compile('print([x+i for i in range(1,3)])', 'MyTest', 'exec')) Test() In Python 2.7.15 the output is [2, 3] [2, 3] In

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

Reading this sub-thread, it struck me that a good way to make PEP 562 more likely to be accepted is to launch an over-the-top attack on it. Then more moderate people - who were/are not necessarily in favour of the PEP - feel pressurised into defending it. Hah! Watch this space for my vicious, v

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

On 17/04/2018 15:01, Chris Angelico wrote: On Tue, Apr 17, 2018 at 10:17 PM, Nick Coghlan wrote: Style guide recommendations === As this adds another way to spell some of the same effects as can already be done, it is worth noting a few broad recommendations. These c

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

On 26/02/2018 19:08, Guido van Rossum wrote: I would like to remind all wannabe language designers that grammar design is not just solving puzzles. It's also about keeping the overall feel of the language readable. I'm getting the idea that none of the proposals discussed so far (whether new

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

On 22/02/2018 19:04, Serhiy Storchaka wrote: Yet one discussion about reusing common subexpressions in comprehensions took place last week on the Python-ideas maillist (see topic "Temporary variables in comprehensions" [1]). The problem is that in comprehension like `[f(x) + g(f(x)) for x in