[Python-ideas] Re: commonprefix

[Rob Cliffe] > The os.path.commonprefix function basically returns the common initial > characters (if any) shared by a sequence of strings, e.g. > ... > It seems to me that this function (or something similar) should not be > in os.path, but somewhere else where it would be more visible. It's ce

[Python-ideas] Re: Giving Decimal a global context was a mistake?

[David Mertz] >> Because the module implements >> http://speleotrove.com/decimal/decarith.html >> [Greg Ewing] > Well, yes, but someone made the decision to implement that > particular standard rather than one of the ones with fixed > precision. I'm a

[Python-ideas] Re: Giving Decimal a global context was a mistake?

[Greg Ewing ] > So can you elaborate on how you use variable precision? Numeric programmers frequently want this. An extreme example is in function `collision_stats()` in your Python distribution's Lib/test/support/__init__.py. This needs to compute the variance of a distribution for which we only

[Python-ideas] Re: Giving Decimal a global context was a mistake?

[Christopher Barker ] > So what does Decimal provide? Two things that you can't do with the built-in > (hardware) float: > > Variable precision > Control of rounding And a third: precisely defined results in base 10. You're thinking like an engineer, not an accountant ;-) Politicians don't know a

[Python-ideas] Re: Regex timeouts

[Tim, on trying to match only the next instance of "spam"] > ,,, > It's actually far easier if assertions are used, and I'm too old to > bother trying to repair the non-assertion mess: > > ([^s]|s(?!pam))*spam Since then, Serhiy rehabilitated an old patch to add "atomic groups" and "possessive qua

[Python-ideas] Re: A modulo operator consistent with euclidean division.

[Steven D'Aprano ] > Sure, for floats. I certainly wouldn't want to change the behaviour for > floats. We could change the behaviour for ints (or at least we could if > not constrained by backwards compatibility) or add a new function. We could - but why would we? Just because a thing _can_ be don

[Python-ideas] Re: A modulo operator consistent with euclidean division.

[Steven D'Aprano [\ > Alas, math.remainder goes through float: > > >>> math.remainder(3**500, 3) # Should be 0. > 1.0 > >>> math.remainder(3**500 + 2, 3) # Should be 2. > 1.0 You mean -1 here: remainder() returns a member of the equivalence class with least absolute value, and abs(-1) < abs(2).

[Python-ideas] Re: A modulo operator consistent with euclidean division.

[Nathan Levett ] > First time posting here ~ I've recently encountered that python does not > have an OOTB operator for modulo that is consistent with Euclidean > division. You need to be very explicit about what you intend - my best guess about what you intend isn't supported directly by any prog

[Python-ideas] Re: Make 10**400 / 1e200 work?

[Tim] > >>> cmath.phase(complex(0.0, 0.0)) > 0.0 > >>> cmath.phase(complex(-0.0, 0.0)) > 3.141592653589793 > >>> cmath.phase(complex(0.0, -0.0)) > -0.0 > >>> cmath.phase(complex(-0.0, -0.0)) > -3.141592653589793 [Marco Sulla ] > Whoa. I'm quite curious about why. ... There's no compelling reason

[Python-ideas] Re: Make 10**400 / 1e200 work?

[Om Joshi ] > I spent a couple hours putting this together: > https://github.com/omajoshi/complex_math > > It does lazy updating, staying in polar form until an addition, then staying > in > rectangular form until the next multiplication. > > I implemented Tim Peters'

[Python-ideas] Re: Make 10**400 / 1e200 work?

[Dennis Sweeney ] > The non-associativity isn't just signed zeros: regular floating point > addition and multiplication of positive numbers is not associative Yes, but that's shallow, having to do with rounding errors. In the example I gave, the "inexact" flag never gets set. As far as 754 is con

[Python-ideas] Re: Make 10**400 / 1e200 work?

I have to say that signed zeroes and signed infinities don't work well in 754 for complex numbers. I know Kahan _wanted_ signed zeroes to help sort out branch cuts for complex functions, but he appears to be alone in the world in finding them useful for that ;-) Complex multiplication for values w

[Python-ideas] Re: Make 10**400 / 1e200 work?

[Mark Dickinson ] > > There's definitely potential benefit in some of this - e.g., It Would Be Nice > If > `-1 * complex(inf, 0.0)` gave `complex(-inf, -0.0)` instead of the current > result of > `complex(-inf, nan)`. Except replacing -1 with "-1.0" or "complex(-1)" would presumably _still_

[Python-ideas] Re: Make 10**400 / 1e200 work?

[Ben Rudiak-Gould ] > ... > Python follows the IEEE rounding model for float/float and int/int. > Following it for float/int and int/float would be pretty easy since > the hard work has already been done to support int/int. It doesn't end there. Mark was asking about analogous behavior for mixing

[Python-ideas] Re: Make 10**400 / 1e200 work?

[Mark Dickinson ] > Unrelated question: under this proposal, what would you want > `Fraction(10**400) / 1e200` to do? Should it also produce a > `float` approximation to 1e200, or is it okay for it to raise > `OverflowError` as it currently does? The principled alternative to the current "in mixed

[Python-ideas] Re: Make 10**400 / 1e200 work?

[Tim] >> int.__truediv__ makes semi-heroic efforts to >> get 10**400 / int(1e200) "right" (well, as right as can be) [Stefan Pochmann ] > Yes, those semi-heroic efforts actually are what inspired my > question. A few days ago I noticed that and was delighted it works. > > Use case was the exact ca

[Python-ideas] Re: Make 10**400 / 1e200 work?

[Stefan Pochmann ] > It crashes because it tries to convert 10**400 to a float and that fails: > > >>> 10**400 / 1e200 > Traceback (most recent call last): > File "", line 1, in > 10**400 / 1e200 > OverflowError: int too large to convert to float > > But with two ints it succeeds: > > >>> 10

[Python-ideas] Re: Regex timeouts

[J.B. Langston ] > And unfortunately it does appear that my app took an almost a 20% > performance hit from using regex instead of re, unfortunately. > Processing time for a test dataset with 700MB of logs went from > 77 seconds with the standard library re to 92 seconds with regex. > Profiling c

[Python-ideas] Re: Regex timeouts

[Steven D'Aprano ] > [skipping FUD about pip] If the OP: has problems with pip they can't easily resolve, I expect they'll say so. In my experience, effective help consists of sticking to the simplest things that can possibly work at first, not bury a questioner with an exhaustive account of every

[Python-ideas] Re: Regex timeouts

[J.B. Langston ] > Thanks for the conclusive answer. Not conclusive - just my opinion. Which is informed, but not infallible ;-) > I will checkout the regex library soon. You may not realize how easy this is? Just in case: go to a shell and type pip install regex (or, on Windows, "python -m p

[Python-ideas] Re: Regex timeouts

[MRAB ] > I eventually decided against having it added to the standard library > because that would tie fixes and additions to Python's release cycle, > and there's that adage that Python has "batteries included", but not > nuclear reactors. PyPI is a better place for it, for those who need more >

[Python-ideas] Re: Regex timeouts

[J.B. Langston ] > Well, I certainly sparked a lot of interesting discussion, which I have > quite enjoyed reading. But to bring this thread back around to its > original topic, is there support among the Python maintainers for > adding a timeout feature to the Python re library? Buried in the fun

[Python-ideas] Re: Regex timeouts

[Chris Angelico ] > Is there any sort of standardization of regexp syntax and semantics, Sure. "The nice thing about standards is that you have so many to choose from" ;-) For example, POSIX defines a regexp flavor so it can specify what things like grep do. The ECMAScruot standard defines its own

[Python-ideas] Re: Regex timeouts

[Steven D'Aprano ] > After this thread, I no longer trust that "easy" regexes will do what > they "obviously" look like they should do :-( > > I'm not trying to be funny or snarky. I *thought* I had a reasonable > understanding of regexes, and now I have learned that I don't, and that > the regexes

[Python-ideas] Re: Regex timeouts

[Tim, on trying to match only the next instance of "spam"] > Assertions aren't needed, but it is nightmarish to get right. Followed by a nightmare that got it wrong. My apologies - that's what I get for trying to show off ;-) It's actually far easier if assertions are used, and I'm too old to bot

[Python-ideas] Re: Regex timeouts

[Steven D'Aprano ] > I've been interested in the existence of SNOBOL string scanning for > a long time, but I know very little about it. > > How does it differ from regexes, and why have programming languages > pretty much standardised on regexes rather than other forms of string > matching? What

[Python-ideas] Re: Regex timeouts

[Tim] >> In SNOBOL, as I recall, it could be spelled >> >> ARB "spam" FENCE [Chris] > Ah, so that's a bit more complicated than the "no-backtracking" > parsing style of REXX and scanf. Oh, a lot more complex. In SNOBOL, arbitrary computation can be performed at any point in pattern matching..

[Python-ideas] Re: Regex timeouts

[Tim] >>> That leaves the happy 5% who write "[^X]*X", which >>> finally says what they intended from the start. [Steven] >> Doesn't that only work if X is literally a single character? RIght. It was an examp[e, not a meta-example. Even for a _single character_, "match up to the next, but never m

[Python-ideas] Re: Regex timeouts

""" Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. - Jamie Zawinski """ Even more true of regexps than of floating point, and even of daemon threads ;-) regex is a terrific module, incorporating many features that newer reg

[Python-ideas] Re: itertools.compress default selectors

[Chris Angelico ] > ... > For it to be accepted, you have to convince people - particularly, > core devs - that it's of value. At the moment, I'm unconvinced, but on > the other hand, all you're proposing is a default value for a > currently-mandatory argument, so the bar isn't TOO high (it's not l

[Python-ideas] Re: itertools.compress default selectors

FYI, itertools.compress() is very useful in conjunction with itertools.cycle() to pick out elements following a periodic pattern of indices. For example, # Elements at even indices. >>> list(compress(range(20), cycle([1, 0]))) [0, 2, 4, 6, 8, 10, 12, 14, 16, 18] # Or at odd ones. >>> list(compres

[Python-ideas] Re: Exact decimal multiplication and division operations

[Tim] >> I suggested following the standards' rules (the constructor works the >> same way as everything else - it rounds) for Python's module too, but >> Mike Cowlishaw (the decimal spec's primary driver) overruled me on >> that. [Greg Ewing ] > Did he offer a rationale for that? Possibly, but I

[Python-ideas] Re: Exact decimal multiplication and division operations

[Steven D'Aprano ] > ... > (To be honest, I was surprised to learn that the context precision is > ignored when creating a Decimal from a string. I still find it a bit odd > that if I set the precision to 3, I can still create a Decimal with > twelve digits.) You're not alone ;-) In the original

[Python-ideas] Re: Exact decimal multiplication and division operations

[Random832 ] [various bits of pushback, which all basically boil down to this one:} > ... > That is nonsense. "exactly representable" is a plain english phrase and > has a clear meaning that only involves the actual data format, not the > context. The `decimal` module implements a very exacting s

[Python-ideas] Re: Exact decimal multiplication and division operations

[Tim] >> Try to spell out what you mean - precisely! - by "this". I can't do >> that for you. For any plausible way of fleshing it out I've thought >> of, the answer is "no". [Marco Sulla ] > Well, please, don't be so harsh. I'm trying to discuss to someone that > co-created Python itself, it's no

[Python-ideas] Re: Exact decimal multiplication and division operations

[Tim] >> But the decimal spec takes a different approach, which Python's docs >> don't explain at all: the otherwise-mysterious ROUND_05UP rounding >> mode. Quoting from the spec: >> >> http://speleotrove.com/decimal/damodel.html >> ... >> The rounding mode round-05up permits arithmet

[Python-ideas] Re: Exact decimal multiplication and division operations

[Random832 ] > My suggestion was for a way to make it so that if an exact result is > exactly representable at any precision you get that result, with > rounding only applied for results that cannot be represented exactly > regardless of precision. That may have been the suggestion in your head ;-

[Python-ideas] Re: Exact decimal multiplication and division operations

[Random832] > I don't understand what's unclear - Obviously ;-) But without carefully constructed concrete use cases, what you say continues to remain unclear to me. > I was suggesting there should be an easy way to have the exact > result for all operations on Decimal operands that have exact r

[Python-ideas] Re: Exact decimal multiplication and division operations

[Random832 ] > I was making a "convert Fraction to Decimal, exactly if possible" function and > ran into a wall: it's not possible to do some of the necessary operations with > exact precision in decimal: > > - multiplication > - division where the result can be represented exactly [the divisor is

[Python-ideas] Re: Reliable Ordering Of Sets

[Cade Brown , suggests ordered sets] FYI, last time this went around was December, with over 100 msgs here: https://mail.python.org/archives/list/python-...@python.org/thread/AEKCBGCKX23S4PMA5YNDHFJRHDL4JMKY/#AEKCBGCKX23S4PMA5YNDHFJRHDL4JMKY ___ Python-

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Steven D'Aprano ] >> >> The other simple solution is `next(iter(mydict.items()))`. [Guido] > That one always makes me uncomfortable, because the StopIteration it > raises when the dict is empty might be misinterpreted. Basically I never > want to call next() unless there's a try...except Sto

[Python-ideas] Re: Function composition

[Guido] >> I’ve never been able to remember whether (f@g)(x) means f(g(x)) or g(f(x)). >> That pretty much kills the idea for me. [David Mertz] > Well, it means whichever one the designers decide it should mean. But > obviously it's a thing to remember, > and one that could sensibly go the other

[Python-ideas] Re: Live variable analysis -> earlier release?

[Guido] > Look at the following code. > > def foo(a, b): > x = a + b > if not x: > return None > sleep(1) # A calculation that does not use x > return a*b > > This code DECREFs x when the frame is exited (at the return statement). > But (assuming) we can clearly see that x

[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

[Tim] >> If the result of Python's sort is >> >> [x, y] >> >> then I happen to know (because I know everything about its >> implementation) that one of two things is true: >> >> - The original list was also [x, y], and y < x was False. [Steven] > That's my reasoning, based on your earlie

[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

[Steven D'Aprano ] > ... > All I intended was to say that sort would "work" in the sense you state: > it will give *some* permutation of the data, where (I think, correct me > if I'm wrong) each element compares less than the following element. > > Wait, no, that's not right either... each element

[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

[Steven D'Aprano ] > Sorting doesn't require a total order. Sorting only requires a weak > order where the only operator required is the "comes before" operator, > or less than. That's precisely how sorting in Python is implemented. Let's be careful here. Python's list.sort() guarantees that _if_

[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

[Guido] > But beware, IIRC there are pathological cases involving floats, (long) ints > and rounding where transitivity may be violated in Python (though I believe > only Tim Peters can produce an example :-). Not anymore ;-) That is, while comparisons mixing bigints and floats may have

[Python-ideas] Re: Really long ints

[Paul Moore ] > ... > Can you share a bit more about why you need to do this? In the > abstract, having the ability to split numbers over lines seems > harmless and occasionally useful, but conversely it's not at all > obvious why anyone would be doing this in real life. It's not all that uncommon

[Python-ideas] Re: List - append

[Guido, on Pythons before 1.0.2 always printing non-None expression statement results] > Heh. That was such a misfeature that I had thoroughly suppressed any > memory of its existence. -k indeed. :-) I prefer to think of it as a bit of genius :-) The natural desire to avoid mounds of useless out

[Python-ideas] Re: List - append

[Guido] > Sounds like a hallucination or fabrication. Nope! Turns out my memory was right :-) > The behavior of `for i in range(10): i` in the REPL exists > to this day, and list.append() never returned a value. Sure, but those weren't the claims. The claim was that the result of an expression

[Python-ideas] Re: List - append

[David Mertz ] > ... > What we get instead is a clear divide between mutating methods > on collections that (almost) always return None, and functions > like sorted() and reversed() that return copies of the underlying > collection/iterable. Of course, there are many methods that don't > have func

[Python-ideas] Re: List - append

[M Siddharth Prajosh ] > This is more of a doubt than a new idea. Python has always worked > intuitively but this was a bummer. > > A list has an append method. So I can do list.append(value). > I tried doing list(range(10)).append(10) and it returns None. Yes. Most methods that mutate an object

[Python-ideas] Re: Fix statistics.median()?

[David Mertz] >> As me and Uncle Timmy have pointed out, it IS FIXED in sorted(). You just >> need to call: >> >>sorted_stuff = sorted(stuff, key=nan_aware_transform) [Christopher Barker] > But what would that be? floats have inf and -inf -- so how could you force > the NaNs to be at the end

[Python-ideas] Re: Total_order

[David] > What is it, 2**48-2 signaling NaNs and 2**48 quiet NaNs? Is my quick count > correct (in 64-bit)? Any bit pattern where the exponent is all ones (there are 11 exponent bits, giving 2**(64-11) = 2**53 bit patterns with an all-ones exponent), _and_ the significand isn't all 0 (it's an infi

[Python-ideas] Re: Total_order

[David] > Has anyone actually ever used those available bits for the zillions of NaNs > for > anything good? Yes: in Python, many sample programs I've posted cleverly use NaN bits to hide ASCII encodings of delightful puns ;-) Seriously? Not that I've seen. The _intent_ was that, e.g., quiet

[Python-ideas] Re: Fix statistics.median()?

[David] > How is that fancy bitmask version different from my 3-line version? Where he's referring to my: https://bugs.python.org/msg336487 and, I presume, to his: def total_order(x): if math.isnan(x): return (math.copysign(1, x), x) . return (0, x) \ Richard s

[Python-ideas] Re: Fix statistics.median()?

[Richard Damon ] > IEEE total_order puts NaN as bigger than infinity, and -NaN as less than > -inf. > > One simple way to implement it is to convert the representaton to a 64 > bit signed integer (not its value, but its representation) and if the > sign bit is set, complement the bottom 63 bits (be

[Python-ideas] Re: Fix statistics.median()?

[Christopher Barker ] > ... > But the biggest barrier is that it would be a fair bit of churn on the sort() > functions > (and the float class), and would only help for floats anyway. If someone want > to propose this, please do -- but I don't think we should wait for that to do > something > wit

[Python-ideas] Re: Argumenting in favor of first()

[Christopher Barker ] > ... > BTW: this has been a REALLY LONG thread -- I think it's time for a > concrete proposal to be written up, sonce it appears we're not all > clear on what we're talking about. For my part I think a first() function > would be nice, an am open to a couple variations, so so

[Python-ideas] Re: Segmentation of string

[David Mertz ] > Here's a discussion of both a conceptually simple and a convoluted but > fast version (the latter, naturally, by Tim Peters). Not really convoluted - it's the natural thing you'd do "by hand" to move from one partition to the next: look at the curr

[Python-ideas] Re: Argumenting in favor of first()

[Christopher Barker] >> I think we all agree that it does not belong in __builtins__, [Greg Ewing] > Do we? Nobody yet has argued in favor of it - or even suggested it. > I'm not convinced. And that remains true even now ;-) The new part here is that yours is the first message to mention it th

[Python-ideas] Re: Argumenting in favor of first()

[Andrew Barnert ] > Sure, but you can also explain first just fine by saying it returns > the first thing in its argument, and that will stick as well. We have different meanings for "fine" in this context. "The first thing in its argument" is English prose, and prone to misunderstanding. I'm ab

[Python-ideas] Re: Argumenting in favor of first()

[Steven D'Aprano] ... > I don't recall who wants a version of first that raises, I do, for one. But I want both (raising and non-raising) behaviors at times, and the more-itertools version supplies both. > or when that would be useful. There is no practical way to assert than an iterable isn't

[Python-ideas] Re: Argumenting in favor of first()

[Tim] >> BTW, you can go a long way in Python without knowing anything about `iter()` >> or `next()`. But not without mastering `for` loops. That's why I prefer to >> say that, for ordinary cases, >> >> a = first(it) >> >> has the same effect as: >> >> for a in it: >> break [Andr

[Python-ideas] Re: Argumenting in favor of first()

[Brett Cannon] > I'm also sure the docs will say "Returns the first item yielded by the iterable." That > last word is a dead give-away on how the choice will be made on any collection, > Sequence or not. (Doubly true if this goes into itertools.) > > There's also the contingency of users who will

[Python-ideas] Re: Argumenting in favor of first()

[Tim] >> Every suggestion here so far has satisfied that, if S is a non-empty set, >> >> assert next(iter(S)) is first(S) >> >> succeeds. That is, `first()` is _defined_ by reference to iteration >> order. It's "the first" in that order (hence the name). [Stephen J. Turnbull ] > The problem

[Python-ideas] Re: Argumenting in favor of first()

>> Does that mean that first() and next() are undefined for sets? [Stephen J. Turnbull ] > first() is undefined. next() is defined by reference to iterating > over the set (that's why I don't have a problem with iterating over a > set). Every suggestion here so far has satisfied that, if S is a

[Python-ideas] Re: Argumenting in favor of first()

[]Brett Cannon ] > ... > Sorry, "needed" was too strong of a word. It's more about justification for > including in the stdlib and deciding to support it for a decade or more > versus the answer we give for simple one-liners of "put in your personal > toolbox if you don't want to type it out every

[Python-ideas] Re: Argumenting in favor of first()

[Steven D'Aprano ] > It wasn't :-) but we're talking about adding a function to **itertools** > not "container tools", one which will behave subtly different with > containers and iterators. Your use-case ("first item in a container") is > not the same as the semantics "next element of an iterator"

[Python-ideas] Re: Argumenting in favor of first()

[Tim] >> For me, most of the time, it's to have an obvious, uniform way to >> spell "non-destructively pick an object from a container (set, dict, >> list, deque, heap, tuple, custom tree class, ...)". I don't even have >> iterators in mind then, except as an implementation detail. [Steven] > You

[Python-ideas] Re: Argumenting in favor of first()

[Andrew Barnert ] > ... > I think you’re arguing that the philosophy of itertools is just wrong, at > least for > the kind of code you usually write with it and the kind of people who usually > write that code. Is that fair, or am I misrepresenting you here? It's fair enough, although rather than

[Python-ideas] Re: Argumenting in favor of first()

[Brett Cannon ] > Thinking out loud here... > > What idiom are we trying to replace with one that's more obviously and whose > semantics are easy to grasp? For me, most of the time, it's to have an obvious, uniform way to spell "non-destructively pick an object from a container (set, dict, list, d

[Python-ideas] Re: Argumenting in favor of first()

[Guido] > The argument that first(it) and next(it) "look the same" doesn't convince > me; I'm sorry - I guess then I have absolutely no idea what you were trying to say, and read it completely wrong. > if these look the same then all function applications look the same, and > that can certainly n

[Python-ideas] Re: Argumenting in favor of first()

[Guido] > ... > Similarly, there is already a spelling of first() (or close enough) that > raises: 1-arg next(). > If 1-arg first() would also raise, it would fail the rule "similar things > should be spelled > similarly, and different things should be spelled differently". The "... unless you'r

[Python-ideas] Re: Argumenting in favor of first()

[Steven D'Aprano ] wrote: >>> values = take(count, items, default=None) [MRAB] >> Why is the count first? Why not have the (definitely required) items >> first and let the count have a default of 1? [Steven] > I lifted the bulk of the function, including the signature, from the > recipe in th

[Python-ideas] Re: Argumenting in favor of first()

[Guido] >> def first(it, /, default=None): >> it = iter(it) >> try: >> return next(it) >> except StopIteration: >> return default [Greg Ewing ] > Can you provide any insight into why you think it's better for > it never to raise an exception, as opposed to raising

[Python-ideas] Re: Argumenting in favor of first()

[Steven D'Aprano ] > What do you think of my suggestion that we promote the itertools recipe > "take" into a function? > > https://mail.python.org/archives/list/python-ideas@python.org/message/O5RYM6ZDXEB3OAQT75IADT4YLXE25HTT/ That it's independent of whether `first()` should be added. I would _m

[Python-ideas] Re: Argumenting in favor of first()

[Andrew Barnert ] > Didn’t PyPy already make the fix years ago of rewriting all of itertools > (for both 2.7 and 3.3 or whenever) as “Python builtins” in the underlying > namespace? I don't know. > Also, even if I’m remembering wrong, just writing a Python module in front > of the C module, with

[Python-ideas] Re: Argumenting in favor of first()

[Guido] > ... > I do have to admit that I'm probably biased because I didn't recall 2-arg > next() > myself until it was mentioned in this thread. I knew about it once, but had forgotten all about it too until this thread :-) Which does indeed make the case stronger for adding itertools.first, e

[Python-ideas] Re: Argumenting in favor of first()

[Guido] > We're not changing next(). It's too fundamental to change even subtly. Note that `next()` already accepts two arguments (the second is an optional default in case its iterable argument is exhausted). Like: >>> next(iter([]), 42) 42 > We might add itertools.first(), but not builtins.fi

[Python-ideas] Re: math.copysign not to introduce float

[Guido] > I suspect Tim Peters had a good reason to include copysign() rather than > sign(). Tim wasn't involved in this one :-) But copysign is a "recommended" function in IEEE-754, and was eventually added to the C standard (for libm). So supplying it in `math` was re

[Python-ideas] Re: Set operations with Lists

Note that CPython's sort is in the business of merging sorted (sub)lists. Any mergesort is. But CPython's adapts to take advantage, when possible, of "lumpy" distributions. For example, if you sort list(range(100, 200)) + list(range(0, 100)) it goes very fast (O(N)). Because

[Python-ideas] Re: Set operations with Lists

[Tim] >> Something I haven't seen mentioned here, but I may have missed it: >> when timing algorithms with sets and dicts, people often end up merely >> measuring the bad effects of hardware data cache misses when the >> containers get large, and especially in contrived benchmarks. >> >> In those t

[Python-ideas] Re: Set operations with Lists

BTW, this thread seems a good place to mention the under-appreciated SortedContainers package from Grant Jenks: http://www.grantjenks.com/docs/sortedcontainers/ This supplies sorted containers (lists, dicts, sets) coded in pure Python, which generally run at least as fast as C extensions impl

[Python-ideas] Re: Set operations with Lists

[Richard Higginbotham ] > If you start including the time it takes to convert lists to sets its even > more > pronounced. hash values can collide and the bigger the data set the > more likely it is to happen. That's not so. Python's hash tables dynamically resize so that the load factor never ex

[Python-ideas] Re: Add gamma function to cmath module

to do ;-) On Sun, Sep 8, 2019 at 4:02 PM Guido van Rossum wrote: > > That's a question for Tim Peters. > > On Sun, Sep 8, 2019 at 9:48 PM Andrew Barnert via Python-ideas > wrote: >> >> On Sep 7, 2019, at 18:07, davidgmoril...@gmail.com wrote: >> > >

[Python-ideas] Re: For-expression/throwaway comprehension

[Guido] > ,,, > I learned something in this thread -- I had no idea that the deque datatype > even has an option to limit its size (and silently drop older values as new > ones are added), let alone that the case of setting the size to zero is > optimized in the C code. But more importantly, I don'

Re: [Python-ideas] NAN handling in the statistics module

[David Mertz ] > I think consistent NaN-poisoning would be excellent behavior. It will > always make sense for median (and its variants). > >> >>> statistics.mode([2, 2, nan, nan, nan]) >> nan >> >>> statistics.mode([2, 2, inf - inf, inf - inf, inf - inf]) >> 2 > > > But in the mode case, I'm not

Re: [Python-ideas] NAN handling in the statistics module

I'd like to see internal consistency across the central-tendency statistics in the presence of NaNs. What happens now: mean: the code appears to guarantee that a NaN will be returned if a NaN is in the input. median: as recently detailed, just about anything can happen, depending on how undefi

Re: [Python-ideas] NAN handling in the statistics module

[David Mertz ] > OK, let me be more precise. Obviously if the implementation in a class is: > > class Foo: > def __lt__(self, other): > return random.random() < 0.5 > > Then we aren't going to rely on much. > > * If comparison of any two items in a list (under __lt__) is deterministic,

Re: [Python-ideas] NAN handling in the statistics module

[David Mertz ] > Thanks Tim for clarifying. Is it even the case that sorts are STABLE in > the face of non-total orderings under __lt__? A couple quick examples > don't refute that, but what I tried was not very thorough, nor did I > think much about TimSort itself. I'm not clear on what "stable

Re: [Python-ideas] NAN handling in the statistics module

[David Mertz ] > I have to say though that the existing behavior of > `statistics.median[_low|_high|]` > is SURPRISING if not outright wrong. It is the behavior in existing Python, > but it is very strange. > > The implementation simply does whatever `sorted()` does, which is an > implementation

Re: [Python-ideas] f-string "debug" conversion

[Tim] > > > Note that transforming > > > > {EXPR!d:FMT} > > > > into > > > > EXPR={repr(EXPR):FMT} > > > > is actually slightly more involved than transforming it into > > > > EXPR={EXPR:FMT} > > > > so I don't buy the argument that the original idea is simpler. More > > magical and le

Re: [Python-ideas] f-string "debug" conversion

[Guido] > Gah! You are overthinking it. This idea is only worth it if it's dead > simple, and the version that Eric posted to start this thread, where !d > uses the repr() of the expression, is the only one simple enough to bother > implementing. > In that case, I have no real use for it, for rea

Re: [Python-ideas] f-string "debug" conversion

[Tim] > >> But what if >> > >> {EXPR!d:FMT} > >> > >> acted like the current > >> > >> EXPR={EXPR:FMT} > >> > >> ? I'd find _that_ useful often. For example, when displaying floats, > >> where the repr is almost never what I want to see. > >> ... [Eric V. Smith ] > After giv

Re: [Python-ideas] f-string "debug" conversion

[Eric V. Smith ] > Here’s the idea: for f-strings, we add a !d conversion operator, which > is superficially similar to !s, !r, and !a. The meaning of !d is: > produce the text of the expression (not its value!), followed by an > equal sign, followed by the repr of the value of the expression. ..

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

[Tim] > > > I already made clear that I'm opposed to changing it. > [Terry Reedy ] > To me, this settles the issues. As author, you own the copyright on > your work. The CLA allows revision of contributions, but I don't think > that contributed poetry should be treated the same as code and docs

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

[Tim Delaney ] > "Elegant" is the *only* word I think it would be appropriate to replace > "beautiful" with. > And I can't think of an elegant replacement for "ugly" to pair with > "elegant". "Awkward" would probably be the best I can think of, and > "Elegant is better than awkward" just feels k

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

[Jonathan Fine ] > The first line from "import this" is > > The Zen of Python, by Tim Peters > > I suggest we put this discussion on hold, until Tim Peters (copied) > has had a chance to respond. > > Don't look at me - I was merely channeling Guido

Re: [Python-ideas] Unpacking iterables for augmented assignment

[James Lu] > > Currently, is = = = always equivalent > > to = ; = ; = ? [Stephen J. Turnbull[ > No. It's equivalent to > > = > = > = > > and the order matters because the s may have side effects. This is tricky stuff. In fact the rightmost expression is evaluated once,

  1   2   3   >