Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

Stephen J. Turnbull wrote: Benjamin Peterson writes: > > I suppose there's no way to get the compiler to both make "for x in d" > > work as above, and make "for k, v in d" be equivalent to Python 2's > > "for k, v in d.iteritems()"? it would change the meaning of currently correct programs,

Re: [Python-Dev] pep8 reasoning

Chris Angelico wrote: add_HTTP_header add_http_header addHTTPHeader addHttpHeader Five... there are FIVE options... convertXMLtoJSON i.e. don't capitalise a part that follows capitalised initials. -- Greg ___ Python-Dev mailing list Python-Dev@py

Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?

Paul Sokolovsky wrote: Well, here it itches to ask if C++-like offsetting of subclass to base class "this" pointer was considered, I suppose in theory it would be possible to build a new set of __slot__ descriptors for the subclass. It mightn't even be all that difficult. My guess would be tha

Re: [Python-Dev] Returning None from methods that mutate object state

Chris Barker wrote: Personally, I often miss the ability to chain operations on mutable objects, but I can only imagine that that design decision was made for good reason. However, as I teach Python, I find I have nothing to say other than "that's the way it's done in Python". Python has bett

Re: [Python-Dev] Internal representation of strings and Micropython

Serhiy Storchaka wrote: html.HTMLParser, json.JSONDecoder, re.compile, tokenize.tokenize don't use iterators. They use indices, str.find and/or regular expressions. Common use case is quickly find substring starting from current position using str.find or re.search, process found token, advance

Re: [Python-Dev] Internal representation of strings and Micropython

Serhiy Storchaka wrote: A language which doesn't support O(1) indexing is not Python, it is only Python-like language. That's debatable, but even if it's true, I don't think there's anything wrong with MicroPython being only a "Python-like language". As has been pointed out, fitting Python onto

Re: [Python-Dev] Internal representation of strings and Micropython

Glenn Linderman wrote: For that kind of thing, you don't need an actual character index, just some way of referring to a place in a string. I think you meant codepoint index, rather than character index. Probably, but what I said is true either way. This starts to diverge from Python code

Re: [Python-Dev] Internal representation of strings and Micropython

Glenn Linderman wrote: so algorithms that walk two strings at a time cannot use the same StringPosition to do so... yep, this is quite divergent from CPython and Python. They can, it's just that at most one of the indexing operations would be fast; the StringPosition would devolve into an in

Re: [Python-Dev] Internal representation of strings and Micropython

Steven D'Aprano wrote: (1) I asked if it would be okay for MicroPython to *optionally* use nominally Unicode strings limited to ASCII. Pretty much the only response to this as been Guido saying "That would be a pretty lousy option", It would be limiting to have this as the *only* way of deali

Re: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes

Nathaniel Smith wrote: I.e., BIN_ADD could do if (Py_REFCNT(left) == 1) result = PyNumber_InPlaceAdd(left, right); else result = PyNumber_Add(left, right) Upside: all packages automagically benefit! Potential downsides to consider: - Subtle but real and user-visible change in Python se

Re: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes

Nathaniel Smith wrote: I'd be a little nervous about whether anyone has implemented, say, an iadd with side effects such that you can tell whether a copy was made, even if the object being copied is immediately destroyed. I can think of at least one plausible scenario where this could occur:

Re: [Python-Dev] Internal representation of strings and Micropython

Paul Sokolovsky wrote: All these changes are what let me dream on and speculate on possibility that Python4 could offer an encoding-neutral string type (which means based on bytes) Can you elaborate on exactly what you have in mind? You seem to want something different from Python 3 str, Python

Re: [Python-Dev] Internal representation of strings and Micropython

Steven D'Aprano wrote: I don't know about car engine controllers, but presumably they have diagnostic ports, and they may sometimes output text. If they output text, then at least hypothetically car mechanics in Russia might prefer their car to output "правда" and "ложный" rather than "true" an

Re: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes

Julian Taylor wrote: tp_can_elide receives two objects and returns one of three values: * can work inplace, operation is associative * can work inplace but not associative * cannot work inplace Does it really need to be that complicated? Isn't it sufficient just to ask the object potentially be

Re: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes

Nathaniel Smith wrote: For the numpy case, we really need to see all the operands, *and* know what the operation in question is... Okay, I see what you mean now. Given all that, it might be simpler just to have the method perform the operation itself if it can. It has all the information neces

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

Nikolaus Rath wrote: you almost certainly want to do Popen(['/bin/sh', 'for i in `seq 42`; do echo $i; done'], shell=False) because if your shell happens to be tcsh or cmd.exe, things are going to break. On Unix, the C library's system() and popen() functions always use /bin/sh, NOT the user'

Re: [Python-Dev] Criticism of execfile() removal in Python3

Fabio Zadrozny wrote: Well, I must say that the exec(open().read()) is not really a proper execfile implementation because it may fail because of encoding issues... It's not far off, though -- all it needs is an optional encoding parameter. -- Greg

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico mailto:ros...@gmail.com>> wrote: > ISTM what you want is not shell=True, but a separate function that > follows the system policy for translating a command name into a > path-to-binary. According to the docs, subprocess.Popen sh

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

Paul Moore wrote: Huh? CreateProcess uses PATH: Hmm, in that case Microsoft's documentation is lying, or subprocess is doing something itself before passing the command name to CreateProcess. Anyway, looks like there's no problem. -- Greg ___ Python

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

Nick Coghlan wrote: I'm OK with a target scope declaration construct having lexical-scope-dependent behaviour - exactly what "nonlocal NAME" will do depends on both the nature of the current scope, Yes, but my point is that having an explicit "parentlocal" scope declaration doesn't help to make

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

Ivan Pozdeev via Python-Dev wrote: This isn't as messy as you make it sound if you remember that the outermost iterable is evaluated only once at the start and all the others -- each iteration. Anyone using comprehensions has to know this fact. That fact alone doesn't imply anthing about the

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

Tim Peters wrote: If the parent has a matching parentlocal declaration for the same name then the original really refers to the grandparent - and so on. Ah, I missed that part, sorry -- I withdraw that particular objecttion. Still, this seems like a major addition (seeing as it comes with a n

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

Ivan Pozdeev via Python-Dev wrote: for me, the primary use case for an assignment expression is to be able to "catch" a value into a variable in places where I can't put an assignment statement in, like the infamous `if re.match() is not None'. This seems to be one of only about two uses for

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

Baptiste Carvello wrote: x=0; [x:=x+i for i in range(5)] what would be a non-cryptic alternative to the above example? Personally I wouldn't insist on trying to do it with a comprehension at all, but if forced to come up with a readable syntax for that, it would probably be something like

Re: [Python-Dev] Help preventing SIGPIPE/SIG_DFL anti-pattern.

Alfred Perlstein wrote: I am asking if there's a way we can discourage the use of "signal(SIGPIPE, SIG_DFL)" unless the user really understands what they are doing. Maybe there's some way that SIGPIPEs on stdout could be handled differently by default, so that they exit silently instead of pro

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

Nick Coghlan wrote: That's a performance argument, not a readability one (as if you don't care about performance, you can just repeat the subexpression). Repeated subexpressions can be a readability issue too, since you have to examine them to notice they are actually the same. They also provid

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

Terry Reedy wrote: If we had followed the math precedent, instead of language>, we would have set builders, list builders, dict builders, and generator builders. I was intending to suggest something like that back when comprehensions were first being discussed, but people raced ahead and adopte

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

Steven D'Aprano wrote: - list builder syntax is syntax which returns a list; - dict builder syntax is syntax which returns a dict; - set builder syntax is syntax which returns a set; - generator builder syntax is syntax which returns a generator. You only get a list/dict/set from the first t

Re: [Python-Dev] PEP 484

Shawn Chen wrote: The PEP 484 is proposing a type hint which can annotate the type of each parameters. How ever code written in this format can not be run for python3.5 and below. You're a bit late. Parameter annotations have been a part of the language since at least 3.1. PEP 484 just codifie

Re: [Python-Dev] Symmetric vs asymmetric symbols (was PEP 572: Do we really need a ":" in ":="?)

Ivan Pozdeev via Python-Dev wrote: (while "<>" reads "less or greater" which is mathematically not equivalent to that: not everything has a defined ordering relation. I think this is a silly argument against "<>". If we're going to try to assign meaning to individual characters in an operator,

Re: [Python-Dev] Call for prudence about PEP-572

Eric V. Smith wrote: there is at least one place where the grammar does forbid you from doing something that would otherwise make be allowable: decorators. And that was a controversial issue at the time. I don't remember there being much of an objective argument for the restriction -- it was m

Re: [Python-Dev] Let's change to C API!

Neil Schemenauer wrote: Perhaps a "argument clinic on steroids" would be the proper approach. So, extensions would mostly be written in C. However, we would have a pre-processor that does some "magic" to make using the Python API cleaner. You seem to have started on the train of thought that

Re: [Python-Dev] Change in Python 3's "round" behavior

j...@math.brown.edu wrote: I understand from https://github.com/cosmologicon/pywat/pull/40#discussion_r219962259 that "to always round up... can theoretically skew the data" *Very* theoretically. If the number is even a whisker bigger than 2.5 it's going to get rounded up regardless: >>> round

Re: [Python-Dev] Change in Python 3's "round" behavior

I don't really get the statistical argument. If you're doing something like calculating an average and care about accuracy, why are you rounding the values before averaging? Why not average first and then round the result if you need to? -- Greg ___ Py

Re: [Python-Dev] Change in Python 3's "round" behavior

Alex Walters wrote: Other use case is finance, where you can end up with interest calculations that are fractional of the base unit of currency. US$2.345 is impossible to represent in real currency, so it has to be rounded. This brings us back to my original point about floating point accuracy

Re: [Python-Dev] Change in Python 3's "round" behavior

Steven D'Aprano wrote: (It's also called Dutch Rounding.) Oh, so *that's* why Python does it! Fair enough. :-) Similarly for differences. If you perform many subtractions (let's say you are paying off a loan, and calculating interest, then rounding to the nearest cent) you have to care about

Re: [Python-Dev] Change in Python 3's "round" behavior

Chris Angelico wrote: ]That means that any representable number actually has to indicate a range of values centered on that value. That's not always true -- it depends on the source of the information. For example, a reading of 5 seconds on a clock with 1 second resolution actually represents a

Re: [Python-Dev] "Deprecation" of os.system in favor of subprocess?

My take on this is that os.system() is there because it's part of the C stdlib, and Python generally aims to provide wrappers for all of the C stdlib facilities. It's not Python's place to start making value judgements about which things are worthy of being wrapped and which aren't. -- Greg

Re: [Python-Dev] short-circuiting runtime errors/exceptions in python debugger.

When I have a bug that only happens after hours of run time, I try to find a much shorter test case that reproduces it. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://m

Re: [Python-Dev] Signalling NANs

Steven D'Aprano wrote: The Debian box uses an ARM processor, so there's that difference too. FWIW, I tried this on MacOSX 10.6 with an Intel Xeon and it also seems to suppress sNaNs. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://

Re: [Python-Dev] Need discussion for a PR about memory and objects

Nick Coghlan wrote: - the object identity is like the registration number or license plate (unique within the particular system of registering vehicles, but not unique across systems, and may sometimes be transferred to a new vehicle after the old one is destroyed) - the object type is like the m

Re: [Python-Dev] Need discussion for a PR about memory and objects

Chris Angelico wrote: Licence plate numbers do get reused. And they can change, e.g. if you get a personalised plate. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

Chris Angelico wrote: I would be strongly in favour of ctypes gaining a "get address of object" function, which happens (in current CPythons) to return the same value as id() does, but is specifically tied to ctypes. Isn't this what the ctypes.py_object type is for? Also, any code that does an

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

MRAB wrote: If I want to cache some objects, I put them in a dict, using the id as the key. If I wanted to locate an object in a cache and didn't have id(), I'd have to do a linear search for it. That sounds dangerous. An id() is only valid as long as the object it came from still exists, afte

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

Tim Peters wrote: The dict itself keeps the objects alive. Yes, but the idea of a cache is that you're free to flush things out of it to make room for something else without breaking anything. It sounds like MRAB is using ids as weak references, without the assurance actual weak references gi

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

Steven D'Aprano wrote: The sample code I've been shown is this: pointer_to_obj = id(obj) from_deref = ctypes.cast(pointer_to_obj, ctypes.py_object).value from_deref is obj # True There's no need to use id() or casting to create a ctypes.py_object instance, you can just call it:

Re: [Python-Dev] Add more SyntaxWarnings?

Stefan Behnel wrote: So … are you suggesting to use the webbrowser module inside of the REPL to look up the exception message of the previously printed stack trace in stack overflow when a user types "why()"? "Python is searching for an answer to your question..." -- Greg _

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

Jeroen Demeyer wrote: Let me just say that the code for METH_FASTCALL function/method calls is optimized for a stack layout: a piece of the stack is used directly for calling METH_FASTCALL functions We might be able to get some ideas for dealing with this kind of thing from register-window arc

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

Joe Jevnik via Python-Dev wrote: If Python switched to a global stack and global registers we may be able to eliminate a lot of instructions that just shuffle data from the caller's stack to the callee's stack. That would make implementing generators more complicated. -- Greg __

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

Victor Stinner wrote: LOAD_CONST_REG R0, 2 (const#2) LOAD_GLOBAL_REG R1, 'range' (name#0) CALL_FUNCTION_REG4, R1, R1, R0, 'n' Out of curiosity, why is the function being passed twice here? -- Greg ___ Python-Dev mailing list Python-Dev

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

Victor Stinner wrote: Using a different register may require an explicit "CLEAR_REG R1" (decref the reference to the builtin range function) which is less efficient. Maybe the source operand fields of the bytecodes could have a flag indicating whether to clear the register after use. -- Greg _

Re: [Python-Dev] Compact ordered set

Antoine Pitrou wrote: On a more abstract level, set and dict are both content-addressed collections parametered on hash and equality functions. Indeed. It's been said that a set is like "half a dict", and this is why sets were implemented using dicts in the old days. It's kind of an obvious th

Re: [Python-Dev] configparser: should optionxform be idempotent?

Inada Naoki wrote: a) Document "optionxform must be idempotent". b) Ensure all APIs calls optionxform exactly once, and document >[that it must be idempotent in certain special situations]. I think the question that needs to be asked is whether optionxform is meant to be a canonicalisi

Re: [Python-Dev] configparser: should optionxform be idempotent?

Paul Moore wrote: There's a subtle difference in the mathematical and computing meanings [of idempotent] (around functions > with side-effects, which aren't a thing in maths) Not really an issue here, since optionxform shouldn't be having side effects if it's sane. In any case, the word is eas

Re: [Python-Dev] Remove tempfile.mktemp()

Antoine Pitrou wrote: Does it always work? According to the docs, """Whether the name can be used to open the file a second time, while the named temporary file is still open, varies across platforms So use NamedTemporaryFile(delete = False) and close it before passing it to the other program.

Re: [Python-Dev] Remove tempfile.mktemp()

Antoine Pitrou wrote: On Wed, 20 Mar 2019 11:25:53 +1300 Greg Ewing wrote: So use NamedTemporaryFile(delete = False) and close it before passing it to the other program. How is it more secure than using mktemp()? It's not, but it solves the problem someone suggested of another progra

[Python-Dev] Replacement for array.array('u')?

A poster on comp.lang.python is asking about array.array('u'). He wants an efficient mutable collection of unicode characters that can be initialised from a string. According to the docs, the 'u' code is deprecated and will be removed in 4.0, but no alternative is suggested. Why is this being de

Re: [Python-Dev] Deprecating "instance method" class

Christian Heimes wrote: I couldn't find any current code that uses PyInstanceMethod_New. Let's deprecate the feature and schedule it for removal in 3.10. If it's designed for use by things outside of CPython, how can you be sure nothing is using it? -- Greg

Re: [Python-Dev] checking "errno" for math operaton is safe to determine the error status?

Xin, Peixing wrote: On certain platform, expm1() is implemented as exp() minus 1. To calculate expm1(-1420.0), that will call exp(-1420.0) then substract 1. You know, exp(-1420.0) will underflow to zero and errno is set to ERANGE. As a consequence the errno keeps set there when expm1() returns th

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

Victor Stinner wrote: Python is used on devices with low memory (ex: 256 MiB for the whole system). Allowing developers to use a debug build on such devices seem to be a legit rationale for such change. Rather than removing features altogether, maybe the debug build could be split into a number

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

Victor Stinner wrote: I'm not sure of what you means by "objects placed at static memory": the double linked list of all Python objects is created at runtime. _ob_next and _ob_prev are initialized statically to NULL. The trick of allocating extra memory in front of the object would be harder to

Re: [Python-Dev] PEP 594: update 1

Steve Dower wrote: We need to make it more clear somehow that Python uses series.major.minor.micro versioning, not SemVer. We could also do with deciding what the "series" part is really supposed to be for. At the moment it seems to be "we change it when the major number gets up to 9, or we fee

Re: [Python-Dev] [SPAM?] Re: PEP 558: Defined semantics for locals()

Chris Angelico wrote: Except that it does. After calling locals() a second time, the result of the *first* call will be updated to reflect changes. Yeow. That's *really* unintuitive. There had better be an extremely good reason for this behaviour. -- Greg __

Re: [Python-Dev] [SPAM?] Re: PEP 558: Defined semantics for locals()

Terry Reedy wrote: I believe that the situation is or can be thought of as this: there is exactly 1 function locals dict. Initially, it is empty and inaccessible (unusable) from code. Each locals() call updates the dict to a current snapshot and returns it. Yes, I understand *what's* happen

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Nathaniel Smith wrote: - [proxy]: Simply return the .f_locals object, so in all contexts locals() returns a live mutable view of the actual environment: def locals(): return get_caller_frame().f_locals Not sure I quite follow this -- as far as I can see, f_locals currently has the sam

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Nick Coghlan wrote: Having a single locals() call de-optimize an entire function would be far from ideal. I don't see what would be so bad about that. The vast majority of functions have no need for locals(). -- Greg ___ Python-Dev mailing list Pytho

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Nick Coghlan wrote: If there was a compelling use case for letting "a = 1; exec(src); print(a)" print something other than "1" at function scope, then I'd be more amenable to the idea of the associated compatibility break and potential performance regression in other implementations. However, th

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Nick Coghlan wrote: So for me, getting rid of write backs via exec and "import *" was a matter of "Yay, we finally closed those unfortunate loopholes" rather than being any kind of regrettable necessity. If that were the reasoning, the principled thing to do would be to raise an exception if an

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

Armin Rigo wrote: You have the occasional big function that benefits a lot from being JIT-compiled but which contains ``.format(**locals())``. There should be a lot less need for that now that we have f-strings. -- Greg ___ Python-Dev mailing list Py

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

Gregory P. Smith wrote: But a /separate/ issue is that we /should not try/ to cater to people who cannot use a modern up to date self updating trustworthy web browser. If developers really want people to keep their systems secure, they need to provide updates that *only* fix security issues, an

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

Steven D'Aprano wrote: Currently that assertion fails. Should it? Putting aside the convenience of "do nothing, just inherit the object.__eq__ behaviour" do you think that the current behaviour is *correct*? What I'm getting from this thread is that there are a variety of possible behaviours f

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

David Mertz wrote: This feels similar to NumPy arrays, that also will not compare for equality in bare form. Not quite the same -- comparing numpy arrays doesn't raise an exception, it returns an array of booleans. What raises an exception is trying to use the resulting array in a boolean conte

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

Kyle Stanley wrote: Serhiy Storchaka wrote: Actually, the == operator cannot return NotImplemented. What is the reason for this limitation It's not a limitation, it's a consequence of the way the operator machinery works. NotImplemented is used by operator methods to signal to the interpre

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

David Mertz wrote: We COULD do that with `d1.values() == d2.values()` in principle. This "DictValuesComparison" object could have methods like `.equal_as_set()` and `.equal_as_list()`. However, that's a lot of machinery for very little gain. Particularly as there are already perfectly go

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

Random832 wrote: implement the entire intuitive "contains the same amount of each value" algorithm [more or less Counter(obj1) == Counter(obj2)], But then we'd be guessing that this particular interpretation of "dict values equality", out of several plausible ones, is the one the programmer int

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

Steven D'Aprano wrote: Equality tests really ought not to fail. If they do fail, it should be considered a bug in the __eq__ method, not an intentional result. > To allow == tests to fail is just a way of sneaking in a three-value > logic into the language, only using an extremely inconvenient

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

Steven D'Aprano wrote: But the basic semantics hasn't really changed: two (multi)sets of values are equal if they have the same individual values, regardless of order. Why regardless of order? Dicts have an ordering nowadays. Why shouldn't that ordering be reflected in the algorithm for compar

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

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-correct them... -- Greg

[Python-Dev] Re: Changing Python's string search algorithms

On 17/10/20 3:26 pm, Tim Peters wrote: Tal Einat posted earlier that he was keen to try to work up a clear explanation, and I look forward to that. All the expositions I've found of this algorithm so far are hard to approach. Maybe Mathologer or 3blue1brown could be persuaded to help? They seem

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

On 20/10/20 4:52 am, Gregory P. Smith wrote: Those of us with a traditional posix filesystem background may raise eyeballs at this duplication, seeing a directory as a place that merely maps names to inodes This is probably a holdover from MS-DOS, where there was no separate inode-like structu

[Python-Dev] Re: Speeding up CPython

A concern I have about this is what effect it will have on the complexity of CPython's implementation. CPython is currently very simple and straightforward. Some parts are not quite as simple as they used to be, but on the whole it's fairly easy to understand, and I consider this to be one of its

[Python-Dev] Re: fail keyword like there is pass keyword

On 24/10/20 7:52 am, Umair Ashraf wrote: class MyTest(unittest.TestCase):    def test_this_and_that(self):       """       Given inputs       When action is done       Then it should pass       """       fail def fail(): raise Exception("It didn't work!") Not every one-line function

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

On 27/10/20 8:24 am, Victor Stinner wrote: I would rather want to kill the whole concept of "access" time in operating systems (or just configure the OS to not update it anymore). I guess that it's really hard to make it efficient and accurate at the same time... Also it's kind of weird that ju

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

On 31/10/20 7:22 am, Mark Shannon wrote: On 30/10/2020 4:09 pm, Brandt Bucher wrote: Anyone who reduces pattern matching to "a fancy switch statement" probably isn't the right person to be discussing its semantics and usefulness with. Pattern matching is a fancy switch statement, if you defin

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 3/11/20 11:01 am, Ethan Furman wrote: I believe supporting     case x, x   # look ma!  no guard! is a possible future enhancement. In which case there will be a need for *some* kind of true "don't care" placeholder. If it's not "_" then it will have to be something else like "?". And we

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 4/11/20 4:36 am, Paul Svensson wrote: On Tue, 3 Nov 2020, Greg Ewing wrote: once people start using "_" as a wildcard in patterns, it will be too late to go back. But will it, really ? It seems to me, that if we leave the "_" magic out, and leave "case x, x"

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 6/11/20 4:54 am, Steven D'Aprano wrote: On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote: If "_" is a non-binding wildcard, linters will have to allow "case _, _" otherwise it might as well not be there. And then if it is later changed to be binding, Why

[Python-Dev] Re: My thoughts on Pattern Matching.

On 7/11/20 4:03 am, Thomas Wouters wrote: It's also why I'm not in favour of PEP 642 and other proposals for solving some of the problems in the Structural Pattern Matching proposal (sigils, etc): it widens the gap instead of closing it. Does that mean you're against *any* proposal that invol

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 13/11/20 8:21 am, Paul Sokolovsky wrote: The current stage is to accept the fact that "mark capturing terms" is *very viable* alternative to "mark terms to use as values" ... But people behind PEPs keep ignoring that choice - silently, or with minimal consideration/commentary. Their stated j

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 13/11/20 9:19 am, MRAB wrote: I'd still want to list "as" as another possibility, the advantage being that it's already used for binding elsewhere. Only where it makes English grammatical sense, though, which it doesn't unless there's something on both sides. -- Greg ___

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 14/11/20 7:45 am, Brandt Bucher wrote: with (using your own syntactic flavor): ``` case >first, *>middle, >last: rebuilt = first, *middle, last case {"key": >value, **>rest}: rebuilt = {"key": value, **rest} case Point(x=>a, y=>b): rebuilt = Point(x=a, y=b) I think this is a c

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 14/11/20 9:33 am, Jim J. Jewett wrote: I *hope* this was a typo! If case Point(x=a, y=b): assigns to a and b (instead of x and y, as in a normal call), then that is ... going to be very easy for me to forget, and to miss even when I'm aware of it. I don't think it is a typo, unfortu

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

On 15/11/20 10:48 pm, Paul Sokolovsky wrote: > [from PEP 635] Pattern matching is complimentary to the object-oriented paradigm. BTW, there seems to be a typo here -- I think it's meant to be "complementary". please explain why you chose to proceed anyway (and apply workarounds), instead of f

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

On 18/11/20 4:36 pm, Larry Hastings wrote: But, the thinking went, you'd never want to examine the last value from a list generator, so it was more convenient if it behaved as if it had its own scope. List comprehensions used to leak, but apparently that was considered surprising by enough

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 18/11/20 5:29 pm, Stephen J. Turnbull wrote: Glenn Linderman writes: > Mathematics never came up with separate symbols for equality and > assignment. Mathematics doesn't need them, until we come to an age where we do mathematics on algorithms. Even then, when mathematicians describe al

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

On 22/11/20 6:47 am, David Mertz wrote: I'm convinced by Guido, Brandt, and others that the binding  use will be far more common, so adding extra characters for the 90% case does not feel desirable Minimising the number of characters is not the only consideration. Readability counts too, and I

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

On 22/11/20 1:07 pm, Henk-Jaap Wagenaar wrote: On Sat, 21 Nov 2020 at 19:58, Glenn Linderman > wrote: Don't () already indicate an expression to be evaluated? Does it? [(a, b)] = [(0, 1)] Presumably a comma would be needed to match a 1-tuple. case (x):

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

On 23/11/20 7:49 am, Daniel Moisset wrote: Look at the following (non-pattern-matching) snippet: event = datetime.date(x, month=y, day=z) The only names that are treated as lvalues there are to the left of an '='. The rules are a lot simpler. One of the Zen lines says "If it's hard to exp

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On 24/11/20 9:31 am, Brian Coleman wrote: In my opinion, the object oriented solution to this problem is to use the visitor pattern. Which is a good thing only if you believe that OO solutions are always better than non-OO ones. IMO, the visitor pattern is a workaround for when your language

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On 24/11/20 9:44 am, David Mertz wrote: m = Matcher(arbitrary_expression) if m.case("StringNode(s)"):     process_string(m.val) elif m.case("[a, 5, 6, b]"):     process_two_free_vars(*m.values) elif m.case("PairNone(a, b)"):     a, b = m.values     process_pair(a, b) elif m.case("DictNode"):

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