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

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

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

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

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]

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

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?

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

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

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

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

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

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: 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)

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)

Steven D'Aprano wrote: The *very first* motivating example for this proposal came from a comprehension. I think it is both unfortunate and inevitable that the discussion bogged down in comprehension-hell. I think the unfortunateness started when we crossed over from talking about binding a te

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

Nick Coghlan wrote: actually made those semantics available as an explicit "parentlocal NAME" declaration ...: def _list_comp(_outermost_iter): parentlocal item _result = [] for x in _outermost_iter: item = x _result.append(x) return _r

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

Ivan Pozdeev via Python-Dev wrote: Using this assigned result elsewhere in the same expression (akin to regex backreferences) is not a part of the basic idea actually. If that's true, then the proposal has mutated into something that has *no* overlap whatsoever with the use case that started th

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

Steven D'Aprano wrote: ":=" is the second most common syntax used for assignment in common programming languages, Yes, but it represents an *ordinary* assigment in those languages. The special way that's being proposed to use it in Python is not obvious. -- Greg __

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

Chris Angelico wrote: The wheel turns round and round, and the same spokes come up. A discussion long past, and a discussion yet to come. There are no beginnings or endings in the Wheel of Python... -- Greg ___ Python-Dev mailing list Python-Dev@py

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

Terry Reedy wrote: How loop variables might be isolated without a nested scope: After a comprehension is parsed, so that names become strings, rename the loop variables to something otherwise illegal. This doesn't change the situation conceptually, though, since the question arises of why not

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

Ivan Pozdeev via Python-Dev wrote: "as" was suggested even before is became a keyword in `with'. ( if (re.match(regex,line) as m) is not None: ) That's not equivalent where/given, though, since it still has the asymmetry problem. -- Greg ___ Python-

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

Steven D'Aprano wrote: You seem to be talking about an implementation which could change in the future. I'm talking semantics of the proposed language feature. The way I see it, it's not about implementation details, it's about having a mental model that's easy to reason about. "Comprehensions

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

Guido van Rossum wrote: Greg seem to be +0 or better for (a) Actually, I'm closer to -1 on (a) as well. I don't like := as a way of getting assignment in an expression. The only thing I would give a non-negative rating is some form of "where" or "given". Brief summary of reasons for disliking

Re: [Python-Dev] PySequence_Check but no __len__

Ivan Pozdeev via Python-Dev wrote: the documentation seems to use "sequence" in the sense "finite iterable". Functions that need to know the length of input in advance seem to be the minority. The official classifications we have are: Sequence: __iter__, __getitem__, __len__ Iterable: __iter

Re: [Python-Dev] PySequence_Check but no __len__

Terry Reedy wrote: I am surprised that a C-API function calls something a 'sequence' without it having __len__. It's a bit strange that PySequence_Check exists at all. The principle of duck typing would suggest that one should be checking for the specific methods one needs. I suspect it's a ho

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

Nick Coghlan wrote: x:= f():" implies "x" is already defined as a target somewhere else in the current scope, while "if x := f() given x:" potentially introduces "x" as a new local target N. this is just taking a bad idea and making it worse, IMO. I'm -1 on any contortions designed to

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

Skip Montanaro wrote: Yes, you'll have to pass in locals to exec. Exec changed between python 2 and 3. It used to be treated specially by the compiler so that it could see and modify the locals where it was used. But now it's just an ordinary function, so you can't expect it to magically know a

Re: [Python-Dev] Why aren't escape sequences in literal strings handled by the tokenizer?

Eric V. Smith wrote: I assume the intent is to not throw away any information in the lexer, and give the parser full access to the original string. But that's just a guess. More likely it's because the lexer is fairly dumb and can basically just recognise regular expressions. -- Greg

Re: [Python-Dev] Hashes in Python3.5 for tuples and frozensets

Anthony Flury via Python-Dev wrote: //I did suggest strongly to the original questioner that relying on the same hash value across different platforms wasn't a clever solution Even without randomisation, I wouldn't rely on hash values staying the same between different Python versions. Storing

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

Serhiy Storchaka wrote: Like tab-delimited tables. No, the obvious way to do tables is to allow HTML-marked-up source code. There would be other benefits to that as well. For example we could decree that all keywords must be formatted in bold, and then there would be no trouble adding new keyw

Re: [Python-Dev] Drop/deprecate Tkinter?

Guido van Rossum wrote: So what do *you* think. Do you agree with the OP that Tkinter (and hence IDLE) should be scrapped? I don't have an opinion on that, but the issue of whether tkinter should be in the stdlib has been debated at least once before, and I took the OP as saying "maybe we shoul

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

Steven D'Aprano wrote: "Not sure"? Given that you listed seven ways, how much more evidence do you need to conclude that it is simply wrong to say that Python has a single way to assign a value to a name? Yes, but six of those are very specialised, and there's rarely any doubt about when it's

Re: [Python-Dev] PEP 572 contradicts PEP 3099

Nick Coghlan wrote: On 29 April 2018 at 12:52, Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote: Alex Walters wrote: PEP 3099 is the big list of things that will not happen in Python 3. "There will be no alternative binding operators such as :=.&qu

Re: [Python-Dev] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

Jeff Allen wrote: I speculate this all goes back to some pre-iteration version of FORmula TRANslation, where to its inventors '=' was definition and these really were "statements" in the normal sense of stating a truth. Yeah, also the earliest FORTRAN didn't even *have* comparison operators. A

Re: [Python-Dev] PEP 572 contradicts PEP 3099

Alex Walters wrote: PEP 3099 is the big list of things that will not happen in Python 3. "There will be no alternative binding operators such as :=." The thread referenced by that is taling about a different issue, i.e. using a different symbol to rebind names in an outer scope. -- Greg _

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

Victor Stinner wrote: In my opinion, the largest failure of Python 3 is that we failed to provide a smooth and *slow* transition from Python 2 and Python 3. Although for some things, such as handling of non-ascii text, it's hard to see how a smooth transition *could* have been achieved. Is it a

Re: [Python-Dev] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

Eric Snow wrote: Unless I've missed something, there's no prohibition against deprecating things (and then later removing them) or other breaks in backward compatibility. I suppose that's true, but even so, changing "=" is going to feel like a really big change in the style of the language, big

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

Fatty Morgan wrote: Distinguishing in a rather unobtrusive way (no 'var' or 'let') the initialization of a previously unbound variable 'name := expr' and the re-assignment of a previously bound variable 'name = expr' That would be a massively confusing change. It's a fine idea for a new languag

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

Mike Miller wrote: - How are other modern languages solving this issue? In all the languages I can think of that allow assignments in expressions, there is only one assignment operator -- a stand alone assignment is just a bare assignment expression. But those languages were all designed t

Re: [Python-Dev] PEP 572: Why not := as standard assignment operator?

Chris Angelico wrote: No. Any expression may be used as a statement, so this isn't "outside an expression". It could be detected as a special case and rejected some time later in the compilation process. The question is whether it's worth making the rules more complicated just to forbid somethi

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

Antoine Pitrou wrote: Depends if you mean a graph between names or values? > If between names, you can even have cycles AFAICT: ((a: = a + b), (b: = a)) I was thinking more of the dataflow graph. That's not a cycle between *values*, since the new values being bound are calculated from the

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

Antoine Pitrou wrote: Well, how do languages where assignment is an expression returning the assigned value make their REPLs work? I'm sure they don't inflict that on their users, so it's certainly a solvable problem. I can't think of any such language that has a REPL offhand, but here's a pos

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

Tim Peters wrote: To my eyes, this is genuinely harder to follow, despite its relative brevity: while total != (total := total + term): Not surprising, since there are at least two deeper levels of subtlety at play: 1. total isn't just naming a subexpression, it's being rebound to som

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

Tim Peters wrote: As a statement in a program (as opposed to typed at a shell), "a := 3" has the unnecessary (in that context) property of returning (and discarding 3), so it's better style to use "a = 3" in that context. That seems like a post-hoc justification. If := were the one and only ass

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

Łukasz Langa wrote: Ha, not in Python! Here we have *different syntax* for assignments in expressions. Well, you can also use it as a statement. But don't! This is what I least like about the proposal. We should be moving in the direction of removing warts, but here we would be *creating* one (

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

On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov wrote: my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) Obviously what we want here is a variant of the binding expression that also makes it a keyword argument: my_func(arg, buffer ::= [None]*get_size(), size = len(b

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

Łukasz Langa wrote: What was its own assignment before now is part of the logic test. This saves on vertical whitespace but makes parsing and understanding logic tests harder. Another way to say this is that expressions are no longer restricted to being trees, but can be general DAGs, which req

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

Nick Coghlan wrote: I'd be +0 on an "is=" spelling But "is=' looks like some kind of comparison operator. This seems even more conusing to me. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-

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

Stephen J. Turnbull wrote: Neologisms are usually written in the other order: "dead on arrival (DOA, for short)." ;-) Maybe we can make use of that? if (x - x_base) (diff) and gcd(diff, n) (g) > 1: That doesn't work, because the (...) look like function calls. But what if we used a differe

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

Chris Jerdonek wrote: if (diff := x - x_base) and (g := gcd(diff, n)) > 1: "if diff, which we let equal x - x_base, and g, which ..." or "if diff, which we set equal to x - x_base, and g, which " or "if diff, which we define to be x - x_base, and g, which " or "if diff, which we defin

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

Sven R. Kunze wrote: if (x - x_base) and gcd(x - x_base, n) > 1: return gcd(x - x_base, n) and have the interpreter handle the optimization, or apply an lru_cache? ;-) Problem is, there's no way to automatically tell whether the expressions involved have side effects that are being relied

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

Tim Peters wrote: if (diff := x - x_base) and (g := gcd(diff, n)) > 1: return g My problem with this is -- how do you read such code out loud? From my Pascal days I'm used to reading ":=" as "becomes". So this says: "If diff becomes x - base and g becomes gcd(diff, n) is greater t

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

MRAB wrote: Some languages use '=' for assignment, others for equality, but do you know of a language that uses ':=' for equality' or '==' for assignment? No, but the only sane reason to use "==" for equality testing seems to be if you're already using "=" for something else. So maybe we should

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

Paul Moore wrote: the next question will likely be "so why does = exist at all?" And if we decide to make ':=' the official assigment operator and deprectate '=', the next question will be "Why do we have '==' instead of '='?" -- Greg ___ Python-Dev

Re: [Python-Dev] Deprecating float.is_integer()

Tim Peters wrote: from trig functions doing argument reduction as if pi were represented with infinite precision, That sounds like an interesting trick! Can you provide pointers to any literature describing how it's done? Not doubting it's possible, just curious. -- Greg _

Re: [Python-Dev] Symmetry arguments for API expansion

Tim Peters wrote: An obvious way to extend it is for Fraction() to look for a special method too, say "_as_integer_ratio()". Why not __as_integer_ratio__? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/list

Re: [Python-Dev] Dataclasses, frozen and __post_init__

Chris Barker - NOAA Federal wrote: If I have this right, on the discussion about frozen and hash, a use case was brought up for taking a few steps to create an instance (and thus wanting it not frozen) and then wanting it hashable. Which pointed to the idea of a “ freeze this from now on” method

Re: [Python-Dev] Dataclasses, frozen and __post_init__

Steven D'Aprano wrote: So in principle, we could have a mutable class, and a immutable one, and when you flick the switch, the instance.__class__ changes from mutable to frozen. That seems unfriendly to subclasses as well. To extend a class you now need to subclass both the mutable and immutab

Re: [Python-Dev] Is 4.0 a major breaking changes release?

On Sat, Feb 3, 2018 at 10:46 PM, Ned Deily > wrote: I've seen comments about making somewhat major changes in 4.0 - now I'm concerned that I should pause my porting effort until that is released. Is python 4 going to be another python 3? Guido has repeated

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

Raymond Hettinger wrote: That list of features is mostly easy-to-use except for hash=None which has three possible values, only one of which is self-evident. Maybe the value of the hash option should be an enum with three explicitly-named values. Or maybe there could be a separate "unhashable

Re: [Python-Dev] PEP 567 v2

Guido van Rossum wrote: Well, it's not *immutable* (it shouldn't support hash()), but it doesn't follow the MutableMapping protocol -- it only follows the Mapping protocol. That's why I wrote "mapping" with a small "m". If there's a better term for "collection of associations between keys and

Re: [Python-Dev] PEP 567 v2

Guido van Rossum wrote: It was get_context() in an earlier version of PEP 567. We changed it to copy_context() believing that that would clarify that you get a clone that is unaffected by subsequent ContextVar.set() operations (which affect the *current* context rather than the copy you just go

Re: [Python-Dev] PEP 567 v2

Guido van Rossum wrote: contextvars.copy_context().run(func, ) If contexts are immutable, why is there something called copy_context? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubs

Re: [Python-Dev] PEP 567 v2

Guido van Rossum wrote: There needs to be some way to introspect a Context, for debugging. It could have a read-only introspection interface without having to be a full Mapping. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.

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

Victor Stinner wrote: Users don't use stdin and stdout as regular files, they are more used as pipes to pass data between programs with the Unix pipe in a shell like "producer | consumer". Sometimes stdout is redirected to a file, but I consider that it is expected to behave as a pipe and the reg

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

Victor Stinner wrote: Maybe the "UTF-8 Mode" should be renamed to "UTF-8 with surrogateescape, or backslashreplace for stderr, or surrogatepass for fsencode/fsencode on Windows, or strict for Strict UTF-8 Mode"... But the PEP title would be too long, no? :-) Relaxed UTF-8 Mode? UTF8-Yeah-I'm-F

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