[Python-ideas] Re: re.match(pattern, string, require=True)

2023-10-22 Thread David Mertz, Ph.D.
It's hard to overstate how "normal" a non-match is. A typical program might examine thousands of strings to identify the ten that match a pattern. Exceptions shouldn't be used for cases that are in no way exceptional. On Sun, Oct 22, 2023, 7:27 PM Greg Ewing wrote: > On 23/10/23 1:36 am,

[Python-ideas] Re: re.match(pattern, string, require=True)

2023-10-21 Thread David Mertz, Ph.D.
I feel like this is all example of "not every one line function needs to be in the standard library." You can easily write your own 'match_or_raise()'... I guess it would take two lines, actually. On Sat, Oct 21, 2023, 2:42 PM Ram Rachum wrote: > Hey, > > I bet this has been discussed before

[Python-ideas] Re: Conditional 1-line expression in python

2023-07-17 Thread David Mertz, Ph.D.
hours earlier than that announcement was about a talk I gave back then. On Mon, Jul 17, 2023 at 5:23 PM David Mertz, Ph.D. wrote: > This ship has sailed and the ternary operator isn't going to change. > Seriously, let it go. > > I forget the PEP, but this was well discussed l

[Python-ideas] Re: Conditional 1-line expression in python

2023-07-17 Thread David Mertz, Ph.D.
This ship has sailed and the ternary operator isn't going to change. Seriously, let it go. I forget the PEP, but this was well discussed long ago when the ternary was added. In general, Python prefers words to punctuation symbols for most of its constructs. So the decision was consistent with

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

2023-07-10 Thread David Mertz, Ph.D.
This is basically PEP 505 – None-aware operators ( https://peps.python.org/pep-0505/). I've generally been opposed to that, but clearly some serious and smart Pythonistas have supported it. That PEP is a bigger lift than your suggestion, but correspondingly more general. On Mon, Jul 10, 2023,

[Python-ideas] Re: "Curated" package repo?

2023-07-06 Thread David Mertz, Ph.D.
Dom: I'd recommend you simply start a GitHub project for "Curated PyPI", find a catchy domain name, and publish that via GH Pages. That's a few hours of work to get a skeleton. But no, I'm not quite volunteering to create and maintain it myself today. After there is a concrete site existing,

[Python-ideas] Re: "Curated" package repo?

2023-07-05 Thread David Mertz, Ph.D.
I would go a bit further: DAOs are absolutely terrible for EVERYTHING, and anything that remotely mentions the acronym is a scam. Let's please, please, please not go down some cryptoscam, blockchain, rabbit hole here. Drop it, burn the remains, try to forget it ever happened. On Wed, Jul 5,

[Python-ideas] Re: Double "at" operator for matmul exponentiation

2023-07-05 Thread David Mertz, Ph.D.
Every Python idea that has ever been proposed "for the sake of completeness" has been rejected... at least in the 24 years I've been following such closely. Do you have an actual compelling use case? An abstract symmetry isn't going to do it. On Wed, Jul 5, 2023 at 6:17 AM wrote: > > Python

[Python-ideas] Re: Warn when iterating over an already exhausted generator

2023-06-13 Thread David Mertz, Ph.D.
I've also been a Python user for 24 years now. Since long before iterators were a feature of Python. I wrote quite a few widely read articles about iterators when they were introduced, including the first about leverageing iterators for coroutines. I can't say I've NEVER encountered a glitch

[Python-ideas] Re: Undefined type

2023-06-08 Thread David Mertz, Ph.D.
https://peps.python.org/pep-0661/ On Thu, Jun 8, 2023 at 9:58 AM Dom Grigonis wrote: > This has been bugging me for a long time. It seems that python doesn’t > have a convention for “Undefined” type. > > When I started using python I naturally used None for it (as advised). > > However, the

[Python-ideas] Re: `join` method for the `list` class ... `list.join`

2023-06-06 Thread David Mertz, Ph.D.
more_itertools.interleave(*iterables)[source] Return a new iterable yielding from each iterable in turn, until the shortest is exhausted. >>> list(interleave([1, 2, 3], [4, 5], [6, 7, 8])) [1, 4, 6, 2, 5, 7] For a version that doesn’t terminate after the shortest iterable is exhausted, see

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-02 Thread David Mertz, Ph.D.
lowercase letters (and newline as I did it). A more diverse alphabet might tip the timing slightly, but it's going to be a small matter either way. On Fri, Jun 2, 2023 at 7:49 PM Chris Angelico wrote: > > On Sat, 3 Jun 2023 at 09:42, David Mertz, Ph.D. wrote: > > > > Yeah

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-02 Thread David Mertz, Ph.D.
Yeah... oops. Obviously I typed the version in email. Should have done it in the shell. But you got the intention of set-ifying the characters in the large string. Yes on lies, damn lies, and benchmarks. On Fri, Jun 2, 2023, 7:29 PM Chris Angelico wrote: > On Sat, 3 Jun 2023 at 08:28, Da

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-02 Thread David Mertz, Ph.D.
care about one category, then you still have to ask `'Sc' in set(unicodedata.category(set(ch)) for ch in s)`. Which is fine, that's not a hard question to ask. On Fri, Jun 2, 2023 at 5:36 PM Chris Angelico wrote: > > On Sat, 3 Jun 2023 at 07:28, David Mertz, Ph.D. wrote: > > >

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-02 Thread David Mertz, Ph.D.
Sure. That's fine. With a sufficiently long strings my code is faster, but for "typical" strings yours will be. On Fri, Jun 2, 2023, 5:20 PM Chris Angelico wrote: > On Sat, 3 Jun 2023 at 07:08, David Mertz, Ph.D. > wrote: > > > > def does_string_have_currency_mark(s

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-02 Thread David Mertz, Ph.D.
rote: > > On Sat, 3 Jun 2023 at 06:54, David Mertz, Ph.D. wrote: > > > > If we're talking PyPI, it would be nice to have: > > > > unicode_categories = {"Zs": [...], "Ll": [...], ...} > > > > For all the various categories. It w

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-02 Thread David Mertz, Ph.D.
her hand, it's a few lines of code with a lazy import. Probably not enough code to put on PyPI. On Fri, Jun 2, 2023 at 4:32 PM Marc-Andre Lemburg wrote: > > On 01.06.2023 20:06, David Mertz, Ph.D. wrote: > > I guess this is pretty general for the described need: > > > >

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-01 Thread David Mertz, Ph.D.
I guess this is pretty general for the described need: >>> %time unicode_whitespace = [chr(c) for c in range(0x) if >>> unicodedata.category(chr(c)) == "Zs"] CPU times: user 19.2 ms, sys: 0 ns, total: 19.2 ms Wall time: 18.7 ms >>> unicode_whitespace [' ', '\xa0', '\u1680', '\u2000',

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-01 Thread David Mertz, Ph.D.
OK, fair enough. What about "has whitespace (including Unicode beyond ASCII)"? On Thu, Jun 1, 2023 at 1:08 PM Chris Angelico wrote: > > On Fri, 2 Jun 2023 at 02:27, David Mertz, Ph.D. wrote: > > > > It feels to me like "split on whitespace" or "remove

[Python-ideas] Re: Add a .whitespace property to module unicodedata

2023-06-01 Thread David Mertz, Ph.D.
It feels to me like "split on whitespace" or "remove whitespace" are quite common operations. I've been frustrated a number of times by settling for the ASCII whitespace class when I really wanted the Unicode whitespace class. On Thu, Jun 1, 2023 at 12:20 PM Paul Moore wrote: > > On Thu, 1 Jun

[Python-ideas] Re: @lazy decorator an alternative to functools.partial ?

2023-05-17 Thread David Mertz, Ph.D.
On Wed, May 17, 2023 at 2:22 PM Daniel Guffey wrote: > I'm a bit dubious about the pypi suggestion as packages are being > regularly poisoned with malware ( e.g. New KEKW malware infects > open-source Python Wheel files via a PyPI distribution | SC Media > (scmagazine.com) >

[Python-ideas] Re: Make ellipsis an indicator of missing implementation

2023-04-29 Thread David Mertz, Ph.D.
Moreover, I have worked on a lot of code where ellipsis is used to mean "this branch isn't implemented yet, but doing nothing isn't terrible." I don't love that code. I'd rather it use `pass` and a clarifying comment. But this change would make all that existing code much more broken. On Sat,

[Python-ideas] Re: Allowing `str.format` to format one or more parameters instead of all parameters

2023-04-27 Thread David Mertz, Ph.D.
It's actually much worse than making obviously buggy code pass silently. It can also make uncommon bugs almost impossible to detect. Some code looks like `mystring.format(**values)`. Whether values contains the needed keys can vary at runtime now. It might be fine under most code paths, but fail

[Python-ideas] Re: Native support of YAML in Python STDLIB

2023-03-13 Thread David Mertz, Ph.D.
In a similar vein, I'm guessing that if XML were new today, we'd have zero APIs in the standard library to support it... rather than SIX! On Mon, Mar 13, 2023 at 12:23 PM Christopher Barker wrote: > I think the answer is that yaml is a pretty complex specification -- > powerful and flexible,

[Python-ideas] Re: Ampersand operator for strings

2023-03-05 Thread David Mertz, Ph.D.
Is it really that much longer to write `f"{s1} {s2}"` when you want that? Maybe a couple characters more total, but once you are in an f-string, you can also do a zillion other things at the same time. On Sun, Mar 5, 2023 at 10:42 PM Rob Cliffe via Python-ideas < python-ideas@python.org> wrote:

[Python-ideas] Re: Deprecate misleading escapes in strings

2023-02-16 Thread David Mertz, Ph.D.
Wow! That would break SO MUCH of the code I've written! E.g.: translate = {"el": "ἐπιστήμη", "en": "Knowledge", "zh": "知识"} On Thu, Feb 16, 2023 at 9:54 AM Arusekk wrote: > Hi all! > > I was writing a tutorial on the distinction between bytes and strings > and why it is important, when I

[Python-ideas] Re: Idea: Tagged strings in python

2022-12-20 Thread David Mertz, Ph.D.
distinction of post 10th century CE that modern Greek inherited. I feel like `s.upper(locale='koine')` might sensibly account for this. On Wed, Dec 21, 2022, 1:23 AM Chris Angelico wrote: > On Wed, 21 Dec 2022 at 17:20, David Mertz, Ph.D. > wrote: > > > > I'm on my tabl

[Python-ideas] Re: Idea: Tagged strings in python

2022-12-20 Thread David Mertz, Ph.D.
I'm on my tablet, so cannot test at the moment. But is `str.upper()` REALLY wrong about the Turkish dotless I (and dotted capital I) currently?! That feels like a BPO needed if true. On Wed, Dec 21, 2022, 1:04 AM Steven D'Aprano wrote: > On Wed, Dec 21, 2022 at 09:42:51AM +1100, Cameron

[Python-ideas] Re: Idea: Tagged strings in python

2022-12-18 Thread David Mertz, Ph.D.
On Sun, Dec 18, 2022 at 8:29 PM Steven D'Aprano wrote: > > However, if you want to allow these types to possibly *do* something with > > the strings inside (validate them, canonicalize them, do a security > check, > > etc), I think I like the other way: > > class html(str): pass > > class

[Python-ideas] Re: Idea: Tagged strings in python

2022-12-18 Thread David Mertz, Ph.D.
On Sun, Dec 18, 2022 at 5:24 PM Paul Moore wrote: > On Sun, 18 Dec 2022 at 21:42, Christopher Barker > wrote: > >> On Sun, Dec 18, 2022 at 9:48 AM David Mertz, Ph.D. >> wrote: >> >>> In general, I find any proposal to change Python "because then my t

[Python-ideas] Re: Idea: Tagged strings in python

2022-12-18 Thread David Mertz, Ph.D.
Well, obviously I have to come to the defense of vim as well :-). I'm not sure what year vim got the capability, but I suspect around as long as emacs. This isn't for exactly the same language use case, but finding a quick example on the internet: unlet b:current_syntaxsyntax include @srcBash

[Python-ideas] Re: Idea: Tagged strings in python

2022-12-17 Thread David Mertz, Ph.D.
Just to be clear on my opinion. I think Emil's idea was 100% appropriate to share on python-ideas, and he does a good job of showing where it works be useful. Sure, a background search is nice, but not required. That doesn't mean I *support* the idea. I take a very conservative attitude towards

[Python-ideas] Re: Idea: Tagged strings in python

2022-12-17 Thread David Mertz, Ph.D.
On Sat, Dec 17, 2022, 1:03 PM wrote: > > Moreover, there is no reason an editor could not have a capability to > > "colorize any string passed to a function named foo()." Perhaps with > some > > sort of configuration file that indicates which function names correspond > > to which languages,

[Python-ideas] Re: Idea: Tagged strings in python

2022-12-17 Thread David Mertz, Ph.D.
My impression whenever this idea is proposed is like Barry's. The "win" isn't big enough not simply to use named functions. Balancing out the slight "win" is the much larger loss of adding additional complexity to the Python language. New grammar, new parser, possibly new semantics if tagged

[Python-ideas] Re: Better (?) PRNG

2022-12-06 Thread David Mertz, Ph.D.
t especially helpful. But for other purposes, it absolutely is. And yes, most certainly these two techniques could be complementary, they need not be mutually exclusive. On Tue, Dec 6, 2022 at 8:45 PM Matthias Görgens wrote: > On Tue, 15 Nov 2022 at 00:14, David Mertz, Ph.D. > wrote: > >> In g

[Python-ideas] Re: Enhancing variable scope control

2022-12-04 Thread David Mertz, Ph.D.
On Sun, Dec 4, 2022, 2:08 PM Chris Angelico wrote: > You're not the first to try to use globals() for this, but it means that > the context manager works ONLY at top-level. True. I know that. But if you're inside a function, you already have scope containment, so the issue feels like "so

[Python-ideas] Re: Enhancing variable scope control

2022-12-04 Thread David Mertz, Ph.D.
Like most commenters, I think the whole "create an anonymous function then call it" scoping thing is too complex and has too many edge cases to be a good idea. That said, I decided to play around with what I can do to serve the general purpose within existing Python: >>> @contextmanager ... def

[Python-ideas] Re: Enhancing variable scope control

2022-12-01 Thread David Mertz, Ph.D.
I entirely agree with all of Steven's points. I was going to reply with similar comments, but his are precisely spot-on, and probably more detailed than I would have provided. In particular, the Avdi Grimm essay that Steven linked too is one of the main references I would have provided as well.

[Python-ideas] Re: Enhancing variable scope control

2022-12-01 Thread David Mertz, Ph.D.
This is very, very deliberately a design goal of Python. Ruby is a largely similar language that deliberately made the decision you advocate here. It's a good language, but also one in which monkey patching by imported modules creates a huge amount of chaos. Most large Ruby projects have adopted

[Python-ideas] Re: Better (?) PRNG

2022-11-14 Thread David Mertz, Ph.D.
to find, and trying to find your own is certainly going to be less good than that source which `secrets` utilizes. On Mon, Nov 14, 2022 at 11:13 AM David Mertz, Ph.D. wrote: > In concept, what James suggests, is similar to the Random123 library, > written at D.E.Shaw Research by my sadl

[Python-ideas] Re: Better (?) PRNG

2022-11-14 Thread David Mertz, Ph.D.
In concept, what James suggests, is similar to the Random123 library, written at D.E.Shaw Research by my sadly late colleague John Salmon. See https://github.com/DEShawResearch/random123 and the linked academic publications. E.g. https://dl.acm.org/doi/10.1145/2063384.2063405 In general, all

[Python-ideas] Re: Is it possible to provide an official type annotation checker?

2022-10-13 Thread David Mertz, Ph.D.
I happen to give a talk just yesterday that was about pretty much this ( https://github.com/DavidMertz/PythonRuntimeTyping; hopefully PyCon MEA publishes video after a bit). I illustrate checking the same program using mypy, pytype, and pyright. There is a lot of overlap in what they flag as

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

2022-09-01 Thread David Mertz, Ph.D.
On Thu, Sep 1, 2022, 9:12 PM Chris Angelico > > It depends on context whether it makes sense to define a custom > exception, and I agree that I frequently should define a custom exception. > In that case though, it would still be nice to have an appropriate generic > exception for that to inherit

[Python-ideas] Re: Make dataclass aware that it might be used with Enum

2022-07-10 Thread David Mertz, Ph.D.
I've seen this thread, and also wondered why anyone could EVER want a dataclass that is an enum. Nothing I've seen in the thread gives me any hint about that, really. On Sun, Jul 10, 2022 at 7:44 AM Barry Scott wrote: > > > > On 9 Jul 2022, at 22:53, Steve Jorgensen wrote: > > > > I don't

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread David Mertz, Ph.D.
On Fri, Jun 24, 2022 at 10:52 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > We (not sure how much help I'll be, but I'm in) need to deal with > Chris A's point that a pure memoizing object doesn't help with the > mutable defaults problem. That is with > > def

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-24 Thread David Mertz, Ph.D.
On Fri, Jun 24, 2022 at 3:50 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > That's true in David's proposed semantics, where the runtime does that > check. I'm suggesting modified semantics where deferreds can be a > proxy object, whose normal reaction to *any* operation (possibly

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-22 Thread David Mertz, Ph.D.
object but a different concept > in Twisted, I think calling it something else would be better to avoid > confusion. > > Best wishes > Rob Cliffe > > > On 21/06/2022 21:53, David Mertz, Ph.D. wrote: > > Here is a very rough draft of an idea I've floated often, but not with

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-22 Thread David Mertz, Ph.D.
On Wed, Jun 22, 2022 at 2:17 PM Eric V. Smith wrote: > Every time I’ve looked at this, I come back to: other than the clunky > syntax, how is explicit evaluation different from a zero-argument lambda? The difference is in composition of operations. I can write a dozen zero-argument lambdas

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-22 Thread David Mertz, Ph.D.
On Wed, Jun 22, 2022 at 10:47 AM Martin Di Paola wrote: > Hi David, I read the PEP and I think it would be useful to expand the > Motivation and Examples sections. > While indeed Dask uses lazy evaluation to build a complex computation > without executing it, I don't think that it is the whole

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-22 Thread David Mertz, Ph.D.
, they plan and execute the computation differently). > > Would those libs (and probably others) do benefit from the PEP? How? > > Thanks, > Martin. > > On Tue, Jun 21, 2022 at 04:53:44PM -0400, David Mertz, Ph.D. wrote: > >Here is a very rough draft of an idea I've float

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-21 Thread David Mertz, Ph.D.
Thanks Carl and Chris. After reading your comments, and thinking some more about it, I agree you are both correct that it only makes sense to have a DeferredObject act like a closure in the scope of its creation. That really should suffice for anything I could sensibly want; it's enough for

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-21 Thread David Mertz, Ph.D.
I haven't gotten to writing that into the PEP yet, but I think the rule has to be to take the scope of evaluation not the scope of definition. I know it needs to be there, and I'm just thinking about helpful examples. Which is to say the semantics are more like `eval()` than like a lambda

[Python-ideas] Re: Generalized deferred computation in Python

2022-06-21 Thread David Mertz, Ph.D.
On Tue, Jun 21, 2022 at 5:53 PM Brendan Barnwell wrote: > > In the example, we assume that the built-in function `type()` is special > > in not counting as a reference to the binding for purpose of realizing a > > computation. Alternately, some new special function like `isdeferred()` > might be

[Python-ideas] Generalized deferred computation in Python

2022-06-21 Thread David Mertz, Ph.D.
oning them in this thread. PEP: Title: Generalized deferred computation Author: David Mertz Discussions-To: https://mail.python.org/archives/list/python-ideas@python.org/thread/ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 21-Jun-2022 Python-Version: 3.12 Post-History:

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-21 Thread David Mertz, Ph.D.
I will post to a different thread for my actual semi-proposal. But to answer the claim that late-bound arg defaults and late-bound everything-else are unrelated, and to start with an early version of what I'd actually want, I wrote this:

[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating

2022-06-20 Thread David Mertz, Ph.D.
It seems like this is all an occasion to use itertools.tee() ... But with a consciousness that implicit caching uses memory. On Mon, Jun 20, 2022, 11:36 PM Steven D'Aprano wrote: > On Sun, Jun 19, 2022 at 01:34:35AM +0100, Rob Cliffe via Python-ideas > wrote: > > > To me, the natural

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-19 Thread David Mertz, Ph.D.
On Sun, Jun 19, 2022 at 2:24 PM Chris Angelico wrote: > > def frobnicate(data, > verbose=os.environ.get('LEVEL')==loglevel.DEBUG): ... > > Is there any value in not putting that into a global constant? > Probably not. I was just inventing an ad hoc example to show what I meant. I didn't

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-19 Thread David Mertz, Ph.D.
> > > I guess '>=' also looks "confusable", but it's far less common in > signatures, and the meaning is further away. > > It's no less valid than your other examples, nor less common (why > would you have "==" in a function signature, for instance?). > I guess I probably use `==` more often in

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-19 Thread David Mertz, Ph.D.
On Sun, Jun 19, 2022, 12:02 PM Chris Angelico > I've no idea what you mean by "sophistical" here. Please explain? > 1. of or characteristic of sophists or sophistry 2. clever and plausible, but unsound and tending to mislead a sophistical argument 3. using sophistry Plato's dialog _The

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-19 Thread David Mertz, Ph.D.
Mon, 20 Jun 2022 at 00:06, David Mertz, Ph.D. > wrote: > > > > On Sun, Jun 19, 2022, 3:27 AM Chris Angelico > >> > >> > I'm still -1 because I don't think the purpose alone is close to > worth the cost of new syntax... And especially not using sigils that a

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-19 Thread David Mertz, Ph.D.
On Sun, Jun 19, 2022, 3:27 AM Chris Angelico > > I'm still -1 because I don't think the purpose alone is close to worth > the cost of new syntax... And especially not using sigils that are > confusing to read in code. > > > > The topic of "late binding in function signatures" simply isn't >

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-18 Thread David Mertz, Ph.D.
On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe > Sorry again, but IMO discussing any model except one where late-bound > defaults are evaluated at function call time is just adding FUD. > It's definitely rude to repeatedly state that anyone who's opinion is different from yours is "adding FUD" and

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-18 Thread David Mertz, Ph.D.
I think the example that Steven gave, and Stephen approximately repeats is good. def func(items=[], n=later len(items)): items.append("Hello") print(n) func() > I guess Chris will say 0 and David will say 1, but I might be wrong about either of them. This is correct.

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-16 Thread David Mertz, Ph.D.
I've been scolded that I'm not allowed to post unless I support the PEP. Nonetheless, I reiterate that I oppose it. There is no "preponderance" of support, but perhaps a slim majority of the small number who have commented (5 vs 3, I think). On Thu, Jun 16, 2022, 10:38 PM Steve Jorgensen wrote:

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-15 Thread David Mertz, Ph.D.
As well as all the matters Steven raises, I continue to dislike the proposal for the same reason I did on earlier rounds. I believe a general "deferred computation" mechanism is useful, but that one limited to the context of function parameters does more harm than good is scoped narrowly to that

[Python-ideas] Re: Addition to fnmatch.py

2022-06-06 Thread David Mertz, Ph.D.
This is really nice, but I think you have a negation wrong in there somewhere: In [1]: from collections import deque ...: ...: def partition(pred, iterable): ...: results = deque([]), deque([]) ...: ...: def gen_split(only): ...: for thing in iterable: ...:

[Python-ideas] Re: Addition to fnmatch.py

2022-06-06 Thread David Mertz, Ph.D.
As Chris Angelico notes, that's only good for finite iterables. The recipe in the itertools docs is unbounded, but it's also unbounded in the cache needed if you get long strings of things the do (or don't) confirm the predicate. On Mon, Jun 6, 2022 at 7:06 AM Stephen J. Turnbull <

[Python-ideas] Re: Add .except() and .only(), and .values_at(). instance methods to dict

2022-06-05 Thread David Mertz, Ph.D.
These are all far too easy to do with comprehensions to merit new methods or stdlib functions. m = {'a': 123, 'b': 456, 'c': 789} > m.except(('a', 'c')) # {'b': 456} > m.only(('b', 'c')) # {'b': 456, 'c': 789} > m.values_at(('a', 'b')) # [123, 456] > {k:m[v] for k in m if k not in ['a','c']}

[Python-ideas] Re: Addition to fnmatch.py

2022-06-05 Thread David Mertz, Ph.D.
On Sun, Jun 5, 2022, 12:08 PM MRAB wrote: > On 2022-06-05 16:12, David Mertz, Ph.D. wrote: > > This is exactly the problem solved by set difference. E.g. `{a, b, c} > - {a, c}`. > > > > This operation is linear on the size of the removed set. > > > You don't ha

[Python-ideas] Re: Addition to fnmatch.py

2022-06-05 Thread David Mertz, Ph.D.
This is exactly the problem solved by set difference. E.g. `{a, b, c} - {a, c}`. This operation is linear on the size of the removed set. On Sun, Jun 5, 2022, 11:01 AM John Carter wrote: > I’d like to propose a simple addition to the 'fnmatch' module. Specificity > a function that returns a

[Python-ideas] Re: Delete dictionary entry if key exists using -= operator via __isub__()

2022-04-28 Thread David Mertz, Ph.D.
Using `dct -= key` is WAAAYY too cryptic. A method would be okay, but since that is just `dct.pop(key, None)` without the second argument, it's not worth the trouble. -1 On Thu, Apr 28, 2022, 12:03 PM Zach Victor wrote: > Good points, Antoine! > > The intent is to mutate the dictionary with no

[Python-ideas] Re: Conditions for a coherent MI relationship [was Re: Re: mro and super don't feel so pythonic]

2022-04-16 Thread David Mertz, Ph.D.
R has changed a bit since 2005. My article was from then: https://gnosis.cx/publish/programming/R3.html I'm not trying to quibble about R, but simple to point out that what often mystified as "deep" about OOP is actually banal and fairly trivial. That might be how Alan Kay originally saw OOP. He

[Python-ideas] Re: Conditions for a coherent MI relationship [was Re: Re: mro and super don't feel so pythonic]

2022-04-16 Thread David Mertz, Ph.D.
On Sat, Apr 16, 2022, 12:26 PM Chris Angelico > wrote: > A button IS a widget. > A horizontal box IS a box. > A box IS a container. > A container IS a widget. > > Class hierarchies in graphical systems are just as much based on those > is-a relationships as any of those "horrible metaphors" you

[Python-ideas] Re: Conditions for a coherent MI relationship [was Re: Re: mro and super don't feel so pythonic]

2022-04-16 Thread David Mertz, Ph.D.
I don't really care what terms like "Full MI" or "True MI" are intended to mean. Python and MANY other programming languages that allow classes to have multiple parents, use a method resolution order (MRO) to decide which same-named method from a complex inheritance tree to use in a given call.

[Python-ideas] Re: mro and super don't feel so pythonic

2022-04-12 Thread David Mertz, Ph.D.
On Tue, Apr 12, 2022, 4:31 PM Steven D'Aprano > Except the most important one: why are you using multiple inheritence when > you clearly don't want multiple inheritence, instead you want delegation? > I'll note that hundreds of posts ago, I made the FIRST reply to this silliness, and that it

[Python-ideas] Re: mro and super don't feel so pythonic

2022-04-10 Thread David Mertz, Ph.D.
arentheses makes no difference. On Sun, Apr 10, 2022, 1:23 PM malmiteria wrote: > David Mertz, Ph.D. writes: > > Are you likewise "confused" by the fact that `a = b - c` is generally > > different from `a = c - b`?! > > Why do you always quote confused? > &g

[Python-ideas] Re: mro and super don't feel so pythonic

2022-04-10 Thread David Mertz, Ph.D.
On Sun, Apr 10, 2022, 11:51 AM malmiteria > "class A(B)" feels very different from "class B(A)" > but "class A(B,C)" doesn't feel so obviously different from "class A(C,B)" > Are you likewise "confused" by the fact that `a = b - c` is generally different from `a = c - b`?! >

[Python-ideas] Re: mro and super don't feel so pythonic

2022-04-10 Thread David Mertz, Ph.D.
On Sun, Apr 10, 2022, 10:35 AM Steven D'Aprano > I don't believe that David's denials that people are confused by super() > are even a little bit reasonable. I take the words "unconcerned" and "confused" to be distinct. ___ Python-ideas mailing list

[Python-ideas] Re: mro and super don't feel so pythonic

2022-04-09 Thread David Mertz, Ph.D.
On Sat, Apr 9, 2022, 7:31 AM malmiteria wrote: > Joao S. O. Bueno writes: > > You are still repeating this: > > "more in line with the expectation of the majority, " > > Though, as already asked, there is zero (nothing) to support that. > Here's some more evidence of a sort: I've taught

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

2022-04-07 Thread David Mertz, Ph.D.
On Thu, Apr 7, 2022 at 2:47 PM Marc-Andre Lemburg wrote: > In high finance, I've never seen decimals being used, only floats. > Excel is omnipresent, sets the standards and uses IEEE 754 floats > as well (plus some black magic which sometimes helps, but often > makes things worse): > In forex,

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

2022-04-07 Thread David Mertz, Ph.D.
Because the module implements http://speleotrove.com/decimal/decarith.html On Thu, Apr 7, 2022 at 2:03 AM Greg Ewing wrote: > On 7/04/22 9:53 am, Chris Angelico wrote: > > how else would you do variable-precision in the standard library? > > Maybe the mistake was in thinking that we need

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-07 Thread David Mertz, Ph.D.
On Thu, Apr 7, 2022 at 10:51 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > NOTE: The big problem I see with this is that I don't see any > practical way to use syntax for non-numeric types like ndarray. > The problem is that in, say, economics we use a lot of m x 2 >

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread David Mertz, Ph.D.
On Mon, Apr 4, 2022 at 7:45 PM Ethan Furman wrote: > On 4/4/22 13:31, David Mertz, Ph.D. wrote: > > > You should probably change the thread subject to "All-and-only 7 SI > units" if that's what you mean. > > While I'm sure SI would be very useful, I susp

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread David Mertz, Ph.D.
You should probably change the thread subject to "All-and-only 7 SI units" if that's what you mean. On Mon, Apr 4, 2022 at 1:46 PM Brian McCall wrote: > > I drove 20 minutes up the road to by a bushel (US, not British) of U.S. > No. 1. apples, to make apple cider. On my return trip, I stopped

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread David Mertz, Ph.D.
> > Units have infinite precision, so grades and tolerances are also > irrelevant. > Not if you believe in Planck lengths (or quantum states) :-). -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread David Mertz, Ph.D.
Just to elaborate on units I use, here's a hypothetical (not stuff that actually happened today, but very commonplace nature): I drove 20 minutes up the road to by a bushel (US, not British) of U.S. No. > 1. apples, to make apple cider. On my return trip, I stopped at the > hardware store to buy

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread David Mertz, Ph.D.
On Mon, Apr 4, 2022 at 3:53 AM Chris Angelico wrote: > The 160 units would be more likely to have collisions though. Also, > the base and derived SI units will be used with magnitude prefixes, > The supposed 160 are far fewer than I use on a daily (or at least weekly) basis. Yes, all the rest

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-04 Thread David Mertz, Ph.D.
On Mon, Apr 4, 2022, 2:17 AM Brian McCall > For instance, I don't think there would be much uproar if "teaspoons" were left out of any kind of implementation. Apparently someone other than you does the cooking in you household! ___ Python-ideas mailing

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-03 Thread David Mertz, Ph.D.
On Mon, Apr 4, 2022, 12:53 AM Brian McCall > > An electron volt is a unit of energy. Or of mass. Or of momentum. > An electron volt is a unit of energy and only a unit of energy. Knowing a > particle's energy (in certain situations) means that you also know other > physical quantities about that

[Python-ideas] Re: Native support for units [was: custom literals]

2022-04-03 Thread David Mertz, Ph.D.
While units are certainly useful, I think this is FAR too large to add to Python syntax. A library like "units" is great, but it really needs to be a library, and not a small one. There are thousands of units in use in sciences, commerce, engineering, ordinary life, etc. In all of them, it is not

[Python-ideas] Re: mro and super don't feel so pythonic

2022-03-26 Thread David Mertz, Ph.D.
If you want to explicitly delegate a method to a class, you should explicitly delegate a method to a class. This is exactly why a lot of folks feel composition is better than inheritance (at least often so). You don't need `super()` to call `SomeSpecificClass.method(self, other, args)` On Sat,

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

2022-03-18 Thread David Mertz, Ph.D.
Are you speaking of how to generalize modulo to negative numbers (about which programming languages vary)? The bar for adding new syntax to Python is VERY high. Probably easier is getting a function in the `math` module. But even there, you'll need to explain what behavior you want AND why that

[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary

2022-03-17 Thread David Mertz, Ph.D.
I just do this myself in my text editor (vim): [image: sets-py.png] But this is just cosmetic because I like to look at it this way. The actual file on disk contains `set()`, `<=`, `in`, `not in` and wouldn't be a problem for anyone without the same fonts installed, or require anyone to know odd

[Python-ideas] Re: Add a replace method to tuples

2022-03-14 Thread David Mertz, Ph.D.
On Mon, Mar 14, 2022, 7:52 PM Steven D'Aprano > I got "No results matched your query" on the second URL, at which point I > didn't bother with the first. > Hmm... while I don't support the proposal, I saw results at both links. Those links were the first good faith comments I saw from OP. A

[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary

2022-03-14 Thread David Mertz, Ph.D.
On Mon, Mar 14, 2022 at 8:33 AM wrote: > Possible solution: > s = {} # new empty set > d = {:} # new empty dictionary (the ":" is a reference to key-value pairs) > I have suggested over the years—as have probably dozens of other people (maybe thousands)—that that would be a great spelling if

[Python-ideas] Re: Add a replace method to tuples

2022-03-14 Thread David Mertz, Ph.D.
On Fri, Mar 11, 2022, 6:19 PM wfdc wrote: > > Likewise this which you wrote in another post: "Do you see why it's > useful to have immutability?" > > That's not insulting at all. It's a perfectly valid question to address to > a post that seems to be contesting the purpose of immutable types in

[Python-ideas] Re: Add a replace method to tuples

2022-03-11 Thread David Mertz, Ph.D.
e immutability criterion. > > Saying "just be careful not to mutate the original datastructure" isn't a > solution. There's a reason we have immutable types: To *enforce*​ > immutability. Otherwise, why aren't you proposing getting rid of the tuple > type entirely? > &

[Python-ideas] Re: Add a replace method to tuples

2022-03-11 Thread David Mertz, Ph.D.
*​ > immutability. Otherwise, why aren't you proposing getting rid of the tuple > type entirely? > > --- Original Message --- > On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. < > david.me...@gmail.com> wrote: > > On Fri, Mar 11, 2022, 4:16 PM wfdc via

[Python-ideas] Re: Add a replace method to tuples

2022-03-11 Thread David Mertz, Ph.D.
On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas wrote: > > why haven't you used a list > 2. I don't want to modify the original sequence. > There's a really easy solution for you that will even be more perfomant. Use a list and DON'T modify the original! This is ABSOLUTELY an

[Python-ideas] Re: Add a replace method to tuples

2022-03-11 Thread David Mertz, Ph.D.
On Fri, Mar 11, 2022, 2:39 PM wfdc wrote: > > Not every one line function needs to be a method on a built-in type. > > Not every one line function needs to *not* be a method on a built-in type. > See tuple's count method for an example. > Again, if users find themselves re-implementing the same

  1   2   3   4   5   6   7   8   9   10   >