Re: [Python-ideas] Fwd: Trigonometry in degrees

Stephan Houben wrote: Yes that is what my code does. It reduces degrees to [0,90]. Only for the special angles, though. Richard's point is that you need to do tha for *all* angles to avoid discontinuities with large angles. This is not how sine functions are calculated. They are calculated

Re: [Python-ideas] Give regex operations more sugar

Chris Angelico wrote: This would want to be semantically different from chained calls, in that a single replace([x,y,z], q) would avoid re-replacing; +1, this would be REALLY handy! It's easy to trip yourself up with chained replacements if you're not careful -- like I did once when escaping

Re: [Python-ideas] Give regex operations more sugar

Michel Desmoulin wrote: Also, we do have to saturate the str namespace with all the re functions. We could decide to go for `str.re.stuff`. However, note that this is not as simple as just adding a class attribute to str that references the re module, since presumably you want to be able to

Re: [Python-ideas] Operator for inserting an element into a list

Mikhail V wrote: L ^= item is L.append(item) or L += [item] Okay, that achieves an in-place append, but it's not exactly obvious to the unenlightened what it does, whereas append() is pretty self-explanatory. Also, using the slice version to do an insert L[i:i] ^= item is not as efficient

Re: [Python-ideas] Operator for inserting an element into a list

Mikhail V wrote: But if you say that special-casing of [i:j] here would be hard to implement, then maybe insert() idea should be dropped. Since I wrote that I realised that it's not true -- given an infix ^ operator like you propose, the in-place version of it would actually give the desired

Re: [Python-ideas] Give regex operations more sugar

Clint Hepner wrote: Strictly speaking, a regular expression is just a string that encodes of a (non)deterministic finite automata. More strictly speaking, regular expressions themselves are agnostic about determinism vs. non-determinism, since for any NFA you can always find an equivalent

Re: [Python-ideas] Operator for inserting an element into a list

Mikhail V wrote: L[0:0] = ["bb"] -> ["bb", "aa"] The trick is to put brackets around the element and so it works as insert(). Though additional brackets look really confusing for this purpose, so I don't feel like using this seriously. I don't think it's all that confusing. It looks

Re: [Python-ideas] Fwd: Trigonometry in degrees

Tim Peters wrote: 1. Python's float "%" is unsuitable for argument reduction; e.g., >>> -1e-14 % 360.0 360.0 `math.fmod` is suitable, because it's exact: >>> math.fmod(-1e-14, 360.0) -1e-14 So why doesn't float % use math.fmod? -- Greg ___

Re: [Python-ideas] Fwd: Trigonometry in degrees

Steven D'Aprano wrote: sin(3°) is: -1/2 (-1)^(29/60) ((-1)^(1/60) - 1) (1 + (-1)^(1/60)) This proposal was supposed to *simplify* the trig functions for non-mathematicians, not make them mind-bogglingly complicated. I don't think anyone is going to complain about sin(3°) not being exact,

Re: [Python-ideas] Fwd: Trigonometry in degrees

Michael Selik wrote: Whoops, it turns out Euler's formula does work! I expected imprecision, but at least one test matched. That might be because the implememtation of e ** x where x is complex is using Euler's formula... -- Greg ___ Python-ideas

Re: [Python-ideas] A "within" keyword

David Teresi wrote: One of the features I miss from languages such as C# is namespaces that work across files - it makes it a lot easier to organize code IMO. Maybe for the writer, but not for the reader. I like the fact that in Python I can usually tell which file a given class or function is

Re: [Python-ideas] Fwd: New suggested built in keyword: do

Jamie Willis wrote: What about just supporting filtering syntax at the top level? for x range(50) if x % 2: print(x) It would be more general and probably easier to support this: for x in range(50): if x % 2: print(x) i.e. just relax the requirement that a statement following on the same

Re: [Python-ideas] Trigonometry in degrees

Steven D'Aprano wrote: Even old-school scientific calcuators without the fancy CAS symbolic maths are capable of having cos(90) return zero in degree mode. FWIW, my Casio fx-100 (over 30 years old) produces exactly 1 for both sin(90°) and sin(pi/2) for its version of pi. -- Greg

Re: [Python-ideas] Trigonometry in degrees

Chris Angelico wrote: The math module would need a hyperbolic sine function which accepts an argument in; Except that the argument to hyperbolic trig functions is not an angle in any normal sense of the word, so expressing it in degrees makes little sense. (However I do like the idea of a

Re: [Python-ideas] Trigonometry in degrees

Stephen J. Turnbull wrote: Since Pi is irrational, Pi/4 is too, so it definitely cannot be represented. Making a correction to a number that "looks like" Pi/4 is against this philosophy. I'm not sure what all the fuss is about: >>> from math import pi, sin >>> sin(pi/2) 1.0 >>> sin(pi/2 + 2

Re: [Python-ideas] Trigonometry in degrees

Richard Damon wrote: First I feel the need to point out that radians are actually fairly fundamental in trigonometry, Even more so in calculus, since the derivative of sin(x) is cos(x) if and only if x is in radians. -- Greg ___ Python-ideas mailing

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

Eric Fahlgren wrote: I don't think it's possible to avoid instantiating the exception at the user level, what would sys.exc_info() do about it's second return value? The exception could be instantiated if and when sys.exc_info() gets called. -- Greg

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

Ethan Furman wrote: Why is this? Doesn't the exception have to be instantiated at some point, even if just to print to stderr? If it gets caught by an except clause without an else clause, in theory there's no need to instantiate it. However, Python doesn't currently seem to take advantage

Re: [Python-ideas] Add shutil.chown(..., recursive=False)

BTW, I wouldn't argue that Python shouldn't provide things that are only useful to root. While writing setuid utilities in Python is a bad idea for lots of reasons, I don't think there's anything wrong with becoming root by another means and then running a Python program that you know well enough

Re: [Python-ideas] Add shutil.chown(..., recursive=False)

Steven D'Aprano wrote: Look closely at my example: the file ownership recursively changed from steve.steve to steve.users. You're quite right. I hadn't realised that chown can be used to change the group as well as the user. It's permitted to change the group to one that the user is a member

Re: [Python-ideas] Add shutil.chown(..., recursive=False)

Steven D'Aprano wrote: But it doesn't matter: regular users can call chown -R: Only if you're not actually telling it to change anything. % ls -l foo.txt -rw-r--r-- 1 greg users 1 29 May 18:19 foo.txt % chown greg foo.txt % chown fred foo.txt chown: foo.txt: Operation not permitted So you

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

Michael Lohmann wrote: I just wanted to override the class-variable `magic_number` to give a reason why I don’t ever want to call Magic.__init__ in Foo. If you want, you can have this class instead: class Magic: > def __init__(self): raise RuntimeError("Do not initialize this

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

Michael Lohmann wrote: class Ethel(Aardvark, Clever): """Ethel is a very clever Aardvark""" def __init__(self): super().__init__(quantity="some spam", cleverness=1000)) >> if you want to instantiate an Aardvark directly there is NO WAY EVER that you could give him

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

Michael Lohmann wrote: class Magic: magic_number = 42 def __init__(self): A.magic_number = 0 # As soon as you look too deep into it all the Magic vanishes What is A here? Did you mean something else? -- Greg ___

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

Nick Coghlan wrote: Aye, while I still don't want comprehensions to implicitly create new locals in their parent scope, I've come around on the utility of letting inline assignment targets be implicitly nonlocal references to the nearest block scope. What if you're only intending to use it

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

Brendan Barnwell wrote: If I understand correctly, the essence of your argument seems to be that you want be able to write a class A, and you want to be able to use that class EITHER as the top of an inheritance chain (i.e., have it inherit directly from object) OR in the middle of an

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

Tim Peters wrote: x: 12 y: 13 == 13 [x y] == [x y] do [x y] == 13 How does scoping work? If you pass a block to a function which evaluates it, how are names in the block resolved? -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

Steven D'Aprano wrote: Yeah, to me it looks more like a prefix version of Forth than Lisp. Throf? -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct:

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

Paul Svensson wrote: I don't quite get what's so subtle about it, am I missing something? The "with" keyword calls "__enter__", and "as" gives it a name. Just like "-x + y" is different from "-(x + y)", I think the difference is that mentally one already tends to think of "with x as y"

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

Chris Angelico wrote: The 'as' syntax has been hammered out in great detail and is no longer recommended due to its negative interactions with existing constructs. Allowing it in arbitrary expressions has been ruled out on the grounds that the difference between "with x as y:" and "with (x as

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

Chris Angelico wrote: I'm not sure. How long will it take for people to agree on a meaning for "trillion"? About a trillion years, I estimate. :-) -- Greg ___ Python-ideas mailing list Python-ideas@python.org

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

Stefan Behnel wrote: So, does that mean we now need to hold our breath for 1.9 british trillion years or 1.9 american trillion years? Seeing as the time-to-red-giant is only about 5e9 years, I don't think it matters much either way. -- Greg ___

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

Steven D'Aprano wrote: It's Python 3.8, and I learn that in 4.0 "spam" is going to become a keyword. I simply take my code and change all the references spam to \spam, and I've future-proofed the code for 4.0 while still keeping compatibility with 3.8 and 3.9. Okay, maybe it helps a little

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

Ethan Furman wrote: How long before the earth stops rotating? Apparently about 1.9 trillion years. > When it does, will we be > tide-locked with the sun, or will an earth day become an earth year? Wikipedia says the main cause of the slowing is tidal effects from the moon, so probably it

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

Carl Smith wrote: > I wrote: The trouble with explicitly overriding keywords is that it still requires old code to be changed whenever a new keyword is added... > For the purpose of this discussion, let's say that if any code implicitly enables a new feature (by simply using it), all the

Re: [Python-ideas] String and bytes bitwise operations

Steven D'Aprano wrote: But XORing bytes seems perfectly reasonable. Bytes are numbers, even if we display them as ASCII characters. Yep. Implement it for bytes, then the user can decode/encode as appropriate for the application. -- Greg ___

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

Steven D'Aprano wrote: Let's say you're reading from a CSV file, creating an object from each row, and processing it: Okay, I can see it could be useful for situations like that. But this is still a completely different use case from the one that started this discussion, which was making it

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

Todd wrote: The overall issue is that python has no way of knowing if the keyword is being used for legitimate backwards-compatibility purposes or someone intentionally overrode after it was made a keyword because they somehow thought it was a good idea. That is why being explicit about

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

Ethan Furman wrote: Part of the point of the proposal is to be able to use existing keywords (at least, I thought it was). Mainly it's so that *new* keywords can be added to the language without breaking old code. Nobody is going to want to turn one of the currently existing keywords into a

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

Terry Reedy wrote: the first two 'and's in "a and b.and # and error" are tagged. To not tag the second would require full parsing, That particular case could be handled by just not colouring any word following a dot. Some other situations might result in false positives, but there are cases

Re: [Python-ideas] Inline assignments using "given" clauses

Steven D'Aprano wrote: To reiterate what Tim already pointed out, that original usecase required a way to feed values *into* the comprehension. https://mail.python.org/pipermail/python-ideas/2018-February/048971.html There's no need for dedicated syntax for that if we can just set an

Re: [Python-ideas] Inline assignments using "given" clauses

Tim Peters wrote: total = 0 progressive_sums = [total := total + value for value in data] I'm skeptical that it's a good idea to encourage this kind of thing in the first place. -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Inline assignments using "given" clauses

Can someone explain to me why it was considered a bad thing that for-clauses leaked names in comprehensions, but it will be a good thing for inline assignments to leak names from them? -- Greg ___ Python-ideas mailing list Python-ideas@python.org

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

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

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

Elias Tarhini wrote: The thought of writing "operator.not" is appealing, but being forced to use *that* (with *from operator import not* being non-allowable) may not be. Under the proposal I made in my last post, "from operator import not" would be fine -- you just wouldn't be able to use the

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

Guido van Rossum wrote: Of course this would still not help for names of functions that might be imported directly (do people write 'from numpy import where'?). Maybe things could be rigged so that if you use a reserved word as a name in an import statement, it's treated as a name everywhere

Re: [Python-ideas] Inline assignments using "given" clauses

Steven D'Aprano wrote: In my experience mathematicians put the given *before* the statement: Given a, b, c three sides of a triangle, then Area = sqrt(s*(s-a)*(s-b)*(s-c)) where s = (a + b + c)/2 is the semi-perimeter of the triangle. I agree, and "where" would be my first

Re: [Python-ideas] Inline assignments using "given" clauses

Kirill Balunov wrote: While for those who are familiar with Pascal, Icon and other languages that use this syntax, this - `:=` looks natural. As someone familiar with Pascal, I think the similarity to the Pascal assignment operator is actually an argument *against* it. Knowing what it means

Re: [Python-ideas] Inline assignments using "given" clauses

Gustavo Carneiro wrote: IMHO, all these toy examples don't translate well to the real world because they tend to use very short variable names while in real world [good written code] tends to select longer more descriptive variable names. I don't believe that's always true. It depends on the

Re: [Python-ideas] Inline assignments using "given" clauses

Guido van Rossum wrote: I'd need well-reasoned explanations My reasoning is essentially the same as what I've already said about "where". To summarise, "given" sounds like something an English-speaking mathematician would write, whereas ":=" doesn't even have an obvious pronunciation. Some

Re: [Python-ideas] Inline assignments using "given" clauses

+1 given, -1 := -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

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

Tim Peters wrote: Umm ... that's the opposite of what the Reference Manual says "lower":means: """ 6.16. Operator precedence The following table summarizes the operator precedence in Python, from lowest precedence (least binding) to highest precedence (most binding). """ Which is also in

Re: [Python-ideas] Inline assignments using "given" clauses

Tim Peters wrote: "async def", "async for", and "async with" statements were added _without_ making "async" a new reserved word. It may require pain in the parser, but it's often doable anyway. There would be less pain if the parser generator could deal with non-reserved keywords more

Re: [Python-ideas] Objectively Quantifying Readability

Tim Peters wrote: def objective_readability_score(text): "Return the readability of `text`, a float in 0.0 .. 1.0" return 2.0 * text.count(":=") / len(text) A useful-looking piece of code, but it could be more readable. It only gives itself a readability score of 0.0136986301369863.

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

Steven D'Aprano wrote: y = 1 def func(): x = 2 return x+y Here, there's a local environment as well as an implicit global one. Surely we don't want to call this a closure? Python probably isn't the best choice of language for the point you're making, because even top-level functions

Re: [Python-ideas] Objectively Quantifying Readability

Rhodri James wrote: I'd be interested to know if there is a readability difference between really_long_descriptive_identifier_name and ReallyLongDescriptiveIdentifierNames. As one data point on that, jerking my eyes quickly across that line I found it much easier to pick out the component

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

Steven D'Aprano wrote: So what was the closure? If the surrounding function was still running, there was no need to capture the running environment in a closure? You seem to be interpreting the word "closure" a bit differently from most people. It doesn't imply anything about whether a

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

Steven D'Aprano wrote: Pascal, for example, had lexical scoping back in the 1970s, but no closures. Well, it kind of had a limited form of closure. You could pass a procedure or function *in* to another procedure or function as a parameter, but there was no way to return one or pass it out in

Re: [Python-ideas] Sublocal scoping at its simplest

Chris Angelico wrote: 1) Bind the caught exception to a sublocal 'e' 2) Execute the suite, with the reference to 'e' seeing the sublocal 3) Set the sublocal e to None 4) Unbind the sublocal e At the unindent, the sublocal name will vanish, and the original 'e' will reappear. That's a

Re: [Python-ideas] Should __builtins__ have some kind of pass-through print function, for debugging?

Nathaniel Smith wrote: It looks like my client used "font-family: monospace", maybe yours only understands or something? Hmmm, looking at the message source, it does indeed specify monospace. It seems the version of Thunderbird I'm using does a spectacularly bad job of interpreting HTML.

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

Tim Peters wrote: (ABC had no lexical scoping either - nor, if I recall correctly, even textual nesting of its flavor of functions). If Python hadn't allowed textual nesting either, folks might have been content to leave it that way. But having textual nesting without lexical scoping was just

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

Tim Peters wrote: The points to using function-call-like syntax were already covered ("nothing syntactically new to learn there", The trouble is that one usually expects "nothing syntactically new" to imply "nothing semantically new" as well, which is very far from the case here. So I think

Re: [Python-ideas] Should __builtins__ have some kind of pass-through print function, for debugging?

Nathaniel Smith wrote: Traceback (most recent call last):   File "/tmp/blah.py", line 16, in     print(foo())           ^   File "/tmp/blah.py", line 6, in foo but he sent it in HTML using a proportional font, which spoils the effect! -- Greg

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

Tim Peters wrote: To the compiler, it's approximately nothing like "a function call". It's nothing like a function call to the user, either, except in the most superficial of ways. - The explicit parentheses make it impossible to misunderstand where the expression begins or ends. Except

Re: [Python-ideas] Allow multiple imports from a package while preserving its namespace

Nick Coghlan wrote: I find the imports at the top of the file to be a nice catalog of external dependencies. Not only is it useful for human readers, it's also useful for packaging tools such as py2exe that need to know which modules are being used. I experimented once with auto-importing in

Re: [Python-ideas] Allow multiple imports from a package while preserving its namespace

Serhiy Storchaka wrote: 27.04.18 02:12, Greg Ewing пише: import display, event, mixer in pygame I read this as import display, event, mixer in pygame pygame.display = display pygame.event = event pygame.mixer = mixer del display, event, mixer in pygame It's meant

Re: [Python-ideas] Allow multiple imports from a package while preserving its namespace

Chris Angelico wrote: +0 for an easier way to import multiple submodules at once. It's not something I've personally had a need for, but it's a sane and logical thing to do. Maybe: import display, event, mixer in pygame or in pygame import display, event, mixer -- Greg

Re: [Python-ideas] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

Tim Peters wrote: while we have N numbers, there are N+1 slice indices. So accumulate(xs) doesn't quite work. It needs to also have a 0 inserted as the first prefix sum (the empty prefix sum(xs[:0]). Which is exactly what a this_is_the_initial_value=0 argument would do for us. In this case,

Re: [Python-ideas] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

Peter O'Connor wrote: The behaviour where the first element of the return is the same as the first element of the input can be weird and confusing. E.g. compare: >> list(itertools.accumulate([2, 3, 4], lambda accum, val: accum-val)) [2, -1, -5] >> list(itertools.accumulate([2, 3, 4], lambda

Re: [Python-ideas] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

Raymond Hettinger wrote: I don't want to overstate the case, but I do think a function signature that offers a "first_value" option is an invitation to treat the first value as being distinct from the rest of the data stream. I conjecture that the initial value is *always* special, and the

Re: [Python-ideas] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

Raymond Hettinger wrote: For neither of those use case categories did I ever want an initial value and it would have been distracting to even had the option. For example, when doing a discounted cash flow analysis, I was taught to model the various flows as a single sequence of up and down

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

Kyle Lahnakoski wrote: Consider Serhiy Storchaka's elegant solution, which I reformatted for readability smooth_signal = [ average for average in [0] for x in signal for average in [(1-decay)*average + decay*x] ] "Elegant" isn't the word I would use, more like "clever". Rather

Re: [Python-ideas] Fixing class scope brainstorm

Guido van Rossum wrote: I do notice that we probably can't easily solve this using the existing closure machinery ("cells") because if we were to have cells in the class dict, it would confuse everything else that looks in the class namespace. Maybe it could be done with a new kind of cell

Re: [Python-ideas] Disallow importing the same module under multiple names

Chris Billington wrote: I wonder how mercurial gets around the fact that its own imports might be shadowed by whatever's in the current working directory. The cwd is only added to sys.path in the interactive interpreter, not when you run "python something.py". So it's not usually a problem

Re: [Python-ideas] New PEP proposal -- Pathlib Module Should Contain All File Operations

Jason Maldonis wrote: In python, `os` and `shutil` are currently the low-level modules, and it stands to reason that we might consider combining these somehow (although I'm assuming that there was a good reason not to in the first place The functions in os are thin wrappers around system

Re: [Python-ideas] Descouraging the implicit string concatenation

Carl Meyer wrote: With this rule the only missing-comma that can slip through is when you've forgotten _all_ the intervening commas in your sequence of strings. That's much less likely. Not so unlikely when the argument list is of length 2. -- Greg

Re: [Python-ideas] Descouraging the implicit string concatenation

Facundo Batista wrote: That we say "hey, this works but please don't use it, because it tends to a error prone way of writing some code, instead do this". The trouble is that there is nowhere near widespread agreement that it is error prone enough to be worth such a drastic measure as

Re: [Python-ideas] Descouraging the implicit string concatenation

Oleg Broytman wrote: The most painful was that the bug destroyed important information that was hard to fix later (enterprise code in production, the code is certificated and hard to replace). Seems to me there are a number of problems right there: * Important information that is not

Re: [Python-ideas] Descouraging the implicit string concatenation

Facundo Batista wrote: What was proposed and reject was the *removal* of the feature/syntax. I propose the discouragement of the idiom. Providing a linter option to catch it would be fine. Officially discouraging it would be going too far, I think. It's one thing to promote style guidelines

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

Robert Vanden Eynde wrote: The "make it a keyword in a context" might lead to things like "print(where where where = where)", not sure you'd want that :) What the heck, if it was good enough for PL/1... But that's just a choice of syntax, Choice of syntax is important, though. It's all

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

2018-03-03 8:40 GMT+01:00 Nick Coghlan : pairs = [(f(y), g(y)) for x in things with bind(h(x)) as y] I don't mucn like "with bind(h(x)) as y" because it's kind of like an abstraction inversion -- you're building something complicated on top of something complicated in

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

Robert Vanden Eynde wrote: But I think that the implementation of print(y with y = x + 1) would be more close to next(y for y in [ x+1 ]) WHy on earth should it be? Expanding that gives you a generator containing a loop that only executes once that is immediately run to yield exactly one

Re: [Python-ideas] Class autoload

Jamesie Pic wrote: obj = new yourmodule.YourClass() This would also eliminate the need to manage an import list at the beginning of a script in most case. I like the fact that I can usually tell what modules a module depends on by looking at the top for import statements. If people were

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

Nathan Goldbaum wrote: Where is also very common in numpy. So if someone did: from numpy import * data = where(condition) They might have issues Bummer, I didn't know numpy used it. That puts rather a big dampener on the idea of making it a keyword. :-( Remaining options include: * Make

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

Robert Vanden Eynde wrote: One could see : print(y with y = x+1) As a shortcut for : print(next(y for y in [ x+1 ])) Or more straightforwardly, print((lambda y: y)(x + 1)) This is how the semantics of let-type constructs is often defined in lambda-calculus-inspired languages such as

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

Nick Coghlan wrote: I don't think it should be possible to close over statement locals. Why not? -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct:

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

Chris Angelico wrote: It would NOT work for anything where the bool() of the desired object doesn't exactly match the loop's condition. while condition(x) where x = something(): ... -- Greg ___ Python-ideas mailing list

[Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

PEP 572 as it stands seems to have many problems: * Asymmetry between the first and subsequent uses of the bound value * Embedded as-clauses are subtle and hard to spot * Ever more convoluted semantics are being invented to address percieved pitfalls Alternative proposal

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

On 28 February 2018 at 21:48, Robert Vanden Eynde wrote: Isn't it easier to talk on a forum? For me, the fact that all the mailing lists I subscribe to feed into one input queue is a feature, not a bug. It means I can easily keep abreast of developments in many areas at

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

On Mon, Feb 19, 2018 at 5:58 AM, Sylvain MARIE > wrote: By the way, is there a reason for the name "Integral" (algebraic theory) instead of "Integer" (computer science) ? Would it be practically

Re: [Python-ideas] Consider generalizing Decimal to support arbitrary radix

Mark Dickinson wrote: And base-16 floating-point is still used in current IBM hardware, but I don't know whether that's purely for historical/backwards-compatibility reasons, or because it's faster for the FPU. Historically, base 16 was used to get a bigger exponent range for a given number

Re: [Python-ideas] Format mini-language for lakh and crore

Nick Coghlan wrote: - "," would be short for ",3," with decimal digits - "_" would be short for "_3_" with decimal digits - "_" would be short for "_4_" with binary/octal/hexadecimal digits Is it necessary to restrict "," to decimal? Why not make "," and "_" orthogonal? While "," with

Re: [Python-ideas] Suggest adding struct iter_unpack allowing mixed formats & add iter_pack

Steve Barnes wrote: It would be very nice if: a) iter_unpack.next produced an iterator that optionally took an additional parameter of a format string, (with endianness permitted), to replace the current format string in use. Hmmm, rather than screw around with the iterator protocol, it

Re: [Python-ideas] Non-intrusive debug logging

Steve Barnes wrote: I would suggest, however, that if this feature is introduced it be controlled via a run-time switch &/or environment variable which defaults to off. I disagreew with defaulting it to off. That would encourage lazy developers to distribute library code full of #l lines, so

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

On 12/04/2017 10:01 AM, brent bejot wrote: I think we can all agree that defining __key__ and calling "sorted(list_of_attrdicts)" has that syntactic sugar that is oh-so-sweet-and-tasty. Just remember that too much syntactic sugar can give you cancer of the semicolon. -- Greg

Re: [Python-ideas] How assignment should work with generators?

C Anthony Risinger wrote: * Unpacking is destructuring not pattern matching. We're just arguing about the definition of terms now. The point I was making is that unpacking is fundamentally a declarative construct, or at least that's how I think about it. I used the term "pattern matching"

Re: [Python-ideas] How assignment should work with generators?

Steve Barnes wrote: Since the practical difference between remainder being the (partly exhausted) iterator and it being a list, (itself an iterator), A list is *not* an iterator, it's a sequence. There's a huge difference. Items of a sequence can be accessed at random, it can be iterated over

Re: [Python-ideas] How assignment should work with generators?

Steven D'Aprano wrote: On Wed, Nov 29, 2017 at 07:33:54PM +, Steve Barnes wrote: Just a thought but what about a syntax something along the lines of: a, b, *remainder = iterable Where remainder becomes the iterable with the first two values consumed by assigning to a & b. Guido's

Re: [Python-ideas] Add a dict with the attribute access capability

Ivan Pozdeev via Python-ideas wrote: I needed to hold an external function reference in an object instance (if I assigned it to an attribute, it was converted into an instance method). No, that only happens to functions stored in *class* attributes, not instance attributes. >>> class A: ...

Re: [Python-ideas] How assignment should work with generators?

Brendan Barnwell wrote: That's an interesting analysis, but I don't think your view is really the right one. It *is* unpacking a suitcase, it's just that *if necessary* the suitcase is constructed just in time for you to unpack it. I don't think that's right. An iterator created from a

<    2   3   4   5   6   7   8   9   >