Re: [Python-Dev] PEP 492 quibble and request

Guido van Rossum wrote: On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle > wrote: Does this mean that somehow "await x" guarantees that the coroutine will suspend at least once? No. First, it's possible for x to finish without yielding. But even if x yield

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

Paul Moore wrote: It would probably be helpful to have a concrete example of a basic event loop that did *nothing* but schedule tasks. No IO waiting or similar, just scheduling. Take a look at the example I developed when working on the yield-from pep: http://www.cosc.canterbury.ac.nz/greg.ewi

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

Paul Moore wrote: What about Greg Ewing's example? http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Examples/Scheduler/scheduler.txt That doesn't cover any of the higher level abstractions like tasks or futures (at least not by those names or with those interfaces). B

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

Guido van Rossum wrote: the bytecode generated for await treats coroutine objects special, just like the bytecode generated for yield-from treats generator objects special. The special behavior they have in common is the presence of send() and throw() methods, I don't think that's quit accura

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

Paul Moore wrote: I can't see how you can meaningfully talk about event loops in a Python context without having *some* term for "things you wait for". PEP 3152 was my attempt at showing how you could do that. -- Greg ___ Python-Dev mailing list Pyth

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

Terry Reedy wrote: What I do not understand is how io events become event loop Event instances. They don't become Events exactly, but you can register a callback to be called when a file becomes ready for reading or writing, see: http://effbot.org/pyfaq/can-i-have-tk-events-handled-while-wait

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: The PEP gives you a Task Local Storage, where Task is: 1. your single-threaded code 2. a generator 3. an async task If you correctly use context managers, PEP 550 works intuitively and similar to how one would think that threading.local() should work. My version works *m

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: def foo(): var = ContextVar() var.set(1) for _ in range(10**6): foo() If 'var' is strongly referenced, we would have a bunch of them. Erk. This is not how I envisaged context vars would be used. What I thought you would do is this: my_contex

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: I understand what Koos is talking about, but I really don't follow you. Using the "with-statements to be skipped" language is very confusing and doesn't help to understand you. If I understand correctly, instead of using a context manager, your fractions example could be

Re: [Python-Dev] PEP 550 v4

There is one thing I misunderstood. Since generators and coroutines are almost exactly the same underneath, I had thought that the automatic logical_context creation for generators was also going to apply to coroutines, but from reading the PEP again it seems that's not the case. Somehow I missed

Re: [Python-Dev] PEP 550 v4

There are a couple of things in the PEP I'm confused about: 1) Under "Generators" it says: once set in the generator, the context variable is guaranteed not to change between iterations; This suggests that you're not allowed to set() a given context variable more than once in a given gene

Re: [Python-Dev] PEP 550 v4

Elvis Pranskevichus wrote: By default, generators reference an empty LogicalContext object that is allocated once (like the None object). We can do that because LCs are immutable. Ah, I see. That wasn't clear from the implementation, where gen.__logical_context__ = contextvars.LogicalCon

Re: [Python-Dev] Memory bitmaps for the Python cyclic garbage collector

Tim Peters wrote: In that case, it's because Python _does_ mutate the objects' refcount members under the covers, and so the OS ends up making fresh copies of the memory anyway. Has anyone ever considered addressing that by moving the refcounts out of the objects and keeping them somewhere else

Re: [Python-Dev] \G (match last position) regex operator non-existant in python?

Guido van Rossum wrote: From this I understand that when using e.g. findall() it forces successive matches to be adjacent. Seems to me this would be better addressed using an option to findall() rather than being part of the regex. That would avoid the issue of where to keep the state. -- Greg

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

Guido van Rossum wrote: I did not assume totally opaque -- but code objects are not very introspection friendly (and they have no strong compatibility guarantees). If I understand the proposal correctly, there wouldn't be any point in trying to introspect the lambdas/thunks/whatever. They're on

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 8 November 2017 at 19:21, Antoine Pitrou wrote: The idea that __main__ scripts should get special treatment here is entirely gratuitous. When I'm writing an app in Python, very often my __main__ is just a stub that imports the actual functionality from another module to get the benefits of

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

Tres Seaver wrote: IIUC, that would be as expected: you would see the warnings when running your test suite exercising that imported code (which should run with all warnings enabled), but not when running the app. But then what benefit is there in turning on deprecation warnings automatically

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

Ethan Furman wrote: Contriwise, "annotation_strings" sounds like a different type of annotation -- they are now being stored as strings, instead of something else. How about "annotations_as_strings"? -- Greg ___ Python-Dev mailing list Python-Dev@py

[Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

Guido van Rossum wrote: The PEP answers that clearly (under Implementation): > If an annotation was already a string, this string is preserved > verbatim. This bothers me, because it means the transformation from what you write in the source and the object you get at run time is not reversib

Re: [Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

Guido van Rossum wrote: But Python's syntax changes in nearly every release. The changes are almost always additions, so there's no reason why the AST can't remain backwards compatible. the AST level ... elides many details (such as whitespace and parentheses). That's okay, because the AST

Re: [Python-Dev] module customization

Ethan Furman wrote: The second way is fairly similar, but instead of replacing the entire sys.modules entry, its class is updated to be the class just created -- something like sys.modules['mymod'].__class__ = MyNewClass . If the recent suggestion to replace the global namespace dict with the

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

Ivan Levkivskyi wrote: while `g = list((yield i) for i in range(3))` is defined as this code: def __gen(): for i in range(3): yield (yield i) g = list(__gen()) Since this is almost certainly not what was intended, I think that 'yield' inside a generator expression shoul

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

Paul Moore wrote: At the moment, I know I tend to treat Python semantics as I always did, but with an implicit proviso, "unless async is involved, when I can't assume any of my intuitions apply". That's *not* a good situation to be in. It's disappointing that PEP 3152 was rejected, because I th

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

Paul Moore wrote: 3. List comprehensions are the same as list(the equivalent generator expression). I don't think that's ever been quite true -- there have always been odd cases such as what happens if you raise StopIteration in list(generator_expression). To my mind, these equivalences have n

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

Ivan Levkivskyi wrote: The key idea is that neither comprehensions nor generator expressions should create a function scope surrounding the `expr` I don't see how you can avoid an implicit function scope in the case of a generator expression, though. And I can't see how to make yield in a gener

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

Ivan Levkivskyi wrote: "People sometimes want to refactor for-loops containing `yield` into a comprehension but that doesn't work (particularly because of the hidden function scope) - lets make it a SyntaxError" Personally I'd be fine with removing the implicit function scope from comprehensio

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

Ivan Levkivskyi wrote: On 23 November 2017 at 05:44, Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote: def g(): return ((yield i) for i in range(10)) I think this code should be just equivalent to this code def g(): temp = [(yield i) for i in

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

Ivan Levkivskyi wrote: "People sometimes want to refactor for-loops containing `yield` into a comprehension By the way, do we have any real-life examples of people wanting to do this? It might help us decide what the semantics should be. -- Greg ___

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

Paul Moore wrote: has anyone confirmed why a function scope was considered necessary at the time of the original implementation, but it's apparently not now? At the time I got the impression that nobody wanted to spend the time necessary to design and implement a subscope mechanism. What's chan

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

Serhiy Storchaka wrote: Ivan explained that this function should be rough equivalent to def f(): t = [(yield i) for i in range(3)] return (x for x in t) This seems useless to me. It turns a lazy iterator into an eager one, which is a gross violation of the author's intent in

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

Guido van Rossum wrote: The debugger does stop at each iteration. It does see a local named ".0" I suppose there currently is no way for the debugger to map the variable names to what they are named in the source, right? If the hidden local were named "a.0" where "a" is the original name, ma

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

Guido van Rossum wrote: the extra scope is now part of the language definition. It can't be removed as a "bug fix". Does anyone actually rely on the scope-ness of comprehensions in any way other than the fact that it prevents local variable leakage? If not, probably nobody would notice if it w

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

Nick Coghlan wrote: def example(): comp1 = yield from [(yield x) for x in ('1st', '2nd')] comp2 = yield from [(yield x) for x in ('3rd', '4th')] return comp1, comp2 If the implicit "yield from" idea seems too magical, then the other direction we could go is to make

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

Serhiy Storchaka wrote: Ivan explained that this function should be rough equivalent to def f(): t = [(yield i) for i in range(3)] return (x for x in t) This is a *rough* equivalent. There are differences in details. The details would seem to be overwhelmingly important, tho

Re: [Python-Dev] Second post: PEP 557, Data Classes

Nick Coghlan wrote: Perhaps the check could be: (type(lhs) == type(rhs) or fields(lhs) == fields(rhs)) and all (individual fields match) I think the types should *always* have to match, or at least one should be a subclass of the other. Consider: @dataclass class Point3d: x: float y

Re: [Python-Dev] Second post: PEP 557, Data Classes

Chris Angelico wrote: I'm not sure there's any distinction between a "point" and a "vector from the origin to a point". They transform differently. For example, translation affects a point, but makes no difference to a vector. There are two ways of dealing with that. One is to use vectors to r

Re: [Python-Dev] Using async/await in place of yield expression

Guido van Rossum wrote: The source for sleep() isn't very helpful -- e.g. @coroutine is mostly a backwards compatibility thing. So how are you supposed to write that *without* using @coroutine? -- Greg ___ Python-Dev mailing list Python-Dev@python.o

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

Eric Fahlgren wrote: ​I think you're missing something here, since it seems clear to me that indeed the arguments are evaluated prior to the function call.​ I think the OP may be confusing "evaluating the function" with "calling the function". If the function being called is determined by some

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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)

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)

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)

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)

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] PyObject_IsInstance is dangerous

Serhiy Storchaka wrote: PyObject_IsInstance is not safe when used to check if the object is an instance of specified builtin type. The __class__ attribute can be modified and PyObject_IsInstance() can return true if the object has not layout compatible with specified structure. Code that re

Re: [Python-Dev] PyObject_IsInstance is dangerous

Serhiy Storchaka wrote: May be modify PyObject_IsInstance so that it will never return true if layouts are not compatible? That wouldn't be a good idea, since PyObject_IsInstance is meant to reflect the behaviour of python's isinstance() function, which doesn't care about C layouts. -- Greg __

Re: [Python-Dev] Enable access to the AST for Python code

Guido van Rossum wrote: Hey Ben, this is probably a better topic for python-ideas. I'll warn you that a hurdle for ideas like this is that ideally you don't want to support this just for CPython. It's definitely cool though! This would effectively be a macro system. I thought your position on

Re: [Python-Dev] Enable access to the AST for Python code

Steve Dower wrote: It's only a macro system when you generate code in unexpected/unobvious places with it. This is more like inspect.getsource(), but going straight to the AST. Is it really that much different? The end result is the same -- the user writes something that looks like a Python ex

Re: [Python-Dev] Enable access to the AST for Python code

Ethan Furman wrote: I think the key difference is that the AST is not going to be converted to run different Python code under Python, but under some other language -- presumably to implement the semantics of the Python snippet. If the semantics were exactly the same as the Python snippet, the

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

Nick Coghlan wrote: We've long had a requirement that certain kinds of proposal come with at least nominal support commitments from the folks proposing them (e.g. adding modules to the standard library, supporting new platforms). Institutions with a clear financial interest in a particular probl

Re: [Python-Dev] Obtaining stack-frames from co-routine objects

Nick Coghlan wrote: I wonder if in 3.6 it might be possible to *add* some bookkeeping to "await" and "yield from" expressions that provides external visibility into the underlying iterable or coroutine that the generator-iterator or coroutine has delegated flow control to. In my original implem

Re: [Python-Dev] async __setitem__

Nick Coghlan wrote: What if we're assigning to multiple targets, do the run in parallel? How is tuple unpacking handled? How is augmented assignment handled? If we allow asynchronous assignment, do we allow asynchronous deletion as well? Yeah, we'd kind of be letting the camel's nose in here.

Re: [Python-Dev] Importance of "async" keyword

Sven R. Kunze wrote: # Call func syncronously, blocking until the calculation is done: x = func() # Call func asyncronously, without blocking: y = await func() Using the word "blocking" this way is potentially confusing. The calling task is *always* blocked until the operation completes. The

Re: [Python-Dev] Importance of "async" keyword

Sven R. Kunze wrote: I like the 'await' syntax to mark suspension points. But the 'async' coloring makes no sense to me. It is an implementation details of asyncio (IMHO). Functions containing an "await" are going to be coloured in any case -- that's unavoidable, given that await is built on t

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