Re: [Python-ideas] Shuffled

On Tue, Sep 6, 2016 at 2:48 PM, David Mertz wrote: > On Tue, Sep 6, 2016 at 1:15 PM, Sven R. Kunze wrote: >> >> Their response: "Oh, I don't need it, let's close it." >> Arek: "But I need it." > > > This definitely feels like a case of "put it on PyPI."

Re: [Python-ideas] Shuffled

[Sven R. Kunze ] > ... > He already convinced some people. Just not some venerable Python devs, which > doesn't necessarily mean something at all. > > Their response: "Oh, I don't need it, let's close it." > Arek: "But I need it." > > So, who's right now? By default, the

Re: [Python-ideas] Shuffled

[Sven R. Kunze ] >>> >>> ... >>> He already convinced some people. Just not some venerable Python devs, >>> which>> doesn't necessarily mean something at all. >>> >>> Their response: "Oh, I don't need it, let's close it." >>> Arek: "But I need it." >>> >>> So, who's right now?

Re: [Python-ideas] Shuffled

[David Mertz ] > This definitely feels like a case of "put it on PyPI." Actually, maybe > contribute to `boltons`, it feels like it might fit as a utility function > there. It's trivial to write such a function if it's truly needed - it would be easier to write it from scratch

Re: [Python-ideas] Shuffled

[Sven R. Kunze ] > I am not questioning experience which everyone in a team can benefit from. > > > BUT experienced devs also need to recognize and respect the fact that > younger/unexperienced developers are just better in detecting > inconsistencies and bloody work-arounds. They

Re: [Python-ideas] [Python-Dev] Drastically improving list.sort() for lists of strings/ints

[redirected from python-dev, to python-ideas; please send followups only to python-ideas] [Elliot Gorokhovsky ] > ... > TL;DR: Should I spend time making list.sort() detect if it is sorting > lexicographically and, if so, use a much faster algorithm? It will be fun to

Re: [Python-ideas] [Python-Dev] Drastically improving list.sort() for lists of strings/ints

[Elliot Gorokhovsky ] > Wow, Tim himself! And Elliot himself! It's a party :-) > Regarding performance on semi-ordered data: we'll have to > benchmark to see, but intuitively I imagine radix would meet Timsort > because verifying that a list of strings is sorted

Re: [Python-ideas] Py_SIZE of PyLongs

[Elliot Gorokhovsky ] > I'm working on a special-case compare function for bounded integers for the > sort stuff. By looking at the implementation, I figured out that Py_SIZE of > a long is the sign times the number of digits (...right?). > ... Please ignore the

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

[Sven R. Kunze ] > Indeed. I also didn't know about that detail of reversing. :) Amazing. (Also > welcome to the list, Alireza.) It follows from what the docs say, although I'd agree it may be helpful if the docs explicitly spelled out this consequence (that reverse=True also

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

[Paul Moore] > My understanding is that the code does a per-check that all the > elements of the list are the same type (float, for example). This is a > relatively quick test (O(n) pointer comparisons). If everything *is* a > float, then an optimised comparison routine that skips all the type >

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

[Nick Coghlan] > It's probably more relevant that cmp() went away, since that > simplified the comparison logic to just PyObject_RichCompareBool, > without the custom comparison function path. Well, the current sort is old by now, and was written for Python 2. But it did anticipate that rich

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

[Alireza Rafiei ] > I have a list called count_list which contains tuples like below: > > > [('bridge', 2), ('fair', 1), ('lady', 1), ('is', 2), ('down', 4), > > ('london', 2), ('falling', 4), ('my', 1)] > > > I want to sort it based on the second parameter in

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

[Tim Delaney ] > Isn't there already always a scan of the iterable to build the keys array > for sorting (even if no key keyword param is specified)? No - `.sort()` is a list method, and as such has nothing to do with arbitrary iterables, just lists (perhaps you're

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

[Elliot Gorokhovsky ] > (Summary of results: my patch at https://bugs.python.org/issue28685 makes list.sort() 30-50% > faster in common cases, and at most 1.5% slower in the uncommon worst case.) > ... Would someone please move the patch along? I expect it's my

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

[Chris Angelico ] > Arbitrary comparison functions let you do anything but whoa, I > cannot imagine any way that this would ever happen outside of "hey > look, here's how you can trigger a SystemError"! CPython is full of defensive code protecting against malicious crap.

[Python-ideas] Reducing collisions in small dicts/sets

Short course: the average number of probes needed when searching small dicts/sets can be reduced, in both successful ("found") and failing ("not found") cases. But I'm not going to pursue this. This is a brain dump for someone who's willing to endure the interminable pain of arguing about

Re: [Python-ideas] Reducing collisions in small dicts/sets

[MRAB ] > If the current scheme suffers only for small tables, couldn't you use an > alternative scheme only for small tables? Sure. But whether that's desirable partly depends on timing actual C code. Try it ;-) For maintenance sanity, it's obviously better to have

Re: [Python-ideas] Reducing collisions in small dicts/sets

[Tim] >... I haven't yet thought of a cheap way to compute an > `inc` for double-hashing that isn't vulnerable to bad behavior for > _some_ easily constructed set of int keys. If you forget "cheap", > it's easy; e.g., > > random.seed(h) > inc = random.choice(range(1, mask + 1, 2)) Heh.

Re: [Python-ideas] Reducing collisions in small dicts/sets

Two bits of new info: first, it's possible to get the performance of "double" without division, at least via this way: """ # Double hashing using Fibonacci multiplication for the increment. This # does about as well as `double`, but doesn't require division. # # The multiplicative constant

Re: [Python-ideas] Hexadecimal floating literals

onals, nobody needs to understand 854 at all to use these things, so long as they stick to exactly representable numbers. Whether a specific literal _is_ exactly representable, and what happens if it's not, does require understanding a whole lot - but that's also true of decimal float liter

Re: [Python-ideas] Hexadecimal floating literals

[Antoine Pitrou ] > ... > The main difference is familiarity. "scientific" notation should be > well-known and understood even by high school kids. Who knows about > hexadecimal notation for floats, apart from floating-point experts? Here's an example: you <0x0.2p0 wink>.

Re: [Python-ideas] Pattern Matching Syntax

[Guido] > Can I recommend going slow here? This is a very interesting topic where many > languages have gone before. I liked Daniel F Moisset's analysis about the > choices of a language designer and his conclusion that match should be a > statement. Just to be annoying ;-) , I liked the way he

Re: [Python-ideas] Pattern Matching Syntax

[Tim] >> ... I liked the way he _reached_ that conclusion: by looking at real- >> life Python code that may have been written instead to use constructs >> "like this". I find such examination far more persuasive than abstract >> arguments or made-up examples. [Serhiy Storchaka

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

[Nick Coghlan ] > ... > The essence of the given clause concept would be to modify *these specific > cases* (at least initially) to allow the condition expression to be followed > by an inline assignment, of the form "given TARGET = EXPR". I'm not clear on what "these specific

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> There's a difference, though: if `y` "leaks", BFD. Who cares? ;-) >> If `y` remains inaccessible, there's no way around that. [Chris] > That's Steve D'Aprano's view - why not just let them ALL leak? I don't > like it though. I didn't suggest that. I'm not suggesting changing _any_

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> I have a long history of arguing that magically created lexically >> nested anonymous functions try too hard to behave exactly like >> explicitly typed lexically nested functions, but that's the trendy >> thing to do so I always lose ;-) [Nick Coghlan ] > You have the

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Chris Angelico ] > ... > You're correct. The genexp is approximately equivalent to: > > def genexp(): > for p in small_primes: > thisp = p > yield n % thisp == 0 > while any(genexp()): > n //= thisp > > With generator expressions, since they won't

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> In a different thread I noted that I sometimes want to write code like >> this: >> ... >>while any(n % (thisp := p) == 0 for p in small_primes): >>n //= thisp >> ... [Ryan Gonzalez ] > Couldn't you just do: > > def first(it): >return next(it, None) > >

[Python-ideas] A comprehension scope issue in PEP 572

In a different thread I noted that I sometimes want to write code like this: while any(n % p == 0 for p in small_primes): # divide p out - but what's p? But generator expressions hide the value of `p` that succeeded, so I can't. `any()` and `all()` can't address this themselves -

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

[Tim] >> ... >> It's no longer the case that Python avoided that entirely, since >> "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. At this stage in Python's >>

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

[Steven D'Aprano ] >>> ... >>> average = 0 >>> smooth_signal = [(average := (1-decay)*average + decay*x) for x in signal] >>> assert average == smooth_signal[-1] [Tim] >> The scope issues are logically independent of assignment-expression >> spelling, but it's a pretty safe

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

[Greg Ewing '] > This whole discussion started because someone wanted a way > to bind a temporary result for use *within* a comprehension. It's been noted several times recently that the example PEP 572 gives as _not_ working: total = 0 progressive_sums =

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> """ >> An assignment expression binds the target, except in a function F >> synthesized to implement a list comprehension or generator expression >> (see XXX). In the latter case[1], the target is bound in the block >> containing F, and errors may be detected: If the target also appears

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

>> total = 0 >> progressive_sums = [total := total + value for value in data] [Greg Ewing ] > I'm skeptical that it's a good idea to encourage this kind of thing > in the first place. Adding a feature is creating possibility for its use, not encouraging its

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

[Terry Reedy ] > ... > The impact on real-time syntax coloring should be considered. An re-based > colorizer, like IDLE's, tags every appearance of keywords outside of strings > and comments, syntactically correct or not. For instance, the first two > 'and's in "a and b.and #

Re: [Python-ideas] A partial (wacky?) alternative to assignment expressions

[Steven D'Aprano ] > I'm hoping that the arguments for assignment expressions will be over by > Christmas *wink* so as a partial (and hopefully less controversial) > alternative, what do people think of the idea of flagging certain > expressions as "pure functions" so the

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

Just noting some real code I typed today where `given` works great if it allows unpacking syntax, and assignment expressions don't: while True: head, matched, s = s.partition(sep) if not matched: break Using `given`: while matched given head, matched, s =

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

[Tim] >> It's been noted several times recently that the example PEP 572 gives >> as _not_ working: >> >> total = 0 >> progressive_sums = [total := total + value for value in data] >> >> was the original use case that prompted work on the PEP. You gotta >> admit that's ironic ;-) [Nick]

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] > While I don't have real use cases beyond that, given that much, > "consistency" kicks in to suggest that: > > def f(): > [x := 42 for x in range(1)] > > makes `x` local to `f` despite that x wasn't bound elsewhere in f's body. > > def f(): > global x > [x

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Terry Reedy ] > ... > If I am understanding correctly, this would also let one *intentionally > 'leak' (export) the last value of the loop variable when wanted. > > [math.log(xlast:=x) for x in it if x > 0] > print(xlast) Yup! You can do that today by emulating a nonlocal

Re: [Python-ideas] A cute Python implementation of itertools.tee

I posted this several weeks ago, just for fun - an obscure but surprisingly brief Python implementation of itertools.tee, sharing a single stream (as a singly linked list) among all the returned iterables. Didn't think about it again until today, when recent discussions of lexical scoping made me

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] > ... The ":= is treated specially in comprehensions" idea is aimed > more at them than at people who think invoking a synthetic > anonymous lambda "is obvious". It occurs to me that, while suggestive, this is an unhelpful way to express it. It's not at all that the semantics of ":="

Re: [Python-ideas] A comprehension scope issue in PEP 572

... [Guido] >> We should probably define what happens when you write [p := p for p in >> range(10)]. I propose that this overwrites the loop control variable rather >> than creating a second p in the containing scope -- either way it's probably >> a typo anyway. [Jacco van Dorp

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

[Steven D'Aprano ] > Chris' PEP 572 started off with the concept that binding expressions > would create a "sub-local" scope, below function locals. After some > debate on Python-Ideas, Chris, Nick and Guido took the discussion off > list and decided to drop the sub-local

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

A brain dump, inspired by various use cases that came up during the binding expression discussions. Idea: introduce a "local" pseudo-function to capture the idea of initialized names with limited scope. As an expression, it's "local" "(" arguments ")" - Because it "looks like" a function

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

[Guido] > (I vaguely recall this has been brought up before, but I'm too lazy to find > the subtread. So it goes.) > > PEP 572 currently seems to specify that when used in expressions, the > precedence of `:=` is lower (i.e. it binds more tightly) Umm ... that's the opposite of what the Reference

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Nick Coghlan ] > How would you expect this to work in cases where the generator expression > isn't immediately consumed? If "p" is nonlocal (or global) by default, then > that opens up the opportunity for it to be rebound between generator steps. > That gets especially

Re: [Python-ideas] A comprehension scope issue in PEP 572

Just a quickie - I'm out of time for now. [Guido] >> That's just one of several "don't do that" situations. *What will happen* >> is perhaps hard to see at a glance, but it's perfectly well specified. Not >> all legal code does something useful though, and in this case the obvious >> advice

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> ... >> So long as I'm the only one looking at real-life use cases, mine is >> the only evidence I care about ;-) I don't really care about >> contrived examples, unless they illustrate that a proposal is >> ill-defined, impossible to implement as intended, or likely to have >> malignant

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] > ... > But an assignment expression target name always has the > same scope within a comprehension. [which is a consequence > of the rules - not a rule of its own] Something related to ponder: what's the meaning of the following _without_ the proposed scope change? So the Golden Binding

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim[ >> ... >> ":=" target names in a genexp/listcmp are treated exactly the same as >> any other non-for-target name: they resolve to the same scope as they >> resolve to in the block that contains them. The only twist is that if >> such a name `x` isn't otherwise known in the block, then `x`

Re: [Python-ideas] A comprehension scope issue in PEP 572

Ah, fudge - I pasted in the wrong "high-level" code. Sorry! The code that's actually being emulated is not > list(i + sum((i := i+1) + i for j in range(i)) > for i in range(5)) but list(i + sum((i := i+1) for j in range(i)) + i for i in range(5)) > ... I have piles of

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

[attributions lost - sorry, but I can't get 'em back] ... >>> Similar to import statements, optional parentheses could be included in >>> the >>> grammar, allowing the name bindings to be split across multiple lines: >>> >>>if diff and g > 1 given ( >>>diff = x - x_base, >>>g

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Nick] >> That's all well and good, but it is *completely insufficient for the >> language specification*. > I haven't been trying to write reference docs here, but so far as > supplying a rigorous specification goes, I maintain the above gets > "pretty close". It needs more words, and certainly

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim, suggests changes to the Reference Manual's 4.2.1] > """ > An assignment expression binds the target, except in a function F > synthesized to implement a list comprehension or generator expression > (see XXX). In the latter case, if the target is not in F's > environment (see section 4.2.2)

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim[ >> ... If a comprehension C is in class scope S, apparently the >> class locals are _not_ in C's environment. Since C doesn't >>> even have read access to S's locals, it seems to me bizarre >> that ":=" could _create_ a local in S. [Ethan Furman ] > Python 3.7.0b3+

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

[Matt Arcidy] >> Note Tim came up with a real metric: >> 2 * count(":=")/len(statement). >> It's objective. it's just unclear if a higher score is better or worse. >> However, one could say "a Tim of .3 is considered too high" as a guideline. [Steven D'Aprano] > I think Tim was making a joke

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> - If the target is not local to any function enclosing F, and is not >> declared `global` in the block containing F, then the target is bound >> in the block containing F. [also Tim] > FYI, that's still not right, ... > I suspect that the above should be reworded to the simpler: > > - If

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] > ... > - If the target is not local to any function enclosing F, and is not > declared `global` in the block containing F, then the target is bound > in the block containing F. FYI, that's still not right, but I've been distracted by trying to convince myself that the manual actually

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> Since this is all about scope, while I'm not 100% sure of what Guido >> meant, I assumed he was saying "p can only have one scope in the >> synthetic function: local or non-local, not both, and local is what I >> propose". For example, let's flesh out his example a bit more: >> >> p

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

[Guido] > ,,, > OT about the name: despite Tim's relentless pushing of "binding expressions" > in the end I think they should be called "assignment expressions" just like > in C. Ha! I already gave up on "binding expressions". For nearly a full day, I've been rigidly calling them "binding

Re: [Python-ideas] A comprehension scope issue in PEP 572

... [Guido] >> You should really read Tim's initial post in this thread, where he >> explains his motivation. [Nick] > I did, and then I talked him out of it by pointing out how confusing it > would be to have the binding semantics of "x := y" be context dependent. Ya, that was an effective

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

[Brendan Barnwell] >> >> . . . and it's true the latter is a bit more verbose in that case for >> little extra benefit. But when the locally-defined value is used within >> a more complicated expression (like the quadratic formula example), I >> think readability goes down significantly. To

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

[Gustavo Carneiro] >>> 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. [Greg Ewing] >> I don't believe that's always true.

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Guido] > I am convinced by Tim's motivation. I hadn't thought of this use case before > -- I had mostly thought "local scope in a comprehension or generator > expression is the locals of the synthetic function". But Tim's reasoning > feels right. I'm trying very hard _not_ to reason. That is,

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> In a different thread I noted that I sometimes want to write code like >> this: >> >> while any(n % p == 0 for p in small_primes): >> # divide p out - but what's p? >> >> But generator expressions hide the value of `p` that succeeded, so I >> can't. `any()` and `all()`

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> (inside a synthetic function created to >> implement a listcomp/genexp, names bound by "=" are local; names bound >> by ":=" are nonlocal; names bound by both are "who cares?"- >> compiler-time error would be fine by me, or the first person to show a >> real use case wins). [Jacco van

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Guido] >> So the way I envision it is that *in the absence of a nonlocal or global >> declaration in the containing scope*, := inside a comprehension or genexpr >> causes the compiler to assign to a local in the containing scope, which is >> elevated to a cell (if it isn't already). If there is

Re: [Python-ideas] A comprehension scope issue in PEP 572

These all match my expectations. Some glosses: [Guido] > So the way I envision it is that *in the absence of a nonlocal or global > declaration in the containing scope*, := inside a comprehension or genexpr > causes the compiler to assign to a local in the containing scope, which is > elevated

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

[Nick] >... > There were a couple key reasons I left the "for x in y" case out of the > initial proposal: > > 1. The "for x in y" header is already quite busy, especially when tuple > unpacking is used in the assignment target > 2. Putting the "given" clause at the end would make it ambiguous as

Re: [Python-ideas] Pattern Matching Syntax

[Tim] ... I liked the way he _reached_ that conclusion: by looking at real- life Python code that may have been written instead to use constructs "like this". I find such examination far more persuasive than abstract arguments or made-up examples. [Serhiy] >>> I would like

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

[Steven D'Aprano ] > ... > Red (2011) > ... > ... claims to be nearly identical to Rebol. > > Wikipedia describes Rebol (and presumably Red) as not having either > expressions or statements in usual sense. Based on my reading, it is > kinda-sorta like Forth except without the

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

[Tim] >> I was an early REBOL user, and my head still hurts ;-) It was ... >> different, for sure. [Steven D'Aprano ] > Yeah, to me it looks more like a prefix version of Forth than Lisp. > Complete with "anything can be a name": The example I gave just strung "words"

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

[Tim, on Rebol/Red] >> >> x: 12 y: 13 >> == 13 >> >> [x y] >> == [x y] >> >> >> >> do [x y] >> == 13 [Greg Ewing ] > How does scoping work? If you pass a block to a function > which evaluates it, how are names in the block resolved? Too involved, but basically a form

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

[Peter O'Connor] >> ... >> We could use given for both the in-loop variable update and the variable >> initialization: >>smooth_signal = [average given average=(1-decay)*average + decay*x >> for x in signal] given average=0. [Steven D'Aprano

Re: [Python-ideas] High Precision datetime

[Chris Barker] > Does that support the other way -- or do we never lose a leap second anyway? > (showing ignorance here) Alexander covered the Python part of this, so I'll answer the possible higher-level question: we haven't yet needed a "negative" leap second, and it's considered unlikely (but

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

[Terry Reedy] > ... > I believe avoiding tagging raw names as keywords could be done by adjusting > the re for keywords Yup - it should just require adding a negative lookbehind assertion; e.g., >>> import re >>> keypat = r"(?>> re.search(keypat, r"yup! while") <_sre.SRE_Match object; span=(5,

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

[Steven D'Aprano] > ... The initial proposal is fine: a separate set of trig functions that take > their arguments in degrees would have no unexpected surprises (only the > expected ones). With a decent implementation i.e. not this one: > > # don't do this > def sind(angle): >

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

> > > [Tim] >> 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 > > [Greg Ewing] > So why doesn't float % use math.fmod? >

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

[Richard Damon] > My first comment is that special casing values like this can lead to > some very undesirable properties when you use the function for numerical > analysis. Suddenly your sind is no longer continuous (sind(x) is no > longer the limit of sind(x+d) as d goes to 0). > > As I stated

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

I should note that numeric code "that works" is often much subtler than it appears at first glance. So, for educational purposes, I'll point out some of what _wasn't_ said about this crucial function: [Tim] > import mpmath > from math import fmod > # Return (n, x) such that: > #

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

[Steven D'Aprano ] > Thanks Tim! > You're welcome ;-) > Reading your digressions on the minutia of floating point maths is > certainly an education. It makes algebra and real-valued mathematics > seem easy in comparison. > Hard to say, really. The problem with floating point is that it's so

Re: [Python-ideas] Fwd: collections.Counter should implement fromkeys

[ Note to repliers to Abe (and others recently): replies to Google Groups posts are broken for now on this list, so be sure to replace python-id...@googlegroups.com with python-ideas@python.org in your reply. Else the mailing list (neither Google Groups nor the python.org archive)

[Python-ideas] Fwd: collections.Counter should implement fromkeys

Reposting because the original got bounced from Google Groups. -- Forwarded message - From: Tim Peters Date: Fri, Jun 29, 2018 at 5:54 PM Subject: Re: [Python-ideas] collections.Counter should implement fromkeys To: Cc: python-ideas [Abe Dillon ] > ... > I'm using th

Re: [Python-ideas] random.sample should work better with iterators

> > [Tim] > In Python today, the easiest way to spell Abe's intent is, e.g., > > > > >>> from heapq import nlargest # or nsmallest - doesn't matter > > >>> from random import random > > >>> nlargest(4, (i for i in range(10)), key=lambda x: random()) > > [75260, 45880, 99486, 13478] > > >>>

Re: [Python-ideas] random.sample should work better with iterators

[Abe Dillon] > Randomly sampling from some population is often done because the entire > > population is impractically large which is also a motivation for using > > iterators, so it seems natural that one would be able to sample from an > > iterator. A naive implementation could use a heap

Re: [Python-ideas] Fwd: collections.Counter should implement fromkeys

[Abe Dillon] > I haven't been part of the conversation for 15 years, but most of the argument > against the idea (yours especially) seem to focus on the prospect of a > constructor war and imply that was the original motivation behind actively > disabling the fromkeys method in Counters. I quoted

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

[MRAB] > By "inject" I mean putting a name into a namespace: > > import my_module > my_module.foo = 'FOO' > > You can't insert a name into a function's body to make a new local variable. So you do mean at runtime, I think. Then as before, you can do that with module and the builtin

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

[MRAB ] > I think it should be lexically scoped. That's certainly arguable, but that's why I like real-code driven design: abstract arguments never end, and often yield a dubious in-real-life outcome after one side is worn out and the other side "wins" by attrition

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

[MRAB] >>> Imagine renaming the specified names that are declared 'local' >>> throughout the nested portion: >>> >>> def f(): >>> a = 10 >>> local local_a: >>> def showa(): >>> print("a is", local_a) >>> showa() # Raises NameError in showa because nothing bound

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

[MRAB] >>> Would/should it be possible to inject a name into a local scope? You can't >>> inject into a function scope, and names in a function scope can be >>> determined statically (they are allocated slots), so could the same kind of >>> thing be done for names in a local scope? ... [Steven

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

[MRAB] >> There's another question that hasn't been asked yet: what should locals() >> and globals() return? [Tim, "globals()" is obvious, "locals()" can be surprising now] > ... And here recording the results of some code spelunking Dicts don't really have anything to do with how locals are

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

[MRAB ] > ... > The intention is that only the specified names are local. > > After all, what's the point of specifying names after the 'local' if _any_ > binding in the local scope was local? Don't look at me ;-) In the absence of use cases, I don't know which

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

[MRAB] >> Any binding that's not specified as local is bound in the parent scope: [Tim] > Reverse-engineering the example following, is this a fair way of > making that more precise? > > Given a binding-target name N in scope S, N is bound in scope T, where > T is the closest-containing scope

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

[Ethan Furman ] > If we need a sublocal scope, I think the most Pythonic* route to have it > would be: > > with sublocal(): > blah blah > > which would act just like local/global does now: > > - any assignment creates a new variable > - unless that variable

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

[Tim] >> Then `c` is 12, but `a` is still 1 and `b` is still 2. Same thing in the >> end: >> >> c = local(a=3, b=4, a*b) [Nikolaus Rath ] > I think this can be done already with slighly different syntax: > > c = (lambda a=3, b=4: a*b)() > > The trailing () is a little ugly,

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

[Tim] >> ... >> This is the kind of code about which there have been background >> complaints "forever": >> >> m1 = regexp1.match(line) >> m2 = regexp2.match(iine) >> if m1 and m2: >> do all sorts of stuff with m1 and/or m2, >> including perhaps modifying local

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

[Tim] Then `c` is 12, but `a` is still 1 and `b` is still 2. Same thing in the end: c = local(a=3, b=4, a*b) [Nikolaus Rath ] >>> I think this can be done already with slighly different syntax: >>> >>> c = (lambda a=3, b=4: a*b)() >>> >>> The trailing ()

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

[Tim] > ... > Here's an example where I don't know what the consequences of "the > rules" should be: > > def f(): > a = 10 > local a: > def showa(): > print("a is", a) > showa() # 10 > a = 20 > showa() # 20 > a = 30 > showa() # 10 > >

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

[David Mertz ] > Ooops. My proof on anti-concept has a flaw. It only "shadows" names that > already exist. Presumably that's the wrong idea, but it's easy enough to > change if desired. Even in the very early days when Python's runtime was more relentlessly simple-minded than

  1   2   3   >