[Python-ideas] Re: re.match(pattern, string, require=True)
Just as a further note, it's perfectly possible to write a helper:
def ensure_match(pattern, string):
m = re.match(pattern, string)
if m is None:
raise ValueError(f"Provided string did not match {pattern}")
return m
If the project is concerned about failures to check the return value of
matches, then using a helper like this seems like a reasonable way of
addressing this (far more effective than living with the problem until a
flag gets added to the stdlib and the project can drop support for older
Python versions...)
If the intention here is simply to "make it easier for people to remember"
in the future, without being tied to any actual real world use case, then I
don't see how adding a (just as easily forgettable) boolean flag is any
significant improvement.
Paul
On Sun, 22 Oct 2023 at 10:19, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Chris Angelico writes:
>
> > Why create a new argument, then mandate that you use it everywhere,
> > just to achieve what's already happening?
>
> "Newbies don't read code backwards very well" seems to be the
> point.
>
> While I'm not of the school that "I learned this painfully, so newbies
> should learn this painfully", I do think that novice Python
> programmers should learn that
>
> 1. "None has no .xxx attribute" means that some previous code (often
> but not always a regex match) was unable to perform some task
> and returned None to indicate failure.
> 2. If the failure was expectable, your code is buggy because it
> didn't test for None, and if it was unexpected, some code
> somewhere is buggy because it allowed an invariant to fail.
>
> On the cost side, there are so many cases where a more finely divided
> Exception hierarchy would help novices quite a bit but experts very
> little that this case (easy to learn) would open the floodgates. I
> believe Guido has specifically advised against such a hierarchy. I'm
> against this change.
>
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MIE4OFPAG5CTNMUR7FYJSX66UMDHIH57/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/UTU4SQNQOJNBNYCW35ZP4OI4XTDKDJEN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: re.match(pattern, string, require=True)
I don't see how it's more likely that people would remember to add a
`require=True` flag than to add `if m: raise RuntimeError("No match")`. The
problem here is people forgetting that a match can fail, not lack of a
means to handle that problem.
Paul
On Sat, 21 Oct 2023 at 11:38, Ram Rachum wrote:
> Hey,
>
> I bet this has been discussed before but I couldn't find it. I'd
> appreciate it if anyone could point me to that thread.
>
> I'm sick of seeing "AttributeError: 'NoneType' object has no attribute
> 'foo'" whenever there's a `re.match` operation that fails while the code
> expects it to succeed. What do you think about a flag `require` such that
> `re.match(pattern, string, require=True)` would either return a match or
> raise an exception with an actually useful message?
>
>
> Thanks,
> Ram.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/PLF46RTMGJUIXRPXPLHZUPLTLGE47TQA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BJ5R5MFLEDZFGKGHPLYBTPQJCCQTF5WZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Mon, 24 Jul 2023 at 10:31, anthony.flury via Python-ideas < python-ideas@python.org> wrote: > In Python then a better way might be > > result = temp := bar() if temp else default > > This way only bar() and default are evaluated and invoked once. > Or result = bar() if not result: result = default Seriously, what is the obsession with putting things on one line here? If it's because "it works better when there is a long list of such assignments" then unless you actually show a real-world example, it's hard to discuss the *actual* trade-offs. And typically with a real-world example, there are a lot more options available (for example, if this is defaulting a series of arguments to a function, it's often an anti-pattern to have a function with that many arguments in the first place, so refactoring the code may be a better option). Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7QE4CV2ZXNWAVFLVPXOYBB224447UFNL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Tue, 18 Jul 2023 at 16:13, Dom Grigonis wrote: > To me, they are in the inverse relationship. > > Terseness ~ 1 / expressiveness. > No, they are unrelated (in general). Terseness is nothing more than "can I use fewer characters?" and is almost always the wrong thing to do in isolation (yes, if things get *yoo* verbose they can be hard to comprehend, but that's about going to extremes, not about terseness as such). Expressiveness is about matching the *concepts* involved to the problem. So list comprehensions are expressive because they declaratively say what the content of the list should be, and avoid the unnecessary concepts around how you build the list. It's irrelevant how many characters are involved, what matters is that you can omit saying "first create an empty list, now add elements like one by one..." Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JMTRAR3HQZL6G7DQHPLSTCGCFFYHFVAA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal for get_or function in Python dictionaries
On Sat, 15 Jul 2023 at 21:09, Dom Grigonis wrote: > So I would vote for something similar to: > > result = bar is None ? default : bar > > result = default if bar is None else bar Python has a conditional expression already. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3BKGZIIIP6HRMR52BXRYRMEPFYKBPRIW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Sun, 9 Jul 2023 at 15:56, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > James Addison via Python-ideas writes: > > > The implementation of such a system could either be centralized or > > distributed; the trust signals that human users infer from it > > should always be distributed. > > ISTM the primary use cases advanced here have been for "naive" users. > Likely they won't be in a position to decide whether they trust Guido > van Rossum or Egg Rando more. So in practice they'll often want to go > with some kind of publicly weighted average of scores. > I'll also point out that I'm a long-standing Python developer, and a core dev, and I still *regularly* get surprised by finding out that community members that I know and respect are maintainers of projects that I had no idea they were associated with. Which suggests that I have no idea how many *other* people who I think of as "just another person" might be maintainers of key, high-profile projects. So I think that a model based round weighting results based on "who you trust" would have some rather unfortunate failure modes. Honestly, I'd be more likely to go with "I can assume that projects that are dependencies of other projects that I already know are good quality, are themselves good quality". Which excludes people from the equation altogether, but which falls apart when I'm looking for a library in a new area. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/N6X7JFHR6U4TEE4YSZPTE2M4OPD6BMMM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sun, 2 Jul 2023 at 06:11, Christopher Barker wrote: > > The OP of this thread is not alone -- folks want an authoritative source > Authority is built over time. Unless someone starts doing this, there will never be any authoritative source. In case it’s not obvious, none of the projects or groups with existing authority have the resource (and/or the interest) to take this on. The best route to leverage existing authority is for someone to start a new project, and then once it has reached a certain level of maturity, apply for PyPA membership. Unfortunately, too much of this discussion is framed as “someone should”, or “it would be good if”. No-one is saying “I will”. Naming groups, like “the PyPA should” doesn’t help either - groups don’t do things, people do. Who in the PyPA? Me? Nope, sorry, I don’t have the time or interest - I’d *use* a curated index, I sure as heck couldn’t *create* one. Paul. > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MOICAMOPFY33ZQ4K46PBYKMIKD6D4ZRW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sat, 1 Jul 2023 at 16:41, MRAB wrote: > How about adding ticks to some PyPI packages? :-) > > (There's still the problem of who gets to decide which ones get a tick...) Precisely. This is just curation but having PyPI host the curators' decisions. And we've already established that the PyPI admins don't have the resources to curate themselves, so it still needs someone to do the job of curating, and now they *also* need to establish trust with the PyPI admins, who don't have the time or knowledge to review the curators' choices. It keeps going round the same circle. The bottleneck is still people. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IWABLGPI5VDUP2VOFZN27ZU3WL4NPXCI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict method to retrieve a key from a value
On Sat, 1 Jul 2023 at 07:09, Christopher Barker wrote: > So I think light curation would help a lot. [*] > I'd be completely in favour of someone setting up a curated package index. You could probably use the Warehouse codebase if you didn't want to write your own. There would probably be a small amount of work to do re-branding. You might also need to write something to put a moderation layer on the upload interface. I'm not familiar with the Warehouse codebase, so I don't know what that would involve. Assuming it gets sufficient popularity, it could apply for PyPA membership if it wanted to be "official" (whatever that means ;-)) The problem isn't so much with the idea, it's with the fact that everyone likes talking about it, but no-one will actually *do* it. And everyone underestimates the amount of work involved - running PyPI, with its bare minimum curation (blocking malware and typosquatting) is a huge effort. Why do people think a new index with ambitions of more curation would take *less* effort? Or do people have the sort of resources that PyPI consumes lying around looking for something to do? Because if so, there's plenty of other projects looking for resources (a PyPI build farm, anyone?) Who said anything about the PSF? > Nobody, I guess, but it's symptomatic of what I said above - everyone assumes *someone else* will do the work, and the convenient "someone else" is usually the PyPA or the PSF. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TNZCP5UKBGOLHHADRJZBVGXK474JKCK4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Thu, 1 Jun 2023 at 18:16, David Mertz, Ph.D.
wrote:
> OK, fair enough. What about "has whitespace (including Unicode beyond
> ASCII)"?
>
>>> import re
>>> r = re.compile(r'\s', re.U)
>>> r.search('ab\u2002cd')
❯ py -m timeit -s "import re; r = re.compile(r'\s', re.U)"
"r.search('ab\u2002cd')"
100 loops, best of 5: 262 nsec per loop
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/Z7CASFLDWL7N2IPB2QPOWDGALNRBCMF4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a .whitespace property to module unicodedata
On Thu, 1 Jun 2023 at 15:09, Antonio Carlos Jorge Patricio < antonio...@gmail.com> wrote: > I suggest including a simple str variable in unicodedata module to mirror > string.whitespace, so it would contain all characters defined in CPython > function [_PyUnicode_IsWhitespace()]( > https://github.com/python/cpython/blob/main/Objects/unicodetype_db.h#L6314) > so that: > > # existent > string.whitespace = ' \t\n\r\x0b\x0c' > > # proposed > unicodedata.whitespace = ' > \t\n\x0b\x0c\r\x1c\x1d\x1e\x1f\x85\xa0\u1680\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u2028\u2029\u202f\u205f\u3000' What's the use case? I can't think of a single occasion when I would have found this useful. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/374AYVMYWOLB2Q3NH3NM6UMEBK6KIFSP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
On Mon, 27 Feb 2023 at 20:58, python--- via Python-ideas > > > The base is not the master branch but the 3.11.0 release. Maybe you should rebase it on main? That will need to happen if it's to be usable, anyway, and it makes it far easier to review/discuss if you follow the normal process for (proposed) PRs. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/C7MANSLR7FRIF6P523A46YL2OHPL42Q3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Combinations of keywords
On Tue, 21 Feb 2023 at 12:44, James Addison via Python-ideas <
python-ideas@python.org> wrote:
> On Mon, 20 Feb 2023 at 15:03, Otomatyk dupont wrote:
> >> #import A_WINDOW_MODULE and import A_UNIX_MODULE if except
>
> Here's an attempt to rephrase this slightly, with the following ideas in
> mind:
>
> * Reduce parser ambiguity
> * Support filtering based on specific exception classes
> * Rephrase the code to read more closely like natural language
>
> >>> try import A_WINDOW_MODULE but import A_UNIX_MODULE on ImportError
>
If you really don't want to have the multi-line try...except, this is
perfectly possible to implement as a function:
# Put this is an "import_utilities" module if you want
def best_import(*names):
for name in names:
try:
return __import__(name)
except ImportError:
continue
A_MODULE = best_import("A_WINDOW_MODULE", "A_UNIX_MODULE")
> >>> try value = int(x[2]) but value = 0 on IndexError, ValueError
>
This is basically "exception handling expressions", which have been
discussed and rejected many times - see https://peps.python.org/pep-0463/.
Personally, I have occasionally wished I could do something like this, but
by the time I've thought a bit harder and found a workaround, I usually end
up thinking that the workaround is *better* than a solution with an
exception handling expression would have been. So although it would be
convenient for quick hacks, I basically support the rejection.
In the case of this specific example, you can obviously wrap the
calculation and exception handling in a function. For a one-off case,
that's not worthwhile, and "toy examples" typically look like one-off
cases. But in real code, you'll either be doing this a lot (and so the
overhead of a function for it is worthwhile) or it will be part of a
function where the exception handling will be encapsulated anyway.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/6JZUNBLQJ4ESPBWNHKGZY3GIC5YNUO67/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Tagged strings in python
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 text >> editor would need to >> change to accommodate the language" to be unconvincing. >> > > Personally, I’m skeptical of any proposal to change Python to make it > easier for IDEs. > > But there *may* be other good reasons to do something like this. I’m not a > static typing guy, but it segg do me that it could be useful to subtype > strings: > > This function expects an SQL string. > > This function returns an SQL string. > > Maybe not worth the overhead, but worth more than giving IDEs hints SATO > what to do. > I believe typing has annotated types that could do this. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/U22UUM7J22IKDQCQTMHW27AISQ2H2YOY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancing variable scope control
On Wed, 30 Nov 2022 at 18:02, Anony Mous wrote: > For instance, a "local:" declaration could be treated as if it were "def > function()" with an immediately succeeding call as far as the interpreter > is concerned. That buys the scoping for (nearly) free. > That would make "return" in the local scope exit the scope, not the enclosing function. Which is almost certainly not what people would expect from a "local scope" statement. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DTPRYE5LROQV6VHBRQFSVRM7SHZ6PGOI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add mechanism to check if a path is a junction (for Windows)
On Tue, 8 Nov 2022 at 23:34, Steven D'Aprano wrote: > > Most Python coders are using Windows. Surely it is time to do better > for them than "just roll your own"? While I frequently advocate on the side of "not every 3-line function needs to be in the stdlib", there are a lot of convenience functions for Unix in the stdlib (reflecting the fact that Python was initially developed on Unix) and having them for Windows as well seems only fair. Given the existence of pathlib.Path.is_fifo(), I think it's reasonable to include is_junction() too. (There's no isfifo() in os.path, though, so the argument for os.path.isjunction() is correspondingly weaker). Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AY6PMBU7DWFO3CB3WXOGF5Y7XEVKQXNU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Is it possible to provide an official type annotation checker？
On Fri, 14 Oct 2022 at 19:36, Christopher Barker wrote: > I’m sorry that my typing-skepticism came across too strong, but while the > tone and language revealed my personal view, I still think the points were > correct. > > Paul: I didn’t say annotations were experimental. I said “static typing” > is — and I really think it still is, though “immature” is a better word. > I don't know that I'd agree with you, but it's not that important, as static typing isn't (and will never be) something provided by (core) Python. > > Better evidence than the multiple implementations is the still unsettled > state of PEP 563 and the number of typing-related PEPs introduced in the > last few Python releases. > Fair. There *is* a lot of change. But "experimental" for me has a more negative implication than simply a rapid pace of change. As I say, it's not that important though. > My point stands: Static type analysis tools are not stable enough at this > point to choose an “official” one. > My point is that we shouldn't *ever* expect to choose an official tool. Diversity is good and there's multiple (not entirely compatible) use cases. It's not the job of the stdlib (or "Python") to pick one library over another. Libraries get to be in the stdlib because the *community* chooses them. And in this case, probably not even then (see below). I guess we may be agreeing here. But I wasn't certain from your comments who you were expecting to do the "choosing" - it felt like you expected the stdlib/core devs to make the call, but if I got that wrong, then fair enough. > But Paul’s point is better- This kind of development tool doesn’t belong > in the stdlib at all — the features that are needed to support static type > checkers do, which is why they have been added (and still are), but not the > tool(s) itself. > > And I’m confused about your point about my directing my typing rants at > the Core devs— this is Python ideas, not Python-dev, and a community member > suggested that Static Type analysis be standardized— how was my response > not directed at the community ? > Your comments that static typing is experimental felt like they were directed at the core devs, and your overall skepticism about typing (some of which I share, to be clear) feels very much like you want *less* type annotation support in the stdlib/core, not that you think what's there is about right and community members need to understand that "in the core" doesn't equate to "mandatory". On the contrary, you give the impression that you *already* feel that typing is being forced on people who don't want it - by the language and the core devs, not by the community. If you'd addressed the suggestion that static type analysis be standardised by saying "Python has a clear policy that type annotations are optional, and checking will never be enforced by the language, so standardising a specific type checker isn't really appropriate" then that would have felt much more clearly directed at the community. But whatever, you're entitled to your opinions, and you're entitled to express them how you wish, so I don't want to dissect your wording and read things into it that you didn't intend. Sorry if I did so. > And your example of PEP 8 is an excellent one: PEP 8 is a style guide for > the standard library itself. But that gives it a perceived endorsement as > an all-Python standard — I’m suggesting that we wouldn’t want to > accidentally provide a similar perceived endorsement of a particular static > type checker. > I'd go further and say that we (by which I mean "the Python community") should work hard to oppose any drift towards the sort of corrosive insistence that everyone "must" follow rules, or use tools, that are intended as guidelines and helpers, which surrounds the whole "PEP 8 compliance" idea. And in particular, we should push back hard on a similar mindset taking hold regarding type annotations. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/URVXZQRKIEAX6NDVEDZZFGQIYEBYGTVB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Is it possible to provide an official type annotation checker？
On Fri, 14 Oct 2022 at 01:41, Christopher Barker wrote: > Static type analysis is still experimental in Python. > It's not. This is simply false. Type *annotations* are a standard part of the language, supported by language syntax, a standard library module, and a series of PEPs describing various features. None of this is any more experimental than, say, context managers. Type *analysis* is not a feature of Python. It's something that's implemented in a number of third party tools, which address different (but all equally legitimate) use cases. It is a deliberate, and repeatedly confirmed, design decision that the core Python language does *not* enforce behaviour based on type annotations. Evidence for this is that there ARE multiple type checkers, and they don’t > all behave the same way. > This is *not* evidence that typing is experimental. It is evidence that a language feature (type annotations) can be used in different ways, depending on the use case. It is, however, evidence that there are multiple use cases here, served by different 3rd party projects, and that suggests that type checking is *not* suitable for inclusion in the standard library. The standard library is a good place for stable code that will change rarely if ever, and which addresses a wide range of use cases. None of which applies to the existing type checking applications. (Also, the standard library is intended for *libraries*, not *applications*...) > It really needs to settle down before there is a single “official” type > checker. > It's not clear that there will *ever* be a situation where only one type checker satisfies everyone. Any more than there's ever likely to be a single web framework. > Also: Static type checking is optional in Python. There are those of us > that are not convinced that static type checking is or should be a Python > best practice. An official type checker would be an endorsement not just of > that particular approach to type checking, but also the concept itself — I > don’t think the community is ready for that. > At this point, I think that repeating this assertion is simply FUD. Yes, using type annotations and a type checker is optional. So is using context managers or decorators. But we don't keep insisting that "not everyone likes decorators, the community isn't ready for them". It *is* true that there is an element in the community that pushes the idea that everything should be type checked. But that's not new. There are people who insist that PEP 8 is mandatory and linters that report PEP 8 violations should be applied to all code. IDEs like VS Code have plugins that run PEP 8 checks on your code and whine at you if you don't "fix" violations. Type checking is in a very similar position. But the response to this is to point out to such zealots that they are *wrong* and that type annotations (and PEP 8) are *tools* to help users, not rules to constrain them. If you want to remind people that not all code needs to be type checked, and that writing a script (or even a big project) with no annotations is perfectly acceptable, then please, do so - I'd completely support that. But at this point, please *stop* directing such reminders at core Python - it's long past the point where it's clear that no-one on the core team is trying to force type checking on users, and it's the *community* that needs educating in this, not the core team. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4HTLMV4UAFSCC3F4FDTBICE4VUVYDM3E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy
What's wrong with defining a custom exception? It's literally one line: `class InvalidStateError(Exception): pass`. Two lines if you want to put the `pass` on its own line. The built in exceptions are ones that are raised by the core interpreter. Even the stdlib doesn't get builtin exceptions, look at sqlite3.Error, for example. Defining a custom exception in the module alongside the function that raises it is both normal practice, and far more discoverable. Paul On Thu, 1 Sept 2022 at 22:42, Steve Jorgensen wrote: > I frequently find that I want to raise an exception when the target of a > call is not in an appropriate state to perform the requested operation. > Rather than choosing between `Exception` or defining a custom exception, it > would be nice if there were a built-in `InvalidStateError` exception that > my code could raise. > > In cases where I want to define a custom exception anyway, I think it > would be nice if it could have a generic `InvalidStateError` exception > class for it to inherit from. > > Of course, I would be open to other ideas for what the name of this > exception should be. Other possibilities off the top of my head are > `BadStateError` or `StateError`. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/NMHNKSEZG7UZ6AIFTVGQXVECCNYYVODT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KIVLJIBG73RLV7AREYVSKSOBC3V43YUR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: range() manipulations
On Mon, 1 Aug 2022 at 13:50, wrote: > Hello everyone. First time here, so please be forgiving of any missteps on > my part. > This is an idea I have thought about for a while, and I believe it could > be quite useful. > Would it be possible to enhance the standard range() type to allow for > elementary operations on ranges? > For example : > range(10) - range(5) => range(5, 10) > range(3, 5, 2) + range(3, 6, 2) => range(3, 6, 2) > There are a lot of complex cases you'd need to consider. What would the value of range(3, 15, 2) + range(8, 12, 2) be? It's not a range in the sense of being describable as (start, end, step). And simply saying "that's not allowed" wouldn't really work, as it would be far too hard to work with if operations could fail unexpectedly like this. In reality, this feels more like you're after set algebra, which Python already has. I believe this could be a fair first step into allowing for a whole range > of mathematical operations in abstract algebra. > For cases where the number of elements in the range is not ridiculously large, simply converting to sets is probably sufficient: >>> set(range(10)) - set(range(5)) == set(range(5, 10)) True >>> set(range(3,5,2)) | set(range(3,6,2)) == set(range(3,6,2)) True For sufficiently large ranges, there are bitset classes on PyPI that might be more memory efficient. Or if you're looking for some other types of operation (unbounded ranges, or specialised abstract algebra operations) a custom class (maybe even published on PyPI) would probably be a better approach than trying to get something that specialised added to the stdlib. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EMDUKIHECPQJETKGYNPJPXT7VV6Y2HCH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Use 'bin' in virtual environments on Windows
On Thu, 21 Jul 2022 at 16:45, Christopher Barker wrote: > I still am dumbfounded that this wasn’t platform I dependent in the first > place, but you know what essay about hindsight. > Indeed. I've no idea why we had the difference in the first place, but that's water under the bridge at this point. > However, I’m no Windows expert, but I *think* the modern Windows file > system(s?) support something like symlinks. It’s an under-the-hood feature, > but maybe it’s possible to add a symlink for bin. > Maybe. But symlinks are not available on all Windows systems (they need certain settings enabled) so we need to be able to work without them (the same is true on Unix, of course, as symlink support requires the filesystem to support it, and not all filesystems do, - but that's not relevant here). The long and short of it is that for a significant amount of time, the *best* we can hope for is something that allows tools to support *both* "Scripts" and "bin". Only after something like that has been in place for an extended period (years) will we have any chance of desupporting environments that use "Scripts". > Maybe I’m wrong, and/or it’s not possible on all file systems Python needs > to support, in which case *nix systems do support linking, so we could > support “Scripts” on all systems. > > Just a thought. > I'd strongly encourage anyone who is still interested in pursuing this to at least work on a proof of concept set of changes, rather than just discussing how it would be better than what we're doing at the moment. This has come up enough times now that anyone involved in packaging is pretty much resigned to us not being able to change this, and we're not likely to do anything just because someone says "this is worth doing". However, it's possible we're so resigned to the current situation that we haven't thought of some approach that will work - and if so, the best way to demonstrate that will certainly be to come with working (or at least partly working) code. If people want to speculate on how a change might be implemented, then please go ahead (this is python-ideas, after all). But without someone willing to write code, that's all it's likely to be, speculation. Sorry. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OJJOPHALJEMJJGGYWANBQZ5SQXAMGKI4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Use 'bin' in virtual environments on Windows
On Thu, 21 Jul 2022 at 11:33, Thomas Grainger wrote:
> > A practical approach may be to develop some form of library that "hides"
> the difference behind some form of API for finding the correct value, get
> that added to the stdlib and wait a few years until it's adopted everywhere
> (because it's so well-designed and convenient ;-)) Then, you can change the
> location.
>
> Is this the canonical location of this information?
>
> https://github.com/python/cpython/blob/3.10/Lib/sysconfig.py#L56
>
In theory, yes. In practice, if that worked, we wouldn't get people asking
about changing this in the first place... Non-Python programs can get the
script location from sysconfig using
py -c "import sysconfig; print(sysconfig.get_path('scripts'))"
But yes, it's likely that sysconfig *is* that API - it's just that for
whatever reason, people haven't adopted it well enough that we can afford
to change the location without breaking things. Which makes this more of a
social problem than a technical one (get people to use sysconfig and the
problem goes away).
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2E7PTTS4JLEIBB7X3UGA4FCTNEADWO7A/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Use 'bin' in virtual environments on Windows
On Thu, 21 Jul 2022 at 11:07, Simão Afonso wrote: > On 2022-07-21 09:55:21, Paul Moore wrote: > > A practical approach may be to develop some form of library that "hides" > > the difference behind some form of API for finding the correct value, get > > that added to the stdlib and wait a few years until it's adopted > everywhere > > (because it's so well-designed and convenient ;-)) Then, you can change > the > > location. But at that point no-one will care, because they don't ever > > reference the actual location, they just use the API anyway :-) > > I think an option when creating the "venv" (something like "--bin-name > bin", or "--use-bin") is enough. Whatever creates the environment also > handles the fact that "bin" is on the "right" location now. > If you don't control the venv creation, you just use the default, > or accept a similar option. > How would that work? Would the value of bin-name be stored somewhere and then all tools would need to refer to that rather than just selecting based on platform like now? You'd still need to change all the tools, or your choice of directory simply wouldn't make any difference... Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/25NVGOC53RXZC4U2KGQELO6FCXRB6EGL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Use 'bin' in virtual environments on Windows
There is a *lot* of code that depends on the Windows directory being "Scripts". There have been proposals in the past to change it (sorry, no links but it has come up a few times on the various packaging forums), but it simply breaks too much for too little gain. If you're serious about wanting this, and the gain to you is sufficient to justify the work, I'd suggest reviewing as many packaging tools as you can find (virtualenv, venv, pip, setuptools, pipenv, pipx, poetry, hatch, pew, as well as core Python in the sysconfig module and distutils would be a good starting point). Work out what changes would be needed to all of these to support using "bin" on Windows, being sure to work out how to handle backward compatibility - people will still have environments that use "Scripts" for many years to come, even if we change everything, and most of the tools I mentioned need to support Python back to at least version 3.7, if not earlier. Even after doing all of that, you'd likely *still* have a huge issue to address, which is all of the various personal and in-house utilities that never get published anywhere, but which either hard code the "if Windows, then Scripts else bin" test, or simply use whichever value is appropriate for the platform they run on (there may be no need for portability anyway). A practical approach may be to develop some form of library that "hides" the difference behind some form of API for finding the correct value, get that added to the stdlib and wait a few years until it's adopted everywhere (because it's so well-designed and convenient ;-)) Then, you can change the location. But at that point no-one will care, because they don't ever reference the actual location, they just use the API anyway :-) Paul On Thu, 21 Jul 2022 at 00:53, Svein Seldal wrote: > > Using py in the three OS-es (unix-like, Mac and Win) has become very > similar in the last years, which is great. Making portable py code has > become very easy. However, there is one peculiarity in Win which I find > annoying: virtual environments insists on placing executables in the > `Scripts` directory, while the other platforms use `bin`. This forces > portable scripts and programs on the outside of py to be OS-aware in > order to interact with a venv on a Win-system vs other systems. > > I would like to proposing the ability to configure virtual environments > to use `bin` directory for executable on Windows. Personally I think it > would be smart move if it were changed to `bin` as default, making all > py platform act consistently. However, I do understand that there might > be existing code out there that depend on using `Scripts`. > > Best regards, > Svein > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/5OFYP734PMXBVIXEW444IU4CPUI7KTIB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AEKSABA5E2JPETRYXN75WKLTZX4DV2DH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adopting better naming conventions (food for thought)
That would break huge amounts of existing code. While better names might have been nice from the start, improving the naming is nowhere near enough benefit to justify such a disruptive change at this point in Python's development. Paul On Fri, 24 Jun 2022 at 22:47, abed...@gmail.com wrote: > > I was reading some of Kevlin Henney's views on naming conventions, and I > realized that, of the 65 classes that make up Python's built-in exceptions, > only 8 (by my count) satisfy Henney's pretty basic concept of a good > Exception name: > > The name should represent whatever the problem is, and should do so directly > and specifically. To add Exception to the end is either redundant — so remove > it — or an indication of a poor name — so rename it. > > Those are: > SystemExit, KeyboardInterrupt, GeneratorExit, Exception, StopIteration, > StopAsyncIteration, Warning, and BaseException (though Henney also > discourages the use of "Base" in a base-class's name) > > I'm sure there are others throughout the standard library too. > > I always caution novice programmers to err on the side of pragmatism over > dogmatic adherence to "sacred truths". To that end: > > 1) I realize changing built-in exception names would break backwards > compatibility and probably isn't worth doing. This post is more intended as > food for thought going forward and to bring more attention to Kevlin Henney's > ideas. > > 2) I think many of the built-in exceptions are actually fine, particularly > ones that represent a broad class of more specific exceptions like OSError. I > don't think OSError has a specific enough name to be raised on its own > (perhaps it should be abstract or otherwise not directly instantiable?), but > catching error categories can be pretty helpful even if they don't lend > themselves to explicit names. > > I would suggest a more ideal naming scheme would be something like the > following: > > BaseException -> Exception > # The text for GeneratorExit seems to indicate that in Python, an Error is > considered a subclass of an Exception, so this naming seems more appropriate > though it contradicts other views on the distinction between Exception and > Error. > > SystemExit > KeyboardInterrupt -> UserInterrupt > #This is supposed to capture a user-initiated exit, whether it came from a > keyboard or a magic wand is generally much less relevant > GeneratorExit > Exception -> Error > > StopIteration > StopAsyncIteration > ArithmeticError > > FloatingPointError -> Not used, get rid of it? > OverflowError -> Overflow > ZeroDivisionError -> ZeroDivision or Undefined > > AssertionError -> Contradiction or AssertionViolation > AttributeError > > + AttributeNotFound or AttributeUnavailable > + AttributeUnassignable > > BufferError > > > > EOFError -> EndOfFile > ImportError > > ModuleNotFoundError -> ModuleNotFound > > LookupError > > IndexError -> IndexOutOfBounds > KeyError -> KeyNotFound > > MemoryError -> OutOfMemory > NameError -> InvalidName (Not needed?) > > UnboundLocalError -> UnboundLocal > > OSError > > BlockingIOError -> BlockingIO > ChildProcessError -> ChildProcessFailed > ConnectionError > > BrokenPipeError -> BrokenPipe > ConnectionAbortedError -> ConnectionAborted > ConnectionRefusedError -> ConnectionRefused > ConnectionResetError -> ConnectionReset > > FileExistsError -> FileAlreadyExists > FileNotFoundError -> FileNotFound > InterruptedError -> Interrupted > IsADirectoryError -> NotAFile > NotADirectoryError -> NotADirectory > PermissionError -> PermissionDenied > ProcessLookupError -> ProcessNotFound > TimeoutError -> Timeout > > ReferenceError -> ReferentCollected? > RuntimeError > > NotImplementedError -> NotImplemented > RecursionError -> MaxRecursionDepthExceeded or RecursionOverflow > > SyntaxError > > IndentationError > > TabError -> InconsistentIndentation > > SystemError -> SystemFailure > TypeError -> IncompatibleType > ValueError > > UnicodeError > > UnicodeDecodeError > UnicodeEncodeError > UnicodeTranslateError > > Warning > # Should this be under Error? > > DeprecationWarning -> Deprecated > PendingDeprecationWarning -> Obsolete > RuntimeWarning > SyntaxWarning > UserWarning > FutureWarning > ImportWarning > UnicodeWarning > BytesWarning > EncodingWarning > ResourceWarning > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/DRF6EMT3QFPBVTS3S76EEMKHJDCHUHVQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at
[Python-ideas] Re: Generalized deferred computation in Python
On Wed, 22 Jun 2022 at 22:52, Martin Di Paola wrote: > Perhaps this is the real focus to analyze. The PEP suggests that > x.compute() does something *fundamentally* different from just executing > the intermediate expressions. Hang on, did the PEP change? The version I saw didn't have a compute() method, deferred objects were just evaluated when they were referenced. There's a *huge* difference (in my opinion) between auto-executing deferred expressions, and a syntax for creating *objects* that can be asked to calculate their value. And yes, the latter is extremely close to being nothing more than "a shorter and more composable form of zero-arg lambda", so it needs to be justifiable in comparison to zero-arg lambda (which is why I'm more interested in the composability aspect, building an AST by combining delayed expressions into larger ones). Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P2LAQMQUM3KBXNH6EE5XBON4BLNTS7UR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Generalized deferred computation in Python
On Wed, 22 Jun 2022 at 18:35, David Mertz, Ph.D. wrote: > > Hi Martin, > > Short answer: yes, I agree. > Slightly longer: I would be eternally grateful if you wish to contribute to > the PEP with any such expansion of the Motivation and Expansion. One concern I have, triggered by Martin's Dask, PySpark and Django examples, is that we've seen proposals in the past for "deferred expression" objects that capture an unevaluated expression, and make its AST available for user code to manipulate. The three examples here could all use such a feature, as could other ORMs (and I'm sure there are other use cases). This is in contrast to your proposal, which doesn't seem to help those use cases (if it does, I'd like to understand how). The key distinction seems to be that with your proposal, evaluation is "on reference" and unavoidable, whereas in the other proposals I've seen, evaluation happens on demand (and as a result, it's also possible to work with the expression AST *before* evaluation). My concern is that we're unlikely to be able to justify *two* forms of "deferred expression" construct in Python, and your proposal, by requiring transparent evaluation on reference, would preclude any processing (such as optimisation, name injection, or other forms of AST manipulation) of the expression before evaluation. I suspect that you consider evaluation-on-reference as an important feature of your proposal, but could you consider explicit evaluation as an alternative? Or at the very least address in the PEP the fact that this would close the door on future explicit evaluation models? Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GDMURWK3M4WOQVGEMWFY33ZBRSKQMGYX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Tue, 21 Jun 2022 at 10:01, Paul Moore wrote: > PS To be clear, my objections to the PEP aren't based on deferred > evaluation. So I'm an impartial 3rd party on this matter. I *do* have > problems with the PEP, so I have an interest in seeing the PEP fairly > reflect the lack of consensus, and accurately represent the concerns > people are raising, but I don't have a preference for any specific > outcome in the matter of deferred evaluation. Thinking some more about this, my comments are pretty much what I'd be saying if I were a sponsor for this PEP. I don't think a PEP sponsor should be someone who doesn't agree with the PEP, otherwise I'd offer to take on the role (assuming you need a sponsor). But please take my comments in that vein. (And if you do ever manage to convert me to support of the PEP, remind me of this comment and I'll be the sponsor ;-)) Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LLEEOLPQTM5INNXRIIT6UVN3TEJLQIZD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Tue, 21 Jun 2022 at 09:20, Chris Angelico wrote: > > On Tue, 21 Jun 2022 at 18:15, Paul Moore wrote: > > I'm not talking about a "full and detailed specification". That's > > *still* more than is needed for a valid debate (at this point). But > > what *is* needed is a more complete explanation of how deferred > > evaluation would work, and some plausible (not set in stone, just > > plausible) syntax. With that, it would be possible to write down two > > versions of the same code and judge between them. We've not yet had a > > sufficiently clear (IMO) definition of the semantics of deferred > > evaluation yet (or if we have, it's been lost in the arguments), and > > it would help a lot if someone could provide one. I'm thinking > > specifically about the rules for variable capture, scoping, > > interaction with assignment expressions in terms of introducing names, > > etc., as well as how evaluation is "triggered" and what ability there > > is to explicitly say "evaluate this now". > > > > That's what I mean by a full specification. Even without code, that > would be enough to start talking about it. But those arguing "don't go > for lazy evaluation, go for deferreds" don't seem to want to actually > push that proposal forward. > > That's why I call it vapourware. OK, so maybe if you were a little less aggressive in your replies, we could see if anyone wants to respond. But frankly, I imagine it's hard to muster up any enthusiasm for writing up the semantics unless you're willing to show some sign that you might modify the PEP as a result. I'm not talking about rewriting your PEP to be a "deferred evaluation" PEP, but simply to modify it to make it more compatible with the future that the "deferred evaluation" people imagine. On the other hand, if the "deferred evaluation" supporters genuinely have nothing to offer other than "we don't want this PEP *at all* because what we have right now is sufficient in the short term, and longer term maybe something else (deferred evaluation being the possibility we can think of right now) will provide a different solution" then that's also OK. It's just a -1 vote, and should be recorded in the PEP as such - "A number of contributors on python-ideas were against this proposal because they didn't believe it offered enough benefit over the status quo, and they preferred to wait for a more general solution such as deferred evaluation (on the basis of the Zen "never is often better than right now")". That can still go in the "rejected ideas" section, under a heading of "Do Nothing". But unless we can reduce the level of conflict here, we're never going to know which alternative the deferred evaluation supporters want, and it won't be possible to accurately represent their views in the PEP. Which is bad for them (as they'll feel ignored) and for you (as your PEP won't fairly represent the views of the people who contributed to the discussion). Paul PS To be clear, my objections to the PEP aren't based on deferred evaluation. So I'm an impartial 3rd party on this matter. I *do* have problems with the PEP, so I have an interest in seeing the PEP fairly reflect the lack of consensus, and accurately represent the concerns people are raising, but I don't have a preference for any specific outcome in the matter of deferred evaluation. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PLQRTPEVRNU5VGVCRXDUV3ERSFX37RLF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Tue, 21 Jun 2022 at 06:27, Chris Angelico wrote: > > Okay, here's a compromise. > > Go and write a full and detailed specification of the Python-visible > semantics of deferred evaluation objects, including how they would be > used to implement late-bound argument defaults. I'm going to ignore all the rhetoric here, as it's not helpful. I understand that you're frustrated, and that you feel like you're not getting your point across. Part of that (IMO) is *because* you're getting too frustrated, and so not explaining your point well. This is a case in point. Deferred evaluation doesn't need to be implemented to be a valid counter-proposal. Your repeated demands that someone produce an implementation are a distraction, allowing people to argue that you're wrong on that point, while ignoring the more important point. Which is that we don't really have a definition of how deferred evaluation would work. I'm not talking about a "full and detailed specification". That's *still* more than is needed for a valid debate (at this point). But what *is* needed is a more complete explanation of how deferred evaluation would work, and some plausible (not set in stone, just plausible) syntax. With that, it would be possible to write down two versions of the same code and judge between them. We've not yet had a sufficiently clear (IMO) definition of the semantics of deferred evaluation yet (or if we have, it's been lost in the arguments), and it would help a lot if someone could provide one. I'm thinking specifically about the rules for variable capture, scoping, interaction with assignment expressions in terms of introducing names, etc., as well as how evaluation is "triggered" and what ability there is to explicitly say "evaluate this now". > Go and actually do some real work on your pet feature, instead of > using the vapourware to try to shut down the one I've been working on. This is rhetoric again. Asking for more concrete examples of the proposed alternative is reasonable. Getting frustrated when they are not provided is understandable, but doesn't help. Calling the proposed alternative "vapourware" just doubles down on the uncompromising "implement it or I'll ignore you" stance. And replying with increasingly frustrated posts that end up at a point where people like me can't even work out how we'd go looking to see whether anyone *had* provided concrete examples of deferred evaluation just makes things worse. All of which could have been avoided by simply including an early argument posted here in the PEP, under rejected alternatives, with a link to the post and a statement that "this was proposed as an alternative, but there's not enough detail provided to confirm how it would replace the existing proposal". Then anyone who disagrees has a clear understanding of what you want, and how to provide it. > Once again, you're getting very very close to being killfiled. This whole discussion is close to that point for me. But believe it or not, I still have a vague hope that the proposal can be strengthened by people working together, rather than just ending up with a "this is what I think, take it or leave it" PEP. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LZJF4P77YCTX5TM7JJ4VW64JD4DDTBN2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bare wildcard in de-structuring to ignore remainder and stop iterating (restart)
On Mon, 20 Jun 2022 at 18:42, Steve Jorgensen wrote: > > Steven D'Aprano wrote: > > Okay, I'm convinced. > > If we need this feature (and I'm not convinced about that part), then it > > makes sense to keep the star and write it as `spam, eggs, *... = items`. > > I thought about that, but to me, there are several reasons to not do that and > to have the ellipsis mean multiple rather than prepending * for that: > 1. In common usage outside of programming, the ellipsis means a continuation > and not just a single additional thing. > 2. Having `*...` mean any number of things implies that `...` means a single > thing, and I don't think there is a reason to match 1 thing but not assign it > to a variable. It is also already fine to repeat `_` in the left side > expression. > 3. I am guessing (though I could be wrong) that support for `*...` would be a > bigger change and more complicated in the Python source code. Also, while I can't speak for others, I found that when writing examples for posts here, the "*" in "*..." has too strong of a connection with "consume", and I *still* naturally read *... as "consume the rest" (even though it's not currently valid syntax, and the rules for what it *does* mean would be clear and unambiguous, etc etc). So for me at least, any syntax that uses a * would be too easy to misread. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EMZZUSIJYNGV4KM75MF66UPHF3K6DOH7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bare wildcard in de-structuring to ignore remainder and stop iterating (restart)
On Mon, 20 Jun 2022 at 11:08, Steven D'Aprano wrote: > But that's basically islice. So: > > # Its okay to put reusable helper functions in a module. > # Not everything has to be syntax. > first, second, third = itertools.islice(items, 3) > > I think that we have a working solution for this problem; the only > argument is whether or not that problem is common enough, or special > enough, or the solution clunky enough, to justify a syntax solution. I think there's a lot of people (I'm not one of them) who prefer working with syntax rather than functions for "basic operations". Of course, what's "basic" is up for debate, but Lucas Wiman commented earlier "I tend to like syntax over methods for handling basic data types", and while I don't necessarily agree, I can see how people gravitate towards asking for syntax when built in data types are involved. In this case, there's also the need to explicitly state the count, which can be inferred from the LHS when using syntax, but not in a function call. And the (perceived or real?) performance issue with "function calls are slow". Ultimately, this type of proposal is mostly decided by a judgement on "what do we want the language to look like", which attracts subjective comments like "Python isn't Perl", or "it's a natural extension of existing syntax", or "it's more readable". But no-one here has the authority to declare what is or is not "Pythonic" - that authority is with the steering council. So we do our best to reach some sort of group consensus, and dump the hard questions on the SC (via a PEP). My sense is that a lot more people are coming to Python these days with an expectation that syntax-based solutions are OK, and the "old guard" (like myself!) are pushing more for the "not everything has to be syntax" arguments. Maybe I'm not sufficiently self-aware, and when I was newer to Python I too liked the idea of adding syntax more. I honestly can't remember (I did love list comprehensions when they were added, so I clearly wasn't always against syntax!). But I do think that the broad question of "should Python have more complex syntax" is probably a more fundamental debate that we won't resolve here. For the record, I think the islice solution is sufficient for this case. But I have needed this sort of thing occasionally, and islice didn't immediately come to mind - so I have sympathy with the discoverability argument. If a syntax like "a, b, *... = some_iterator" existed, I suspect I'd use it. But picking a syntax that *didn't* mislead me into assuming the iterator was fully consumed would be hard - I thought *... was OK, but writing it just now I realised I had to remind myself that it didn't consume everything, to the point where I'd probably add a comment if I was writing the code. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MQDFG66K4FA3TBOQ32N2WESYGLGXXQTN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a line_offsets() method to str
On Sat, 18 Jun 2022 at 23:15, Eric V. Smith via Python-ideas wrote: > > On 6/18/2022 5:34 PM, Paul Moore wrote: > > After all, it has the > > advantage of working on older versions of Python (and given that one > > of your use cases is Textual, I can't imagine anyone would be happy if > > that required Python 2.12+...) > > Guido's "no 2.8" shirt apparently didn't stop 2.9 through 2.11! Sigh. I *thought* something looked wrong with that, but I assumed I was still getting used to the 2-digit minor version. Time to go to bed, I think... Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UWOETTHZ6BQU5OKB3DYVXWU3S365WYYT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a line_offsets() method to str
On Sat, 18 Jun 2022 at 21:57, Jonathan Slenders wrote: > > Good catch! One correction here, I somewhat mixed up the benchmarks. I forgot > both projects of mine required support for universal line endings exactly > like splitlines() does this out of the box. That requires a more complex > regex pattern. I was actually using: > re.compile(r"\n|\r(?!\n)") > And then the regex becomes significantly slower than the splitlines() > solution, which is still much slower than it has to be. > > This makes me realize that `str.indexes(char)` is actually not what I need, > but really a `str.line_offsets()` which returns exactly the positions that > `str.splitlines()` would use. Does that make sense? > > If this is reasonable, I wouldn't mind working on the implementation. At this point, I'm inclined to say that this is too specialised to be a string method, and it might be better as a 3rd party utility. I imagine there are problems with that, not least the issue of having to depend on a compiled extension that may not be available on all platforms. But as an *optional* dependency (with a fallback to the current splitlines approach) is it really such a problem? Sorry to be the one who's always suggesting this, but I'm genuinely interested in why a 3rd party solution isn't sufficient. After all, it has the advantage of working on older versions of Python (and given that one of your use cases is Textual, I can't imagine anyone would be happy if that required Python 2.12+...) If the proposal had still been for a general str.indexes(char), I might have thought differently (although given that re is fast when searching for a single character, that may not be worthwhile either). Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/N2WF3WCZKIMP5XVKTSISW2ZEG5I2KLMS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sat, 18 Jun 2022 at 15:53, Stephen J. Turnbull wrote: > I don't find that burdensome enough to want syntax, and I can't guess > how quickly I'd start using it if available, that probably depends on > how often the community seems to be using it (ie, in the code I'm > reading). To be honest, I think this is the real flaw with the proposal. It's somewhat attractive in theory, adding a short form for something which people do tend to write out "longhand" at the moment. But the saving is relatively small, and there are a number of vaguely annoying edge cases that probably don't come up often, but overall just push the proposal into the "annoyingly complicated" area. The net result is that we get something that *might* help with a minor annoyance, but the cost in (theoretical, but necessary) complexity is just a bit too high. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7WX3AAR7T3MR2NI7JFY3SJKWK4QIFGN5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sat, 18 Jun 2022 at 03:45, Chris Angelico wrote:
> > This raises another choice: should lazy defaults be evaluated before
> > entering the body of the function, or at the point where the parameter
> > is used? Which would be more useful?
> >
> > # `defer n=len(items)`
> > def func(items=[], n=>len(items)):
> > items.append("Hello")
> > print(n)
> >
> > func()
>
> That's one of the problems. Generic lazy evaluation should be
> processed at some point where the parameter is used, but late-bound
> defaults are evaluated as the function begins. They are orthogonal.
That sounds like an *extremely* good statement to make in the
"Rejected suggestions" section of the PEP, explaining why the PEP's
proposal and a "lazy evaluation" proposal are different.
> At what point is an unrelated proposal a "rejected idea"? How
> different does it have to be before it doesn't help to have it in that
> section?
At the point where people repeatedly offer it as an alternative to the
PEP. If it's so unrelated as to make no sense at all, just add it as
"XXX: rejected as it solves a different problem" or similar. But your
response above is better for the lazy evaluation suggestion, and
explains why you think it's unrelated.
> You're welcome to keep on arguing for the sake of arguing, but you're
> not actually accomplishing anything by it. Especially since you're
> rehashing the exact same complaints that you raised previously, and
> which I responded, exactly the same way, at the time.
*Everyone* is just rehashing the same comments by this point. People
are piling in because of a fear that if they don't, someone will claim
that we now have consensus, not because they have anything new to add.
IIRC, someone early in this thread even said something along the lines
of "we seem to be reaching a consensus", but I can't find the
reference now.
I'd suggest that Chris either mark the PEP as withdrawn, to make it
explicit that he has no plans to submit it, or submit it to the SC
(ideally with a note for transparency saying that there was no
consensus on python-ideas). Nobody is really benefiting from repeating
this discussion over and over.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VJ26QUYGPOB6NED4NYGCKTOHAWZ7YPS3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Fri, 17 Jun 2022 at 15:55, Chris Angelico wrote: > > On Sat, 18 Jun 2022 at 00:21, Paul Moore wrote: > > > > On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote: > > > > > > There are several ways to make this clearly sane. > > > > > > # Clearly UnboundLocalError > > > def frob(n=>len(items), items=>[]): > > > > Um, I didn't see that as any more obvious than the original example. I > > guess I can see it's UnboundLocalError, but honestly that's not > > obvious to me. > > Question: Is this obvious? > > def f(): > x, x[0] = [2], 3 > print(x) > > def boom(): > x[0], x = 3, [2] > # raises UnboundLocalError No. I'm not sure what point you're trying to make here? > I understand that left-to-right evaluation is something that has to be > learned (and isn't 100% true - operator precedence is a thing too), > but at very least, if it isn't *obvious*, it should at least be > *unsurprising* if you then get UnboundLocalError. Why? Are you saying I can't be surprised by the details of rules that I don't often have a need to understand in detail? I fear we're getting off-topic here, though. I'm not arguing that anything here isn't well-defined, just that it's not obvious *to me*. And I'm not even "arguing" that, I'm simply stating it as an observed fact about how I initially reacted to the quoted example. It's you who is stating that the frob case is "clearly" UnboundLocalError, and all I'm saying is that's not "clear" to me, even if it is a consequence of the rules in the PEP. And actually, I could argue that the PEP would benefit from some clarification to make that consequence clearer - but I don't feel that you're likely to be particularly receptive to that statement. In case you are, consider that as written, the PEP says that the *defaults* are evaluated left to right in the function's runtime scope, but it doesn't say when the parameter names are introduced in that scope - prior to this PEP there was no need to define that detail, as nothing could happen before the names were introduced at the start of the scope. If you accept that clarification, can you accept that the current text isn't as clear as it might be? > > > # Clearly correct behaviour > > > def frob(items=[], n=>len(items)): > > > def frob(items=>[], n=>len(items)): > > > > Maybe... I'm not sure I see this as *that* much more obvious, although > > I concede that the left-to-right evaluation rule implies it (it feels > > like a mathematician's use of "obvious" - which quite often isn't ;-)) > > Using assignment expressions in argument defaults is well-defined but > > not necessarily obvious in a similar way (to me, at least). > > When you say "assignment expressions", do you mean "default > expressions", or are you referring to the walrus operator? There's a > lot of other potentially-surprising behaviour if you mix assignment > expressions in with this, because of the difference of scope. It's the > sort of thing that can definitely be figured out, but I would advise > against it. I meant the walrus operator, and that's my point. There's a lot of not-immediately-obvious interactions here. Even if we don't include default expressions, I'd argue that the behaviour is non-obvious: >>> def f(a=(b:=12)): ... print(a, b) ... >>> f() 12 12 >>> b 12 I assume (possibly naïvely) that this is defined in the language spec, though, as it's existing behaviour. But when you add in default expressions, you need to be sure that the various interactions are well-defined. Note that at this point, I'm not even talking about "obvious", simply the bare minimum of "if I write this supposedly legal code, does the PEP explain what it does?" > def frob(items=>[], n=>len(items:=[])): > > This will reassign items to be an empty list if n is omitted. > Obviously that's bad code, but in general, I think assignment > expressions inside default expressions are likely to be very > surprising :) Agreed. Although consider the following: >>> def f(a=(b:=12), b=9): ... print(a, b) ... >>> f() 12 9 >>> b 12 Would def frob(n=>len(items:=[]), items=>[1,2]): ... reassign items if n is omitted? Or would it assign the *global* items and then shadow it with a local for the parameter? Can you point to the explanation in the PEP that covers this? And even if you can, are you trying to claim that the behaviour is "obvious"? > Then let's leave aside the term "obvious" and just go for > "unsurprising". If you write code and get UnboundLocalError, will you > be surprised that it doesn't work? If you write code and it
[Python-ideas] Re: Type checking for **kwargs based on its use
On Fri, 17 Jun 2022 at 14:19, Mauricio Villegas via Python-ideas wrote: > > Look at the following example: > > ``` > def some_function(f1: int): > assert isinstance(f1, int) > > def other_function(f0: str, **kwargs): > assert isinstance(f0, str) > some_function(**kwargs) > > other_function(f0='a', f1='b') > ``` > > I would expect a static type checker to warn that f1='b' is wrong because the > type should be int. There shouldn't be a need to add a type to **kwargs since > what is accepted can be deduced from how it is used. Note that some_function > could be defined in another module and be used in multiple places, thus the > "don't repeat yourself" and "separation of concerns" principles apply. Better > to have the type for f1 be only in the definition of some_function and not in > the **kwargs. > > I created a github issue in pyright > (https://github.com/microsoft/pyright/issues/3583) and the response was that > PEP 484 forbids this. I have seen that there are discussions about TypedDict > for more precise typing of **kwargs. However, requiring to use TypedDict for > the cases in which it is possible to derive what **kwargs accepts based on > its use, seems over-complicating things, which is yet another principle "keep > it simple, stupid". The problem here is that type checkers are *required* to not check unannotated types (by PEP 484, as the pyright maintainers pointed out). That's fundamental to the idea of "gradual typing" and can't be changed without impacting anyone who doesn't fully annotate their code (and many such people exist - not everyone is willing to embrace type checking 100%). The SC have publicly stated that type annotations will remain optional. What you *could* do, I guess, is propose a new annotation that says "allow any type, but do type inference". I don't know whether type checkers have the ability to statically infer the sort of constraint you're suggesting here, but that's a question for the implementers of those checkers, and not a language matter. As a thought, maybe an existing type would work: def other_function(f0: str, **kwargs: dict): or def other_function(f0: str, **kwargs: object): Those don't constrain kwargs beyond what the language mandates, and you don't need to know about how kwargs is used to add them. But if a type checker *can* infer a tighter constraint based on analysis of how kwargs is used in the rest of the program, then presumably it will. Have you tried that? > I would think that it wouldn't be too problematic to have a PEP stating that > static type checkers when **kwargs has not type annotation are allowed to > analyze the source code to identify what **kwargs accepts. I would even say > that when **kwargs has a type, checkers are allowed to analyze how it is > used. Also that the type annotation for **kwargs be not necessary if it is > possible to deduce what it accepts. Anyway, I am just giving out this idea to > see what happens. It would be problematic to have such a PEP, as I've said - it contradicts the guarantee that type checking is optional. But as Alex Waygood said, this is better raised on the typing SIG, as that's where the typing experts hang out (they don't, to my knowledge, read python-ideas at all). Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IMR5PL7HDRE5BFFOGQK7DHSJVYRKJU2M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
>
> There are several ways to make this clearly sane.
>
> # Clearly UnboundLocalError
> def frob(n=>len(items), items=>[]):
Um, I didn't see that as any more obvious than the original example. I
guess I can see it's UnboundLocalError, but honestly that's not
obvious to me.
> # Clearly correct behaviour
> def frob(items=[], n=>len(items)):
> def frob(items=>[], n=>len(items)):
Maybe... I'm not sure I see this as *that* much more obvious, although
I concede that the left-to-right evaluation rule implies it (it feels
like a mathematician's use of "obvious" - which quite often isn't ;-))
Using assignment expressions in argument defaults is well-defined but
not necessarily obvious in a similar way (to me, at least).
> The only way for it to be confusing is to have => on one argument and
> then = on a subsequent argument, *and* to have the earlier one refer
> to the later one.
For you, maybe. I assert that the forms above *are* confusing for me.
You're welcome to explain them to me, like you have, and maybe I'll
now remember the logic for the future, but as a data point, I stand by
my statement that these were confusing to me when I encountered them
fresh. Feel free to state that there's not *enough* cases of people
being confused by the semantics to outweigh the benefits, but it feels
to me that there are a few people claiming confusion here, and simply
saying "you shouldn't be confused, it's obvious" isn't really
addressing the point.
> > Even if someone *can* provide an answer, I'd be reluctant to accept
> > that any answer could be described as "intuitive". And "well, don't do
> > that" is just ducking the question - in essentially the same way as
> > "it's implementation defined" does...
>
> But "don't do that" is a perfectly reasonable response to other kinds
> of bad code, like messing up your spacing:
>
> x = 1+2 * 3+4
>
> Is this intuitive? Some people will think that x should be 21, but the
> actual answer is 11. Python won't stop you from doing this, but style
> guides absolutely should.
But that's not the same as you leaving the behaviour implementation
defined. In the case of operator precedence, there *is* a well-defined
answer, but the spacing doesn't match that interpretation. But in the
case of
frob(n=>len(items), items=())
you're refusing to give a well-defined semantics, and then saying that
people shouldn't do that. But unlike spacing of expressions, the order
of arguments is *important* - it is part of the API of frob that the
first positional argument is n, so "just swap the arguments" is a
semantic change. So how should people get the ("obvious") intended
behaviour? Abandon the new syntax and go back to using None as a
default? That seems a shame, given that (as I understand it) your
reference implementation works exactly as I'd want.
> In the same way, I would strongly recommend that style guides frown
> upon referring to arguments later in the parameter list, even if it
> happens to be legal. I'm just not mandating that the language check
> for this and artificially block it.
You're not *just* recommending this for style guides, you're also
explicitly stating that you refuse to assign semantics to it.
Anyway, all of this is just my opinion. I'm not trying to persuade you
that you're wrong, just to point out that others see things
differently. It's up to you what you do with that information. Change
the PEP or don't, put it back into deferred status or submit it. I'm
not the decision maker here, just a community member whose feedback
will (hopefully) be considered by the SC when making the decision if
the PEP comes to them.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VGXSX6GDV46J7JUVOWHZPL2CO6SZYUER/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Fri, 17 Jun 2022 at 13:54, Andrew Jaffe wrote: > > Is there a *reason* why you are leaving this unspecified? To put it more > baldly, is there any reason (e.g., difficulty of parsing?) why allowing > these "forward" references should *not* be allowed? It seems that > "n=>len(items), items=[]" might be an important use case. Am I right in thinking the key issue here is that => is *not* used for "items"? So def frob(n=>len(items), items=[]): print(n) items.append(1) gets very complicated to reason about. What does this print? frob() frob() frob(items=[1,2,3,4,5]) frob(3, []) frob() frob(3) frob() Even if someone *can* provide an answer, I'd be reluctant to accept that any answer could be described as "intuitive". And "well, don't do that" is just ducking the question - in essentially the same way as "it's implementation defined" does... Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XAUNUGXYCCFU2OXUORMKRPHSRQO5HTX3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bare wildcard in de-structuring to ignore remainder and stop iterating (restart)
On Fri, 17 Jun 2022 at 12:34, Steve Jorgensen wrote: > > Although that would be a breaking change, it is already conventional to use > "_" as a variable name only when we specifically don't care what it contains > following its assignment, so for any code to be affected by the change would > be highly unusual. a, b, *_ = iterator() seems like it would be a fairly common pattern to read 2 values and then consume the iterator (for side effects, for example, or simply to avoid the "must return exactly 2 values" error). I'm not sure if I've ever used this myself, but you need to be *very* cautious about asserting that a breaking change is unlikely to cause issues... Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IS3B7WH65U3JMAT5KSEJNKCVHCTJ4I6G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Wed, 15 Jun 2022 at 14:04, Rob Cliffe via Python-ideas wrote: > > Please. This has been many times by several people already. No-one is going > to change their mind on this by now. There's no point in rehashing it and > adding noise to the thread. To be fair, the only real point in re-opening the discussion at all is to determine if anyone has changed their mind. That said, IMO it's unlikely that enough time has passed for that to have happened, so it's unlikely that anything productive will come from this new thread. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KITPPSXCDQBTI3HJCZHLFEAU2RLJOY4W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating
> On 09/06/2022 09:50, Paul Moore wrote:
> > On Thu, 9 Jun 2022 at 01:12, Steve Jorgensen wrote:
> >> My current thinking in response to that is that using islice is a decent
> >> solution except that it's not obvious. You have to jump outside of the
> >> thinking about the destructuring capability and consider what else could
> >> be used to help. Probably, first thing that _would_ come to mind from
> >> outside would be slicing with square brackets, but that would restrict the
> >> solution to only work with sequences and not other iterables and
> >> iterators as islice does.
> >>
> >> That brings up a tangential idea. Why not allow square-bracket indexing of
> >> generators instead of having to import and utilize islice for that?
> > Because generators don't have a common (sub-)type, so there's no class
> > to put the relevant __getitem__ method on.
> >
> >
> How so?
>
> >>> def mygen(): yield 42
> ...
> >>> type(mygen())
>
Sorry, I was assuming the request was for slicing to work for
iterables, not generators. But do we really want to make slicing work
for generators, but still fail for other iterators? That seems like
it'll just cause confusion. Take the OP's original example:
with open("some.file") as f:
for line in f[:10]:
# This fails because f isn't a generator
with open("some.file") as f:
for line in (l for l in f)[:10]:
# This does work because we're slicing a generator
You're bound to get someone (possibly even the OP!!!) asking for the
first version to "just work"...
Also, "obvious" cases like
# How we would do this currently
def get_first_3_current(i):
return list(itertools.islice(i, 3))
# How someone might assume we could do this with the new indexing
def get_first_3(i):
return list(i[:3])
get_first_3(range(10))
get_first_3({1,2,3,4})
get_first_3({"a": "one", "b": "two", "c": "three"})
won't work, and no amount of adding iter() will make them work.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EN2AEJKZKZRWSNDMAROCII4OP4ZCA57C/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating
On Thu, 9 Jun 2022 at 01:12, Steve Jorgensen wrote: > > My current thinking in response to that is that using islice is a decent > solution except that it's not obvious. You have to jump outside of the > thinking about the destructuring capability and consider what else could be > used to help. Probably, first thing that _would_ come to mind from outside > would be slicing with square brackets, but that would restrict the solution > to only work with sequences and not other iterables and iterators as islice > does. > > That brings up a tangential idea. Why not allow square-bracket indexing of > generators instead of having to import and utilize islice for that? Because generators don't have a common (sub-)type, so there's no class to put the relevant __getitem__ method on. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PWM3I437X6CCOW7IRCMKITNIIY3JB3R2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Addition to fnmatch.py
There’s an itertools recipe, “partition”. On Mon, 6 Jun 2022 at 08:28, Chris Angelico wrote: > On Mon, 6 Jun 2022 at 16:42, Christopher Barker > wrote: > > > > I think y’all have addressed the OP’s problem — at least the performance > issues. > > > > But I think this brings up a pattern that I don’t have a nifty way to > address: > > > > How do you divide a sequence into two sequences cleanly? > > > > The filter pattern: selectively remove items from a sequence, returning > a new sequence. There are a few ways to do that in Python. > > > > But what if you need both the remaining items and the removed ones? Easy > enough to write a loop that populates two lists, but is there a nifty > one-liner? > > > > Is this a known functional pattern? > > > > I'd call that a "partitioning" task, and you're right, it's not > particularly easy in Python. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/NEY4JKQMDTMS6PN3I6VK6FCICRLCG43P/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7TFCBUT6UD67UVYNUUTKUP26A5FGSUDO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating
On Sat, 4 Jun 2022 at 09:39, Steve Jorgensen wrote: > > I was using the reading of lines from a file as a contrived example. There > are many other possible cases such as de-structuring from iterator such as > `itertools.repeat()` with no `count` argument which will generate values > endlessly. itertools.islice will (in effect) allow you to have a count argument for any iterator. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NRDAL4ZMLLGCH6ZLI26LLMMH7ZITCQIV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Would it be desirable to save the state of functools.cache?
Conceivably. I know I've had cases where this would be helpful. (But on the other hand, it's not *that* hard to write your own persistent cache for your specific use case if you need it). I think this is a case where someone should just create a PR and submit it. No need for a big debate, the core developer who reviews the PR can make a decision (or suggest further discussion if the PR exposes complexities that aren't immediately apparent). Paul On Tue, 24 May 2022 at 20:06, Neil Girdhar wrote: > > Would it be desirable to save the state of functools.cache between program > executions? For example, by providing cache_state property on the cache that > is pickle-able.___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/C6ZD3N5NP2VVR73SVDOV6NTTZLIO3AJX/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IA2UR3N3EE75T6KRNI7CBAY547S67MGE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Whitespace handling for indexing
On Tue, 24 May 2022 at 15:42, Jan Costandius wrote: > > I think that it would be beneficial for PEP 8 conformance, in the case of > large nested dicts, if one were able to separate dict indices by a newline. > What I mean is shown below: > > foo["bar"] > ["baz"] > ["eggs"] > ["spam"] = 1 I don't think this looks particularly nice, nor do I see how it helps with PEP 8. And if the keys are very long, naming the sub-parts is perfectly viable: baz = foo["bar"]["baz"] baz["eggs"]["spam"] = 1 and backslashes, while not particularly attractive, do the job just fine: foo["bar"] \ ["baz"] \ ["eggs"] \ ["spam"] = 1 Do you have a real-world example of when this would be useful? Something that doesn't use "fake" keys like bar or baz? Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RX3M4UZJFJMPSCQH753FKUI6GX26F2OA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
On Sun, 8 May 2022 at 19:38, Ethan Furman wrote:
>
> On 5/8/22 05:08, Valentin Berlier wrote:
>
>
> > This would make it really useful in if statements and list comprehensions.
> Here are a couple motivating examples:
> >
> > # Buy every pizza on the menu
> > cost_for_all_pizzas = sum(
> > price for food in menu
> > if ({"type": "pizza", "price": price} := food)
> > )
>
> What exactly is that last line testing, and how does it differentiate between
> "pizza" and, say, "salad"?
And what is wrong with
cost_for_all_pizzas = 0
for food in menu:
match food:
case {"type": "pizza", "price": price}:
cost_for_all_pizzas += price
Seriously, people are just getting used to match statements (I had to
look the syntax up for the above) so IMO it's a bit early to be trying
to cram them into dubious one-liners.
Paul.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XRBWE4AMN754NNYZNTT3XEJUQ4N7P46D/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a .find() method to list
On Sat, 7 May 2022 at 16:42, wrote:
>
> In its current implementation, the list type does not provide a simple and
> straightforward way to retrieve one of its elements that fits a certain
> criteria.
>
> If you had to get the user where user['id'] == 2 from this list of users, for
> example, how would you do it?
>
> users = [
> {'id': 1,'name': 'john'},
> {'id': 2, 'name': 'anna'},
> {'id': 3, 'name': 'bruce'},
> ]
>
> # way too verbose and not pythonic
> ids = [user['id'] for user in users]
> index = ids.index(2)
> user_2 = users[index]
>
> # short, but it feels a bit janky
> user_2 = next((user for user in users if user['id'] == 2), None)
>
> # this is okay-ish, i guess
> users_dict = {user['id']: user for user in users}
> user_2 = users_dict.get(2)
>
>
> In my opinion, the list type could have something along these lines:
>
> class MyList(list):
> def find(self, func, default=None):
> for i in self:
> if func(i):
> return i
> return default
>
> my_list = MyList(users)
> user_2 = my_list.find(lambda user: user['id'] == 2)
> print(user_2) # {'id': 2, 'name': 'anna'}
You seem to want a function, but it's not obvious to me why you need that.
found = None
for user in users:
if user["id"] == 2:
found = user
break
seems fine to me. If you need a function
def find_user(id):
for user in users:
if user["id"] == id:
return user
works fine.
Python is very much a procedural language, and "simple and
straightforward" often equates to a few statements, or a loop, or
similar. Unlike functional languages, where people tend to think of
"simple" code as being about combining basic functions into compound
expressions that do "clever stuff", Python code tends to be viewed as
"simple and straightforward" (or "Pythonic" if you like) if it
*doesn't* try to combine too much into one expression, but describes
what you're doing in a step by step manner.
So yes, a list doesn't provide the sort of "find" method you're
suggesting. That's because a loop is easy, and does the job just fine.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/IIO2LDWQ7L3N2SJYV6SFJQ5KHMKWSFNU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
On Wed, 4 May 2022 at 17:04, Christopher Barker wrote: > > Bringing this back on list -- I hope that was an accident. If it was, it was me not spotting that your reply to me was on-list, I thought you're replied offlist so I followed suit. Not a problem though, I'm fine with this being on-list (although we're quite a lot off topic now, so others may want me to shut up ;-)) >> The problem with __post_init__ (I think) is >> that it confuses the type checkers (beware, untested code below!): > > Does the attrs approach work any better for this? Not notably. But I haven't explored it in detail, I'll be honest - there's a lot of options, and I may have missed a good one. >> @dataclass >> class Metadata: >> version: str # Actually a Version, but that's not the type we >> want the constructor to accept. >> >> def __post_init__(self): >> self.version = Version(self.version) >> >> And the reality is worse. We want the constructor to take a Version, >> or anything that can be converted to a Version > >> (which, if I check the >> source of the library, *is* just str - but I don't want to necessarily >> copy that declaration as it might change). And yet we want the >> typechecker to know that metadata.version is always a Version. All of >> that information is available statically (we call Version on the input >> data, and self.version is always the result of that call) but I can't >> see how to explain that to the type checker. > > > Frankly, I see that as a limitation of static typing -- how does one describe > "anything that can be turned into a Version? -- sure, the Version __init__ > can take either a Version or a str -- but only certain strs will make any > sense -- so what's the point? Well, while I do agree it's a limitation of static typing, if a value is passed to Version(), the type checker can infer that it must have a type that matches the argument declaration. The problem is that there's no way in Python to *describe* that type so that I can use it in the attribute declaration. So I have to copy the definition. And anyway, what I want is to say that the *attribute* has type Version, but the *constructor argument* has a different type. And I don't think type checkers can handle that, because of how dataclasses work (auto-generating the init function). > Honestly, I think if you want your code to be statically "safe" then you > should have this metadata class require a Version object, which would require > its users to do the conversion first. Nope, I really shouldn't. The reasons are very specific to the application logic, but a class that required the user to convert in advance would be useless to me. (Sure, a complete redesign of the app might make it possible, but that's not the point). > Which is why I like the Dynamic nature of Python, and haven't gotten excited > about static typing. I know, and I agree. But having autocompletion in VS Code is nice, and mypy checks do sometimes pick up on errors. But too much of my time is taken up trying to work around cases where type checkers get confused or upset about very dynamic code. And they don't typically degrade gracefully (by which I mean red "you got this wrong" error bars in my editor, or errors I don't know how to suppress in mypy without adding "I know what I'm doing" comments in my code. So I'm mostly uninterested in adding types, but when I do, I'm obsessive about getting them right :-( > I suppose the way to solve this without dataclasses or auto-assignment is to > type the class attribute and the __init__ parameter separately, yes? Possibly, I haven't experimented much. Although it's a PITA if, in def f(v): v1 = Version(v) reveal_type(v1) reveal_type(v) type checkers can't infer that v1 is of type Version, and v is of a type compatible with the argument of Version. Annoyingly, VS Code appears to get the type of v1, but not of v. And mypy says: ❯ mypy .\tyex.py tyex.py:5: note: Revealed type is "Any" tyex.py:5: note: 'reveal_type' always outputs 'Any' in unchecked functions tyex.py:6: note: Revealed type is "Any" tyex.py:6: note: 'reveal_type' always outputs 'Any' in unchecked functions > (which auto-assignment wouldn't help with, either) Indeed. [...] > What this tells me is that if you want dataclasses to be more > typing-friendly, then there should be a way to specify the __init__ type > separately, which could be done with a parameter to the Field object. Maybe. But really what I want is a way to say "this is what type the attribute is, but don't assume the init argument is the same type". Or just not bother with all this at all. This is where it starts to just become not worth trying to make dataclasses do what I want, I might as well do it myself via init=False. > Bringing it back OT: > > As much as I hate to say it: For folks advocating an auto-assignment feature > -- you should probably consider how it would play with static typing :-( That's probably a good point. Paul
[Python-ideas] Re: Get the value of an attribute of an object hierarchy with a path expression
On Wed, 4 May 2022 at 13:29, Dr. Guta Gábor wrote: > > > I'm not sure there's enough need for this that it should be in the > > stdlib. And I'm certain it isn't sufficiently common to justify being > > a builtin. > How 'enough need' can be measured? Well, there are at least two libraries on PyPI, and at least one of them (glom) has been around for some time, but neither is particularly well known. This suggests to me that this isn't an issue that people are routinely asking "how do I solve this problem?" (or if they are, their requirements are sufficiently different that no one solution has emerged as "the obvious one"). So I struggle to imagine that there's a significant group of users who are all waiting for a solution in the stdlib, and for whom installing a library from PyPI is a problem. > The other way to solve this problem is to have null-conditional access > operators ?. and ?[] like in C# (i.e. a.b.c can be written to a?.b?.c to be > prone to None values). Well, that's not the *only* other way to solve the problem. Using a library from PyPI is an entirely reasonable solution as well. You seem to be discounting that as an option. Can you explain what's wrong with using a library off PyPI? Just to be clear, I'm one of the stronger supporters of having an extensive stdlib, so when I say this, I'm *not* saying that everything should be on PyPI. But it would be good if you could articulate your reasons for why this specific functionality is less usable as an external library, that justify it being in the stdlib. > I don't think that null-conditional operators are Pythonic, but I guess if an > other language has a complete set of operators around a problem, it could be > something that interest lots of people. I agree with you somewhat on this point, I don't think anyone has successfully demonstrated that library-based solutions aren't sufficient here. But library-based doesn't necessarily mean "in the stdlib". Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UA5CWF2Z4ZKYO35CZGRGZWQFGGL6AQ2W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Get the value of an attribute of an object hierarchy with a path expression
On Wed, 4 May 2022 at 12:27, Dr. Guta Gábor wrote: > > This proposal is about adding a builtin function or a package to the standard > library to access an element in an object hierarchy with default behavior > i.e. if at any level the attribute/key/index does not exist in the path the > function returns a default value. [...] > I created a package to demonstrate the idea: > https://github.com/axonmatics/quickpath There's another PyPI library "glom" that does this sort of thing. I'm not sure there's enough need for this that it should be in the stdlib. And I'm certain it isn't sufficiently common to justify being a builtin. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6DOKNFFSSTADE2DEUBOOBOZJABVTADIN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
On Tue, 3 May 2022 at 03:04, Steven D'Aprano wrote:
>
> On Mon, May 02, 2022 at 07:44:14PM +0100, Paul Moore wrote:
>
> > I have classes with 20+ parameters (packaging metadata). You can argue
> > that a dataclass would be better, or some other form of refactoring,
> > and you may actually be right. But it is a legitimate design for that
> > use case.
>
> Indeed. 20+ parameters is only a code smell, it's not *necessarily*
> wrong. Sometimes you just need lots of parameters, even if it is ugly.
>
> For reference, open() only takes 8, so 20 is a pretty wiffy code smell,
> but it is what it is.
It's worth noting that dataclasses with lots of attributes by default
generate constructors that require all of those as parameters. So it's
a code smell yes, but by that logic so are dataclasses with many
attributes (unless you write a bunch of custom code). Genuine question
- what *is* a non-smelly way of writing a dataclass with 24
attributes?
I've written about 20 variations on this particular class so far, and
none of them feel "right" to me :-(
> > Of course the real problem is that you often don't want to
> > *quite* assign the argument unchanged - `self.provides_extras =
> > set(provides_extras or [])` or `self.requires_python = requires_python
> > or specifiers.SpecifierSet()` are variations that break the whole
> > "just assign the argument unchanged" pattern.
>
> Indeed. Once we move out of that unchanged assignment pattern, we need
> to read more carefully rather than skim
>
> self._spam = (spam or '').lower().strip()
>
> but you can't replace that with auto assignment.
Precisely.
> > As a variation on the issue, which the @ syntax *wouldn't* solve, in
> > classmethods for classes like this, I often find myself constructing
> > dictionaries of arguments, copying multiple values from one dict to
> > another, sometimes with the same sort of subtle variation as above:
> >
> > @classmethod
> > def from_other_args(cls, a, b, c, d):
> > kw = {}
> > kw["a"] = a
> > kw["b"] = b
> > kw["c"] = c
> > kw["d"] = d
> > return cls(**kw)
>
> You may find it easier to make a copy of locals() and delete the
> parameters you don't want, rather than retype them all like that:
>
> params = locals().copy()
> for name in ['cls', 'e', 'g']:
> del params[name]
> return cls(**params)
>
>
> > Again, in "real code", not all of these would be copied, or some would
> > have defaults, etc. The pattern's the same, though - enough args
> > arecopied to make the idea of marking them with an @ seem attractive.
>
> But the @ proposal here won't help. If you mark them with @, won't they
> be auto-assigned onto cls?
Again, precisely.
My point here is that the @ proposal is, in my experience, useful in
far fewer situations than people are claiming. What *is* common (again
in my experience) is variations on a pattern that can be described as
"lots of repetitive copying of values from one location to another,
possibly with minor modifications". Having a way of addressing the
broader problem *might* be of sufficient use to be worth pursuing, and
it might even be possible to do something useful in a library, not
needing new syntax.
On the other hand, the @ syntax as proposed *doesn't* address enough
use cases (for me!) to be worthwhile, especially not if new syntax is
needed rather than just something like a decorator.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/CD3HRBE2Q6WIKOJDE5GCLFVVHMGR42VZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
On Mon, 2 May 2022 at 18:46, Steven D'Aprano wrote:
>
> But **not once** when I have read that same method later on have I
> regretted that those assignments are explicitly written out, or wished
> that they were implicit and invisible.
I have classes with 20+ parameters (packaging metadata). You can argue
that a dataclass would be better, or some other form of refactoring,
and you may actually be right. But it is a legitimate design for that
use case. In that sort of case, 20+ lines of assignments in the
constructor *are* actually rather unreadable, not just a pain to
write. Of course the real problem is that you often don't want to
*quite* assign the argument unchanged - `self.provides_extras =
set(provides_extras or [])` or `self.requires_python = requires_python
or specifiers.SpecifierSet()` are variations that break the whole
"just assign the argument unchanged" pattern.
As a variation on the issue, which the @ syntax *wouldn't* solve, in
classmethods for classes like this, I often find myself constructing
dictionaries of arguments, copying multiple values from one dict to
another, sometimes with the same sort of subtle variation as above:
@classmethod
def from_other_args(cls, a, b, c, d):
kw = {}
kw["a"] = a
kw["b"] = b
kw["c"] = c
kw["d"] = d
return cls(**kw)
Again, in "real code", not all of these would be copied, or some would
have defaults, etc. The pattern's the same, though - enough args
arecopied to make the idea of marking them with an @ seem attractive.
Overall, as described I don't think the @arg proposal provides enough
benefit to justify new syntax (and I think trying to extend it would
end badly...). On the other hand, if someone were to come up with a
useful, general way of bulk-copying named values from one "place"[1]
to another, possibly with minor modifications, I think I'd find that
very useful. Call it a DSL for bulk data initialisation, if you like.
I think such a thing could pretty easily be designed as a library. But
I doubt anyone will bother, as adhoc "on the fly" solutions tend to be
sufficient in practice.
Paul
[1] A "place" might be a dictionary - dict["name"] or an object -
getattr(self, "name").
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/Y7KWHYQE7Q7GWEM73RKCT3ITC74LNGPI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Native support for units [was: custom literals]
On Fri, 8 Apr 2022 at 13:09, Matt del Valle wrote: > > My personal preference for adding units to python would be to make instances > of all numeric classes subscriptable, with the implementation being roughly > equivalent to: > > def __getitem__(self, unit_cls: type[T]) -> T: > return unit_cls(self) > > > We could then discuss the possibility of adding some implementation of units > to the stdlib. For example: > > from units.si import km, m, N, Pa > > 3[km] + 4[m] == 3004[m] # True > 5[N]/1[m**2] == 5[Pa] # True Thanks. That's extremely useful, and I can see it as a reasonable language feature request. BUT (and it's a big "but"!) someone would have to write, support and maintain that units library. Obviously in the first instance, it couldn't use the dedicated syntax, but unit_cls(number) doesn't seem like a horribly bad compromise for a 3rd party library right now. So here's my proposal. 1. Somebody (or a group of people) who wants to see this happen, write (or adopt) a library and publish it on PyPI. It should provide *all* of the functionality that the proposed stdlib support would offer, with the sole exception that units get attached to values using unit_cls(number) rather than special syntax. It's possible that the "units" library that's already on PyPI is (nearly) that library - but from what I've heard in this thread, the community hasn't reached consensus on what "best of breed" looks like yet. 2. Once that library has demonstrated its popularity, someone writes a PEP suggesting that the language adds support for the syntax `number[annotation]` that can be customised by user code. This would be very similar in principle to the PEP for the matrix multiplication @ operator - a popular 3rd party library demonstrates that a well-focused language change, designed to be generally useful, can significantly improve the UI of the library in a way which would be natural for that library's users (while still being general enough to allow others to experiment with the feature as well). 3. Once the new language feature is accepted, and the library authors are willing, propose that the library gets added to the stdlib. We're currently at step 1 - we need someone to come up with a library that demonstrates how to provide this functionality in a way that matches users' requirements, and which has unified community support. That step doesn't need anything much from the Python core devs or even this list, beyond maybe a general feeling that the overall plan "isn't a totally dumb idea"... Step 2 is where a PEP and proper core dev support would be needed. But the library would be useful even if this doesn't happen (and conversely, if the library proves *not* to be useful, it demonstrates that the language change wouldn't actually be as valuable as people had hoped). Step 3 is optional. With language support that can be used by external libraries, "being part of the stdlib" isn't needed. This is true of pretty much everything in the stdlib, though - stdlib modules don't have any special benefits that external libraries don't. As a supporter of a large stdlib, I'd be OK with moving the units library into the stdlib (on the assumption that the library maintainers commit to supporting it in the stdlib, and don't run away and dump the problem on the core devs). Others who prefer a smaller stdlib would argue it's fine on PyPI. But that's an argument about principles which frankly end users and 3rd party library authors can't influence much (and can probably ignore in practice). So honestly, I'd encourage interested users to get on with implementing the library of their dreams. By all means look ahead to how language syntax improvements might help you, but don't let that stop you getting something useful working right now. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5NYDJZSQK7ZEE5UDCWHAAU5ZK5FKCLVE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Native support for units [was: custom literals]
On Fri, 8 Apr 2022 at 12:22, Ricky Teachey wrote: > I just get really excited at the idea of it being native to the language and > am dreaming of being able to use it more often for my every day calculations. > Right now I just don't feel confident I can. If you can describe what the Python of your dreams would look like, that would be really useful. Most of the problem here is with people who *don't* need units for every day calculations struggling to understand what is wrong with a library-based solution, and what "language support" would look like in practice. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XAA2IFSZEAS3CUU3TG4DV57U4DZU7FGF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Native support for units [was: custom literals]
On Thu, 7 Apr 2022 at 01:18, Brian McCall wrote: > >> Please can you explain this to me? I don't know what you mean by "get the >> final answer", nor do I know how astropy.units is relevant. Units seems to >> be a perfectly acceptable library without astropy, is that not the case? > > Am I mistaken, or is the units module no longer maintained? I could not find > any documentation for it. Which is also a con. I honestly thought that > "units" took on a new life as "astropy.units". I honestly have no idea. I simply did `pip install units` and it worked. If the units module is no longer maintained, then who would write (and maintain) a module that worked with any core python syntax to allow units to be added to quantities? (Note that any core feature would simply allow something like 3_ft to be written to mean the number 3, with some object associated with the name "ft" attached to it - it would be up to a 3rd party module to actually implement the units calculations). It doesn't look like the astropy people want to maintain a generalised units library if they are solely working with numpy arrays. Also, you didn't explain what you meant by "get the final answer" - I'm still not clear with what you want beyond doing the calculation as you showed in your code. > > As has been mentioned, if you don't like "units." then "from astropy import > > units as U" and use "U.ms" of "from astropy.units import ms" and use ms > > directly. > > As an fyi, lots of single-letter variables are commonly used to match > variables in physics and engineering equations. U and u are of particular > importance in my field. > > > Don't use "import *" then, just import the names you need. > > Still rules out a lot of commonly used variables. ¯\_(ツ)_/¯ If your community typically uses short and frequently clashing names, relying on context and intuition to distinguish them, there's nothing a library or language feature can do to help with that... As I said, there have to be some compromises made. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PZ2RDAO4MGPL46BR6C36BKU4IQUP6WJO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Native support for units [was: custom literals]
On Wed, 6 Apr 2022 at 16:51, Brian McCall
wrote:
> Before I get to this example, though, there is more to arguments for the
> "need" than just counter-examples. I keep using quotes because nothing is
> really a need for anything.
Yes, it's not about "need" in an absolute sense, but more about
whether the gains justify the costs. In this case, the costs are
non-trivial, because there's very little prior art (at least that I
know of) in other programming languages in this area. So there's a
learning curve, making Python a bit less approachable for the average
programmer, which offsets the benefits to people who gain from this
sort of functionality. And that's on top of the usual costs of any
syntax change/new language feature.
> Alright, now let's look at an example. Again, it's not my best, let's go with
> it.
Thanks for this, it helps a lot to have something concrete.
> Symbol definitions:
> h - Planck's constant
> c - speed of light
> Ee - irradiance
> R - reflectance
> Q - quantum efficiency
> F - f-number
> λ - wavelength
> a - width of a pixel
> t - exposure time
> ȳ - output of luminosity function integral
>
> From here, if the triple tick marks do not render this example in monospace
> for you, then I recommend copy/pasting into something that does.
>
> ```
> echo no units
>
> python -c "
> h = 6.62607015e-34
> c = 299792458
> Ee = 200
> R = 0.25
> Q = 0.63
> F = 2.4
> λ = 550e-9
> a = 3.45e-6
> t = 30e-3
> ȳ = 683
> n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2)
Someone's already asked, so I know that the issue was with the value
given to one of the constants, rather than with the formula. And I
know all of this is intended to be read by specialists, not by the
likes of me, but I wonder whether some comments might have helped
here, as well?
t = 30e-3 # exposure time (seconds)
There's a subtle difference between "scripting" and "programming", and
as a programmer, I'd almost certainly add comments like this. But if I
was writing a script, I wouldn't. However, I'd generally not trust the
output of a script as much as I would that of a program. (Jupyter
notebooks fall somewhere in between, for what it's worth...)
> # n = (200 * 0.25 * 0.63 * 550e-9 * 30e-3 * (3.45e-6)**2) / (2 * h*c * 683 *
> 2.4**2)
> print(n)
> "
>
> # Pros - compact, the code representing the equation is easily verifiable,
> and the magnitudes are also easily verifiable
Given that the error was in the magnitude of one of the values,
"magnitudes are easily verifiable" doesn't really seem that correct...
> # Cons - no units
Agreed, this is just using Python as a glorified calculator. I
understand that this is just an example, but I *am* curious, is the
bulk of what you do simply calculations like this, or do your more
complicated examples tend to be more like actual programs?
>
> echo What literals would look like
> python -c "
> # h = 6.62607015e-34m2kg / 1s
> # c = 299792458m / 1s
> # Ee = 200lx
> # R = 0.25
> # Q = 0.63
> # F = 2.4
> # λ = 550e-9nm
> # a = 0.00345mm
> # t = 30ms
> # ȳ = 683lm / 1W
> # n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2)
> # n = (200lx * 0.25 * 0.63 * 500nm * 30ms * (3450nm)**2) / (2 * h*c *
> 683lm/1W * 2.4**2)
> "
> # Pros - Still compact. Dead simple. Planck's constant looks a little weird,
> but this is usually imported from a library anyway
> # Cons - requires a syntax change; inline computations like the last line are
> not IMO quite as readable as the next example
What would the output of "print(n)" be here? Presumably you'd be
expecting some sort of calculation on the units, so you didn't just
get something like
3958.0636423739215lxnm3msWs2/m2kglm
Or is that sufficient for you (I note that it's the same as units
provides, below)? Excuse me if I got the scale of the constant wrong,
you changed the units between the no-units example and this one (t,
for example was seconds and is now ms).
> echo 'What bracket syntax might look like'
> python -c "
> # h = 6.62607015e-34 [m**2*kg/s]
> # c = 299792458 [m/s]
> # Ee = 200[lx]
> # R = 0.25
> # Q = 0.63
> # F = 2.4
> # λ = 550e-9 [nm]
> # a = 0.00345[mm]
> # t = 30 [ms]
> # ȳ = 683[lm/W]
> # n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2)
> # n = (200[lx] * 0.25 * 0.63 * 500[nm] * 30[ms] * (0.00345[mm])**2) / (2 *
> h*c * 683[lm/W] * 2.4**2)
> "
>
> # Pros - Still compact, dead simple, and IMO the best way to look at this code
> # Cons - requires a syntax change and a new kind of namespace in addition to
> global, nonlocal, and enclosure
This is basically just a different bikeshed colour for the previous
example, I think. Is that right?
> echo units
> python -c "
> from units import unit
> h = unit('m**2*kg/s')(6.62607015e-34)
> c = unit('m/s') (299792458)
> Ee = unit('lx') (200)
> R = 0.25
> Q = 0.63
> F = 2.4
> λ
[Python-ideas] Re: Native support for units [was: custom literals]
On Tue, 5 Apr 2022 at 14:25, Ricky Teachey wrote: > units are at THE CORE of that need. > > i think python should be the language we reach for. i have made python work > for me as a civil engineer and been extremely successful with it for all the > usual reasons: ease of learning and community backing that learning, the open > source resources (libraries and applications), the momentum of the language, > its ability to be a swiss army knife (need to transition to web? automate the > boring thing? sure, easy). I've been reading this discussion with gradually increasing levels of bemusement. I genuinely had no idea that handling units was so complex. But one thing I did note was that there are various libraries (at least one, I think I saw more than one mentioned) that do units handling. Why are those libraries insufficient? You said that "The motivation is much more than just being able to not have the * symbol", but no-one seems to have explained why a library isn't enough. After all, scientists manage with numpy being a library and not a core feature. Data scientists manage with tensorflow being a library. What's not sufficient for unit support to be a library? (And remember, the numeric users successfully got the @ operator added to the language by arguing from the basis of it being a sufficient enhancement to improve the experience of using numpy, after years of having requests for general "matrix operations" rejected - language changes are *more likely* based on a thriving community of library users, so starting with a library is a positive way of arguing for core changes). Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RSB6AAPNDTWLP7RKVJYTTYY6FPTP5SVV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
On Tue, 5 Apr 2022 at 12:37, malmiteria wrote: > > ROUND 3 i guess > > I promised paul moore an up to date proposal, here it is: > > 1) an alterhitance module, dedicated to all __bases__ (the iterable of > parents) alteration operations > This replaces the "dependency injection" use case (based on MRO injection, > not __bases__ edits), and on its own doesn't need any addition to python > itself, however, it relies on today's super ability to handle implicitely > remaps of __bases__, and other proposal might remove this capacity, if not > accounted for, so i'm leaving this altheritance module in the proposal, just > so we all know it's not forgotten about. If you want to implement a module, do so and put it on PyPI. I personally think this is probably useless, but it's not a Python change so do it if you want. When (if) it's proved useful, if you want to propose it for the stdlib, you can argue for that separately based on the module's popularity. > 2) the adoption syntax, for classes that are designed to work with multiple > parent (mixin use case) > would replace code from: > ``` > class MyView(LoginMixin, PermissionMixin, View): > ... > ``` > to > ``` > class MyView( > LoginMixin( > PermissionMixin( > View > ) > ) > ): > ... > ``` > Essentially, it's a way to tell MyView to inherit from LoginMixin, which in > this context inherits from PermissionMixin, which in this context inherits > from View. > Again, this could be talked about in a separate post, but it is relevant to > the current discussion, as Mixins are the most current use case for today's > ML. > Actually, idk, should i make a dedicated post for it? or should i keep it in > this thread, as it is relevant to the end goal? It has value on its own tho. I have no idea what the point of this is. And you've made no attempt to describe use cases that would gain from this, or explain what existing constructs would be improved by it. So -1 from me. > 3) Multiple strategies for diamond problems > Essentially, in more general terms, how to handle the case of a class > appearing multiple time in an inheritance tree, should it be specialised > once? each time? only on some specific occasions? I want to add either a > decorator, or a class attribute, or anything for that matter, so that the > programmers can choose the strat they need. > I've got an idea this night about having the kwargs "use_target_MRO" for > super, that might cover this need, i'm not sure. You've not defined this at all, nor have you explained why it's needed. I've never had a "diamond problem" that the existing model didn't suffice for (to be honest, I'm not entirely sure I've ever encountered a diamond problem at all, as I avoid complex multiple inheritance hierarchies because they feel like a code smell anyway). -1 from me. > 4) Allowing to pass as argument of super the class you're targeting, which i > got the idea this night could be done with a target kwarg. > argumentless syntax would behave the same This is a breaking change (passing an argument to super means something different right now). You need to justify breaking existing code (or demonstrate that no-one currently passes arguments to super()) and you haven't. And even if you avoid *any* breakage, you still need to explain why it's worth doing, which you haven't. So -1 from me. > I believe if all those proposal come first, super is not benefitting from MRO > anymore, and MRO could be removed. super is not the only way the MRO is used. And you can't just "remove" it anyway - methods need to be resolved, you can propose a change to the order, but "removing" any resolution order makes no sense. > 5) replacing MRO with a method resolution that I describe at the top of my > post: > - accessing an attribute / method that multiple parent can provide would > raise an ExplicitResolutionRequiredError, those errors can be solved by > defining the attribute in the child class, and performing the "merge" as > you'd want it there. So making the programmer do all the work, rather than having a default behaviour that works in at least some cases. That's strictly worse than the current behaviour. > - accessing an attribute that only one parent can provide would work fine, > even if multiple parent are present (what matters is the uniqueness of the > candidate to resolution) Same as now > - accessing an attribute that no parent have would raise an AttributeError. Same as now > - obviously, accessing an attribute defined in the class body would resolve > to this attribute Same as now > - this would apply for attribute and method, just like today's MRO. So this is essentially making some existing
[Python-ideas] Re: mro and super don't feel so pythonic
On Mon, 4 Apr 2022 at 22:19, malmiteria wrote: > What i am saying is that *if* super(A, self) *were* to call A's method, that > would be a simpler API. I understand that you're specifically responding to Chris, but to be honest, this is the first time you've explicitly stated this (unless it was previously lost in a sea of words somewhere). So I'd like to respond. If you're suggesting *changing* super's behaviour like this, you have to explain how you expect to handle the (quite possibly literally) millions of lines of code that would be broken by making such a change. So far, all you've offered is that "it would be a simpler API" and had no-one agree with you that this is the case. That's not even remotely close to being sufficient to make such a drastic change. > If you understand that this is my proposal, and not my understanding of > today's super, then for the love of god, address my proposal. If that *is* your proposal, then just drop it. You seem incapable of presenting a case that will justify such a massive breakage, so you're just wasting everyone's time making them read your huge emails. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SPMRJYKUDRS3SK4QRBN5JQDAU6QXGPNY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
On Mon, 4 Apr 2022 at 18:59, malmiteria wrote: > super(A, self) does not proxy to A, but to the first *after* A in MRO order. Correct, that's how it's defined to work. > When you're actually in need to passing arguments to super, you very likely > know what class you're gonna be targeting, and having to run MRO logic in > reverse to call super to the class that comes first before your target in MRO > order is what i refer to as "working around MRO". Not at all, you pass *your own class*, and super() works things out for you. Or more simply, just omit the type and super() will work as you want it to. class A(...): def foo(): super().foo() # or super(A).foo() Note that I left the set of bases unspecified, as ..., to demonstrate that you don't need to care what they are. That's the point - the type argument to super() can be omitted in 99% of cases, and whenever it can't, it should be the last class you know about. There's no "running the MRO in reverse". In reality, I can't think of a single realistic case where you'd specify a type argument to super() anyway. Before you mention it, your xxxGoblin/HalfBreed example should be using delegation, as Steven D'Aprano pointed out - using super() in a case where you're trying to force a specific resolution path is *not what super is for*. Maybe you do have use cases where super isn't the right tool for the job. That's entirely possible. But that doesn't mean we should modify super to handle those cases as well as its current function - *especially* not if there are other solutions available in Python today, which don't use super. If you're trying to hit a nail into a piece of wood, and your screwdriver isn't doing a good job at it, that means that you should learn about hammers, not that you should propose that screwdrivers get modified to get better at hitting nails... Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EK7COW2D7MFIUBTFQZKVMCFEBPK7VKXZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
On Sun, 3 Apr 2022 at 18:36, malmiteria wrote: > > Chris Angelico writes: > > And is it still based on the fundamental > > assumption that super() calls THE parent class? > what are you even talking about? It's been explained before in this thread - your fundamental misconception that there is always a single well defined "parent class". In practice there are cases (which have been noted here) that don't follow that pattern. And if you don't take that into account, any proposal you make will be flawed. > > I don't have the time to read > > that long a post. > Then just read the list of 4-5 features i describe as features of current MRO > + super, at the top of my post, and tell me if you agree with this analysis > or not. Sigh. OK, I'll bite. > 1) a dedicated module for dependency injection and more called alterhitance That's not a feature of the current MRO+super. If you want to write such a module, by all means do so and put it on PyPI. I don't know how popular it will be (given that you don't seem to have the same mental model of inheritance as Python's) but there's nothing stopping you, at least not from just reading this one line description (which you said was OK to do...) > 2) a way to declare inheritance after defining the class (postponed > inheritance) If you want this as a Python feature, you'll need to describe use cases and semantics. But again, you're starting from a model that doesn't match how Python works, so it's hard to see this getting accepted. If the "way" you're suggesting doesn't need a language change, then again go for it and publish it on PyPI. > 3) a solution to the diamond problem You haven't demonstrated that there's a problem to be solved. And even if there is, Python *has* a solution, so what's wrong with the existing solution? > 4) changes to the proxy feature of super (that i already mentionned earlier > in this thread) What's wrong with how it is now? You can't argue for change unless you understand the current model, and so far you've demonstrated that you don't, and you're not willing to accept the explanations that have been offered. > 5) changes to the method resolution algorithm (that i already mentionned > earlier in this thread) Same as for (4), what's wrong with it now? Overall, you stand very little chance of getting anywhere with this as you seem to be unwilling to make the attempt to understand people's objections. And you just keep posting huge walls of text that no-one is going to read, because they make no sense to anyone who is familiar with, and comfortable with, Python's existing model. So you're never going to persuade anyone who doesn't already agree with you... Paul PS Please don't respond to this with another wall of text. I won't read it. If you can't summarise the basic idea behind your proposal in a single paragraph, it's probably too complicated, or too incomplete, to succeed anyway. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/I7GNHKSVMRJOXSJSPYK3Q4VZIFWYWBPW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: s?scanf [was: A string function idea]
On Wed, 30 Mar 2022 at 17:58, Christopher Barker wrote: > > On Wed, Mar 30, 2022 at 1:50 AM Stéfane Fermigier wrote: >> >> FYI, there is a “parse” library on PyPI: https://pypi.org/project/parse/ >> >> Parse strings using a specification based on the Python format() syntax. >> >> parse() is the opposite of format() >> >> (I haven’t used it myself, > > > Me neither, but I do like this idea better than scanf style. And there’s an > implementation ready to try out. +1 from me as well. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3GRJX3N7536QK2WUF6VT7J2273VCZ5QI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow os.getenv to optionally convert result to boolean
On Wed, 30 Mar 2022 at 15:39, Adrian Torres Justo wrote: > > Why not use just to_bool(getenv(key))? > > We did use distutils.util.strtobool(os.getenv(key, default)) for a while, > eventually we just built a helper that did the same because it's easier / > more comfortable. > > > No. There would be hundreds different trivial implementations. > > Can you elaborate? Here's more or less what I had in mind (using the > os.getenv source code as template): > > from distutils.util import strtobool > > def getenv(key, default=None, to_bool=False): > """Get an environment variable, return None if it doesn't exist. > The optional second argument can specify an alternate default. > key, default and the result are str.""" > val = environ.get(key, default) > return val if not to_bool else strtobool(val) > > Sure, there are other ways to implement that are probably equally trivial, > but why does that matter? > There are a lot of ways to interpret "convert to bool" - should "yes" and "no" be converted? What about "1" and "0"? Or "001", or "-1"? What should happen to unrecognised values? What if the environment variable doesn't exist? It's not at all obvious to me that strtobool is the definitive way of doing this (quite apart from the fact that distutils will be getting removed from the stdlib in Python 3.12 - see https://peps.python.org/pep-0632/). What is so special about *this particular way* that it's worth including in the stdlib? Particularly when it's so easy to write for yourself. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/J4XDAC6KOVAOOCT2W2ATJ3XZZNUWJNHC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Fri, 11 Mar 2022 at 19:12, wfdc wrote: > What kind of evidence would satisfy you? And how did previous proposals you > supported obtain such evidence? Honestly, probably nothing. I don't think this is a good idea in any case, the "not every one-line function needs to be a builtin" principle applies here, in my view. You may have a different view, that's fine. My reason for pointing out that you hadn't demonstrated that your proposal satisfied the criteria that you yourself stated, is that you might find someone more sympathetic to the proposal, and if so, this is the sort of evidence that you'd need in order to take this to python-dev or to create a PR, if you were to have any chance of success. In the past, proposals that succeeded often did so by surveying significant bodies of real-world code (for example, the standard library) and pointing out where the proposed new feature would demonstrably improve the readability or maintainability of parts of the code. > We've already had 2 other participants here attesting to frequent use of this > functionality. You do know how many people use Python? 2 people saying they do something like this isn't particularly significant. Even 2 people out of the number of regular contributors on python-ideas isn't a lot (especially if you take level of participation into account - which is dangerous, because it amounts to an appeal to authority, but how else are you going to demonstrate that a non-trivial number of the millions of people who use Python would find this helpful? > > it's not clear that the OP shouldn't have been using a list in > the first place > > This has already been explained in this thread. A list is not immutable. A > tuple is. Both the old and new tuples are not mutated or mutable, and we want > to keep it that way. Yes, I understand that if you want to create a new immutable tuple with one value changed, you need to build it from the parts of the original. But there's no *context* here. What's the real-world problem being solved? Why, in the context of that real-world problem, is a tuple (as opposed to, say, an immutable dataclass or namedtuple, both of which have replace methods) the demonstrably best choice, *in spite* of the fact that other choices provide the supposedly important replace functionality? The original SO question sounds suspiciously like an XY-problem to me (see https://en.wikipedia.org/wiki/XY_problem). > See namedtuple's ._replace method. namedtuples are also immutable. We simply > want the same functionality for tuple. I understand *what* you want. But *why*? If the only reason is "for consistency", then fine, that's a reasonable reason. Unlikely to be sufficient in isolation, but that's OK. You asked, you got told "your reasons aren't sufficient". But if you want to persuade someone who has the ability to commit a change to Python to support this proposal, you'll need more (which is what I am trying to help you with). Best of luck in trying to get support for this idea. I'm not keen on it myself, but I'm grateful that you're willing to spend time helping to contribute back towards improving Python. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QOFB34UYWF5K7WPSTMTDPQSLH7VYBC5G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
On Fri, 11 Mar 2022 at 02:20, wfdc via Python-ideas wrote: > If users find themselves re-implementing the same utility function over again > and over again across different projects, it's a good sign that such a > function should be part of the standard library. And yet you haven't demonstrated that this is the case for your proposal (one Stack Overflow question, with a low number of votes, where it's not clear that the OP shouldn't have been using a list in the first place, isn't particularly compelling evidence). Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2A6GQZJ4G7JZMSIE6M4CU4BQMQJ62XUN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Mon, 7 Mar 2022 at 23:44, Chris Angelico wrote: > Not ALL typing changes are just new things in typing.py, so that > doesn't cover everything. And yes, I am sure that a lot of things get > proposed and not implemented - my point is that typing-sig is > successfully finding the good ideas and refining them into actual > code, but python-ideas is 100% shooting ideas to pieces. Bikeshed problem. I barely understand most of the proposals on typing-sig, whereas *everyone* knows what "for..in..if" means (and hence has an opinion). Add to that the fact that the framing of many proposals on python-ideas feels like "here's a neat idea, why doesn't someone (not me) implement it", whereas proposals on typing-sig generally seem to involve an interested party doing a *lot* of work up front, and then summarising that in a proposal, and it's not hard to see why python-ideas is both more accessible for people proposing incompletely thought through ideas, and more hostile towards them... To put it another way, if the culture on python-ideas expected people to do as much up-front work on a proposal as typing-sig seems to (from my experience, at least), there would be far fewer ideas on here, but they would be a lot better, and would be much more likely to be successful. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PPDNF7DHJ6WA7KPXTZJYGG7L7N5SV3U5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Sun, 6 Mar 2022 at 22:43, Chris Angelico wrote: > > On Mon, 7 Mar 2022 at 09:33, Paul Moore wrote: > > > Do I care enough to write a PEP? No. So this, like many other small > > > ideas, will probably die on the vine. > > > > Yes, this is the real problem. It's simply not compelling enough, even > > for supporters of the idea, for them to do the necessary work to make > > it happen. > > > > It is indeed a problem. When a good idea dies because it is simply too > hard to get through the hassles of pushing it to a decision, there is > a fundamental problem. It's good to have a bit of inertia, so that > status quo gets maintained, but at the moment, the extent to which > ideas get shot down makes it look as if this list is > python-idea-killing. I agree - there are a lot of people here who will strongly defend the status quo, as well as a lot of people who simply like to argue for arguing's sake. But it's worth remembering that "survive python-ideas" is *not* part of the PEP process. And it's *also* worth remembering that Python is now so big, and so popular, that change is far more costly than it used to be. > This keeps happening. All the successful ideas seem to happen > elsewhere, notably on typing-sig. What I take away from this is that if you have a good idea, you don't *need* to put it through python-ideas, and if you do, getting shot down on python-ideas doesn't mean your idea is dead. But it *does* mean that if you take your idea to python-ideas, you have to accept that not everyone will like it, and be prepared to defend/justify it in *spite* of that. That's (in theory) OK, because it encourages you to focus on writing a PEP that contains objective reasons why your proposal is worthwhile. But it's also bad, because it makes python-ideas a hostile environment that puts new people off, and burns long-time contributors out. The ideas that I see failing here are often "I think X would be neat", or "We should do Y because it's like X which already exists". Those may not be bad ideas, but they need fleshing out. A PEP that says "a bunch of people on python-ideas things X would be neat" is not going to get accepted any more than one that just says that you think it's a neat idea. The *tone* on python-ideas is (unnecessarily) hostile, but I'd like to assume that the *intent* is helpful. For example, "why do you need X, we can already do it in this way" can be read as "your idea isn't needed", but it can also be read as "you need to think about why your idea is better than the current way, and be able to articulate that clearly and persuasively (for the PEP at least)". Personally, I *always* intend my responses to be taken as helpful, even if I sometimes get derailed into side-arguments about details where I'm not focused on the main proposal, and I then become more confrontational (I apologise that this happens, but I'm only human ;-)). Maybe things would be better if python-ideas were more positive, encouraging, and supportive. But I don't know how to make that happen - people didn't sign up here to mentor potential PEP authors, after all. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K7GD5POEE2WQEZOUBWUQKUOHW6DJCDHE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Sun, 6 Mar 2022 at 21:41, Christopher Barker wrote: > > >> Personally, I'm certainly not ignoring comprehensions. "for thing in >> (x for x in collection if is_interesting(x))" uses comprehensions just >> fine, if you don't like the verbosity of "x for x in", then that's an >> issue with comprehensions, not a reason why comprehensions don't >> address this issue, surely? (Personally, I find the repetitiveness of >> "x for x in" mildly annoying, but not enough to put me off >> comprehensions[1]). > > > Earlier on the thread, I made a similar point that it would be nice to have a > way to filter without the redundant for x in x. Though I can’t think of a > really good way to express it. But as for filtered for loops: > > "for thing in > (x for x in collection if is_interesting(x))" > > It not so much the extraneous “x for x” as the duplicated “for thing in” that > bugs me. > > I’m curious— to the skeptics: do you think that The above (or a later if > block) is just as good or better than > > for thing in collection if isinteresting(thing): > > Or just that it’s not worth it to make a change. I think that for thing in collection: if not isinteresting(thing): break ... is at least as good as for thing in collection if isinteresting(thing): ... and better in many ways (most importantly for me, it works in older versions of Python, which is important for libraries that support multiple versions). I think that for thing in (x for x in collection if isinteresting(x)): ... is only marginally worse, and not sufficiently worse to justify new syntax. > But the other part of why I think comprehensions are relevant is that > introducing anf if to the for statement is not brand new syntax - it would be > allowing existing syntax in a new context that is highly related. Agreed, this makes the impact of new syntax smaller. But I'm not really worried about that. It's not that it's a big change, just that it *is* a change, and there's a minimal cost for *any* change to the language definition. So someone has to care enough to pay that cost (in terms of writing a PEP, an implementation, and documentation, and in terms of going through the process of getting the change accepted). > And as for documentation and all that, it’s hard to imagine very many people > not understanding what it means. > > Do I care enough to write a PEP? No. So this, like many other small ideas, > will probably die on the vine. Yes, this is the real problem. It's simply not compelling enough, even for supporters of the idea, for them to do the necessary work to make it happen. > Oh well. Indeed. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WTZQQYSE3ZUVNCUK6PFPLVLQ3I6ZGR5D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Sun, 6 Mar 2022 at 01:55, Christopher Barker wrote: > > On Sat, Mar 5, 2022 at 4:33 AM Paul Moore wrote: >> >> for thing in filter(is_interesting, this_collection): >> ... >> >> That seems pretty non-clunky. Is the issue here that "filter" is not >> sufficiently well-known? Or that you don't want to name the >> is_interesting function, and lambdas are "too clunky"? This feels like >> another case where the general dislike of lambda results in people >> wanting special-case syntax so they can avoid either writing a >> throwaway function, or using lambda. > > > Speaking for me -- it's not a dislike of lambda -- it's a dislike of the map > / filter approach vs comprehensions in general. > I guess you could say I have a dislike for lambda -- but really it's a > dislike for having to create a function when an expression will do ;-) -- and > lamda only supports expressions, so it will always do. > > This entire conversation -- at least from the side of the skeptics -- seems > to be ignoring comprehensions: Personally, I'm certainly not ignoring comprehensions. "for thing in (x for x in collection if is_interesting(x))" uses comprehensions just fine, if you don't like the verbosity of "x for x in", then that's an issue with comprehensions, not a reason why comprehensions don't address this issue, surely? (Personally, I find the repetitiveness of "x for x in" mildly annoying, but not enough to put me off comprehensions[1]). I'm offering map/filter precisely *because* the people arguing for this construct don't seem to like the idea of using a comprehension. So IMO it's the supporters of the idea who are ignoring comprehensions (or don't want to use them for some unclear reason that seems to boil down to "it doesn't look nice"). Syntactically, the proposal is fundamentally just removing "x for x in" and a set of parentheses, in the special case where you don't also want to do a calculation on the item - you need to go back to the comprehension form if you need "for thing in (x.interesting_bit for x in collection if is_interesting(x))". Or, of course, you split it up: for x in collection: if not is_interesting(x): break thing = x.interesting_bit ... But maybe I just differ in how much I feel comfortable cramming into a single line...? > > If we all thought that map and filter were perfectly adequate, comprehensions > never would have been added at all. And not only were comprehensions added, > but both a looping and filtering mechanism was added at the same time. Let's > imagine for the moment that the filtering was not yet added -- then say the > way to run a filtered loop in a comprehension would be: > > [expr for thing in filter(lambda thing: expr, an_iterable)] > > Would anyone really largure that there would be no point in adding the filter > explicitly to get to (what we do have now): > > [expr1 for thing in an_iterable if expr2] > > The other relevant point is that adding an `if` to the for loop is new > syntax, yes, but it mirrors the comprehension syntax very closely -- so is > not nearly the cognitive load that most syntax additions are. Just because comprehensions are good, doesn't mean *everything* needs to look like them. Comprehensions are good because they are *expressions*, not because they are one-liners. For statements aren't expressions, they are statements, so having the filter be an extra statement isn't the problem that it is for a comprehension. > In fact, I imagine if newbies were to learn about comprehensions first, > they'd be surprised that there was no if allowed in for loops. Maybe, if that were a compelling argument, why don't *other* languages with comprehensions also have for loops with an if clause? > Yes, this is a fairly minor improvement, but to me it's not adding syntax to > "save a line" "or not have to use lambdas" -- but rather it's adding syntax > to make it possible to express a particular concept in a way that is clear, > obvious, and more consistent with the rest of the language (i.e. > comprehensions). > > I was +0, but after this discussion, now +1. I was, and remain, indifferent to the idea. I'm not against, but I don't see the point of all the energy being spent trying to persuade people this should be added. If anything, trying to explain why I find the arguments given in favour of the proposal weak, is simply making me less interested in the proposal - so I think the main result of this discussion is likely to be just to push people to more entrenched positions, and not change many minds. Which in general, is quite likely why discussions like this on python-ideas are so frustrating. IMO, if someone is interested enough, they can write a PEP. If th
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Sat, 5 Mar 2022 at 12:43, Chris Angelico wrote: > > The throwaway function is a *terrible* idea for a lot of situations, > because it puts the condition completely out-of-line. You have to go > dig elsewhere to find out the meaning of the filter. A lambda function > can work, but is about as clunky as the genexp. Using filter() is only > non-clunky in the specific situation where a function already exists > to do the filtration, and in my personal experience, that's been quite > rare. *shrug* I'm not sure I'd agree with you that throwaway functions are quite as terrible as you claim, but we're into the area of personal preference, so I'm not going to debate that one. But equally "let's have new syntax because some people find the current options unattractive" is a difficult argument to sell. So I'm still inclined to ask for something more objective. > > If we had "placeholder" expressions (see, for example > > https://pypi.org/project/placeholder/) so we could do things like > > > > from placeholder import _ > > for thing in filter(_%3==0, the_list): > > ... > > > > would that be sufficiently "non-clunky"? > > That is something I could get behind. I don't like the underscore, > since that usually means "meaningless", and would have to be carefully > managed to avoid shadowing; but that is definitely a possibility. I've not used the library extensively, and I'd encourage you to read the docs if you want details, but you can of course do "from placeholder import _ as X" (or whatever placeholder you prefer). > Does it work if you need to use the underscore twice? For instance, > what if you want to find long-running jobs, where "_.end - _.start > > 30" ? Yes. Again, check the docs for all the details, but this does work. > (This also still has the performance cost of filter and a lambda > function, which is a lot more than just having a bit of extra code as > part of the loop. But that's less significant.) >From the library docs, "Every effort is made to optimize the placeholder instance. It's 20-40x faster than similar libraries on PyPI" and "Performance should generally be comparable to inlined expressions, and faster than lambda". I've not done measurements myself, but I did do some investigation in the past, and the claims seem realistic. > > There are many ways of achieving this sort of result. Clearly, from > > the fact that this request comes up repeatedly, there's *something* > > unsatisfying about all of them, but I'm not entirely clear what > > particular problem is uniquely solved by new "for x in collection if > > condition" syntax, and not by any of the other possibilities? > > They are all clunky except in very specific circumstances, like > "iterate over the non-empty elements" or something. They don't > generalize well. I'm not sure how a for-if statement generalises any better than for ...: if not (condition): break So "doesn't generalize well" isn't the whole story here, I suspect. > > Personally, I don't mind having the if on a separate line, I find the > > generator expression tolerable but a bit verbose, and I'm glad > > "filter" and the placeholder library exist in case I need them, but > > I've never really found the existing options sufficiently annoying > > that I've wanted a for...if statement. > > And clearly a number of other people DO mind having it on a separate > line, because it's putting code in the body that belongs in the > header. I don't disagree, and if that's the argument, then I'm fine with that. > However, as I found out by writing PEP 671, there are enough people > who focus on the concrete that it's never going to happen. All you > have to do is keep on arguing against straw-men and eventually people > get weary of arguing the same unanswered arguments again and again. If someone were to implement this feature, I wouldn't object. In fact, I'd probably use it (not often, maybe, but I wouldn't actively avoid it). For comparison, though, I've yet to use an assignment expression, so don't put too much weight on "Paul would use it" as a measure of acceptability ;-) I think the problem here is that getting enthusiastic community support is always going to be hard, and as Python's user base gets bigger, any group of supporters looks smaller and smaller in comparison. "Everyone likes this, let's implement it" is probably the wrong way of getting language changes through these days, TBH (if indeed it ever was the right way...) But the PEP process is perceived (and presented) as a process of getting consensus, even though it isn't, really. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/POEAICESSJC7S6FEQ4QXVZC7AO5VBWYS/ Code of Conduct:
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Sat, 5 Mar 2022 at 12:12, Chris Angelico wrote: > > On Sat, 5 Mar 2022 at 22:22, Stephen J. Turnbull > wrote: > > > Python has one, and you've already mentioned it: > > > > for thing in (x for x in this_collection if is_interesting(x)): > > > > It's noticably verbose, but it's an exact translation of your > > statement of the abstract concept above. It has all the benefits of > > the proposed syntax except compactness[1]. > > It is extremely verbose, considering that the filtering part of a > comprehension uses the same variable name as iteration, doesn't need > anything to be repeated, and is just another clause. A simple > representation of that in a statement loop would be "for thing in > this_collection if is_interesting(thing):", which doesn't repeat > itself at all (the variable name "thing" is kinda essential to the > concept of filtration here, so I don't count that); and repetition > isn't simply about number of characters on the line, it's about > reducing the potential for errors. (Plus, the genexp adds a > significant amount of run-time overhead.) > > So you're right, I stand (partly) corrected: there IS a very clunky > way to spell this concept. > > What Python needs is a non-clunky way to express this. for thing in filter(is_interesting, this_collection): ... That seems pretty non-clunky. Is the issue here that "filter" is not sufficiently well-known? Or that you don't want to name the is_interesting function, and lambdas are "too clunky"? This feels like another case where the general dislike of lambda results in people wanting special-case syntax so they can avoid either writing a throwaway function, or using lambda. If we had "placeholder" expressions (see, for example https://pypi.org/project/placeholder/) so we could do things like from placeholder import _ for thing in filter(_%3==0, the_list): ... would that be sufficiently "non-clunky"? There are many ways of achieving this sort of result. Clearly, from the fact that this request comes up repeatedly, there's *something* unsatisfying about all of them, but I'm not entirely clear what particular problem is uniquely solved by new "for x in collection if condition" syntax, and not by any of the other possibilities? Personally, I don't mind having the if on a separate line, I find the generator expression tolerable but a bit verbose, and I'm glad "filter" and the placeholder library exist in case I need them, but I've never really found the existing options sufficiently annoying that I've wanted a for...if statement. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2YPLCIZVUIK4OIC7SNGVP3T6BEMIGJ2Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Wed, 2 Mar 2022 at 10:27, Steven D'Aprano wrote: > Off-topic, but since you raised the issue... is there a standard > functional programming term for a variant of map() that applies a single > argument to a series of different functions? > > # regular map > map(func, list_of_args) # (func(arg) for arg in list_of_args) > > # variant map? > map(arg, list_of_funcs) # (func(arg) for func in list_of_funcs) That sounds like what I've heard referred to as "map apply". I don't think functional languages tend to have a particular name for it, because it falls naturally out of the syntax for mapping and functional application. (And as you show, Python is similar - the generator comprehension is easy enough that a named function is not often useful). Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TZI6ZX2PYE6MDADDLPTBUUVPFNYPGEJK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Requirements.txt inside virtual environment
On Fri, 18 Feb 2022 at 23:53, Steven D'Aprano wrote: > When pip resolves dependencies, it does it in the simplest possible way > that *usually* works. It has no satisfiability solver. > > "No effort is made to ensure that the dependencies of all packages are > fulfilled simultaneously. This can lead to environments that are broken > in subtle ways, if packages installed earlier in the order have > incompatible dependency versions relative to packages installed later in > the order." > > https://www.anaconda.com/blog/understanding-conda-and-pip This is no longer true - pip incorporated a proper dependency resolver in 2020. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RL4UQMN2E7XZHY45AKOJ7XZNZEWSRM7O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Regex pattern matching
On Wed, 16 Feb 2022 at 14:47, Valentin Berlier wrote:
>
> Hi,
>
> I've been thinking that it would be nice if regex match objects could be
> deconstructed with pattern matching. For example, a simple .obj parser could
> use it like this:
>
> match re.match(r"(v|f) (\d+) (\d+) (\d+)", line):
> case ["v", x, y, z]:
> print("Handle vertex")
> case ["f", a, b, c]:
> print("Handle face")
>
> Sequence patterns would extract groups directly. Mapping patterns could be
> used to extract named groups, which would be nice for simple
> parsers/tokenizers:
>
> match re.match(r"(?P\d+)|(?P\+)|(?P\*)", line):
> case {"number": str(value)}:
> return Token(type="number", value=int(value))
> case {"add": str()}:
> return Token(type="add")
> case {"mul": str()}:
> return Token(type="mul")
>
> Right now, match objects aren't proper sequence or mapping types though, but
> that doesn't seem too complicated to achieve. If this is something that
> enough people would consider useful I'm willing to look into how to implement
> this.
I'm not sure I really see the benefit of this, but if you want to do
it, couldn't you just write a wrapper?
>>> class MatchAsSeq(Sequence):
... def __getattr__(self, attr):
... return getattr(self.m, attr)
... def __len__(self):
... return len(self.m.groups())
... def __init__(self, m):
... self.m = m
... def __getitem__(self, n):
... return self.group(n+1)
...
>>> line = "v 1 12 3"
>>> match MatchAsSeq(re.match(r"(v|f) (\d+) (\d+) (\d+)", line)):
... case ["v", x, y, z]:
... print("Handle vertex")
... case ["f", a, b, c]:
... print("Handle face")
...
Handle vertex
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/LCWHARNW5OOCY7CHCXC5CVGFH4OAFOEW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Regex timeouts
On Wed, 16 Feb 2022 at 10:23, Chris Angelico wrote: > > On Wed, 16 Feb 2022 at 21:01, Stephen J. Turnbull > wrote: > > What I think is more interesting than simpler (but more robust for > > what they can do) facilities is better parser support in standard > > libraries (not just Python's), and more use of them in place of > > hand-written "parsers" that just eat tokens defined by regexps in > > order. If one could, for example, write > > > > [ "Sun|Mon|Tue|Wed|Thu|Fri|Sat" : dow, > > ", ". > > "(?: |\d)\d)" : day, > > " ", > > "Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec" : month, > > " ", > > "\d\d\d\d" : year, > > " ", > > "\d\d:\d\d:\d\d" : time, > > " ", > > "[+-]\d\d\d\d" : tzoffset ] > > > > (which is not legal Python syntax but I'm too lazy to try to come up > > with something better) to parse an RFC 822 date, I think people would > > use that. Sure, for something *that* regular, most people would > > probably use the evident "literate" regexp with named groups, but it > > wouldn't take much complexity to make such a parser generator > > worthwhile to programmers. > > > > That's an interesting concept. I can imagine writing it declaratively like > this: > > class Date(parser): > dow: "Sun|Mon|Tue|Wed|Thu|Fri|Sat" > _: ", " > day: "(?: |\d)\d)" I find it mildly amusing that even this "better" solution fell victim to an incorrect regexp ;-) However, I do like the idea of having a better parser library in the stdlib. But it's pretty easy to write such a thing and publish it on PyPI, so the lack of an obvious "best in class" answer for this problem suggests that people would be less likely to use such a feature than we're assuming. The two obvious examples on PyPI are: 1. PyParsing - https://pypi.org/project/pyparsing/. To me, this has the feel of the sort of functional approach SNOBOL used. 2. parse - https://pypi.org/project/parse/. A scanf-style approach inspired by format rather than printf. Do people choose regexes over these because re is in the stdlib? Are they simply less well known? Or is there an attraction to regexes that makes people prefer them in spite of the complexity/maintainability issues? Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MAVVUR2L3GKXJLAXZUULSFQT5PDCZWMI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
On Sun, 13 Feb 2022 at 15:43, Chris Angelico wrote:
>
> Which is why the default should be to follow platform expectations. If
> I pass a parameter to a script saying "~/foo/bar", that script should
> be able to expanduser/expandvars to make that behave the way I expect
> it to. If I'm on Windows and I tell something to write to a file in
> "%TEMP%\spam.csv", then I expect it to understand what that means.
> Cross-platform support is nice, but the most common need is for the
> current platform's normal behaviour.
For better or worse, though, Windows (as an OS) doesn't have a "normal
behaviour". %-expansion is a feature of CMD and .bat files, which
varies depending on the Windows version and the version of CMD. A
significant proportion of command line programs on Windows are ported
from Unix and add (some form of) Unix-like behaviour, either as well
as, or instead of, % expansion. Remember, I'm supporting the existing
behaviour as "good enough" here. I'm not the one advocating change. If
you believe that "the current platform's normal behaviour" is anything
other than what os.path.expandvars does, then the onus is on you to
define what you mean.
But I thought the debate here was about "putting a version of
expandvars into pathlib". Maybe someone ought to define what that
means, in practice.
Oh, and just for fun, I just discovered that expandvars does (arguably
broken) quoting, too:
>>> os.path.expandvars("$USERNAME")
'Gustav'
>>> os.path.expandvars("'$USERNAME'")
"'$USERNAME'"
>>> os.path.expandvars("'%USERNAME%'")
"'%USERNAME%'"
Note that it *keeps* the quotes. That's *definitely* not normal
platform behaviour on Windows...
But anyway, I thought the debate here was about "putting a version of
expandvars into pathlib". Maybe someone ought to define what that
means, in practice.
Remember to make sure that the documentation of Path.expandvars()
makes it clear why (Path("Dev team's docs") / Path("${USER}'s files")
/ Path("somefile.txt")).expandvars() returns Path("Dev team's
docs/${USER}'s files/somefile.txt") and not Path("Dev team's
docs/Gustav's files/somefile.txt"), so that people don't report it as
a bug... Yes, they might do the same with os.path.expandvars, but
that's easily responded to - "documentation bug, the docs should
mention quoting and should emphasise that the operation treats the
argument as a string, not as a path". I'm not sure the same response
works when it's a method of a Path object ;-)
And I repeat, *please* remember that I'm not the one arguing for
change here, I'm arguing that the proposed change is potentially more
complex than people are suggesting, and that actually, the benefit
isn't sufficient to justify the work. Although as it's not clear yet
who is offering to do the work, it may be premature of me to make that
argument...
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/7VYTLU2MANE4SXNJBRHVBHLHR25NUTE6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
On Sun, 13 Feb 2022 at 14:26, Stephen J. Turnbull
wrote:
>
> Paul Moore writes:
>
> > Let's keep it simple. I'm -1 on the request, I don't think expandvars
> > should be added to pathlib.
>
> Would you be happier with a getenv_as_path, so that one could do
>
> p = Path.getenv_as_path('HOME') / Path('.python_history')
>
> and on my Mac p == Path('/Users/steve/.python_history')?
I don't think *any* of this is much better than the status quo:
p = Path(os.getenv("HOME")) / ".python_history"
The main point I see of expandvars is to have a way of letting the
*user* pass a string that might reference environment variables, and
expand them. There's some problematic aspects of that already, namely
the platform-dependent handling of % symbols. I assume that the
intended use case for expandvars, based on the fact that it's in
os.path, is to allow expansion of a variable containing a directory
name, such as $HOME, as in the example you give. And that's mostly
fine. Windows has some weirdness in that some environment variables
can (I think) contain trailing backslashes (it definitely happens with
batch file substitution variables, I haven't been able to find an
example with environment variables, but I wouldn't bet either way,
given how the extremely limited capabilities of batch files can get
used to (clumsily) set environment variables at time (look at some of
the wrapper scripts for Java apps, for examples). Again, that's
probably fine, as sequences of multiple slashes and backslashes should
get normalised. But again, I wouldn't be 100% sure.
file_next_to_bat_wrapper = os.path.expandvars("%BATFILE_DIR%the_file.txt")
is a Python translation of a *very* common batfile idiom, where %~dp0
is "the directory containing the bat file", which has a trailing
slash, and you need to *not* add an extra slash if you don't want
later filename parsing (in a bat file) to get confused. I can easily
imagine someone who's new to Python using this sort of idiom by
analogy, and then getting bitten by a variable with no trailing slash.
*shrug* As I say, my arguments are mostly "from experience" and "vague
concerns" - which people, notably the other Steven, have dismissed
(with some justification). Generally, I think that expandvars is
mildly risky, but perfectly fine for simple use. People wanting to
write high-reliability production code should probably think a bit
harder about what they actually want, and whether the limitations of
expandvars are acceptable for their needs. I'd be surprised if after
doing so, they didn't write their own custom parser (we did for pip,
I'm pretty sure). I think that expending a lot of effort trying to
"improve" expandvars is probably not going to make it much more useful
for that latter group. It might make it more discoverable, and just
possibly more convenient, for people who won't have a problem with its
limitations, but it might *also* make some people who should use a
custom solution, think it's fine and use it when they shouldn't.
To be honest though, I'm not sure of the point of trying to persuade
me. I'm fairly fundamentally opposed to changing anything here, but I
can't express my reservations in a way that will persuade anyone else.
Which is fine. Conversely, if you manage to change my mind, it's not
likely to make much difference - no-one is going to write or merge a
PR purely on the basis that I stopped objecting to the idea ;-)
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/5S2YHOI6Q4AI37ULCU2VYK3NWWEWAVBN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
On Sun, 13 Feb 2022 at 01:09, Steven D'Aprano wrote: > I'm sorry Paul, but this sort of made-up, utterly artificial toy example > adds no benefit to the discussion, it just adds fear, uncertainty and > doubt to an extremely straight-forward feature request. OK, if that's your view then fine. I agree the example was made up, although I dispute "utterly artificial", as it reflects a genuine concern I have, it's just not one that I can find or construct a non-artificial example for right now. But yes, the example wasn't good. Let's keep it simple. I'm -1 on the request, I don't think expandvars should be added to pathlib. I think os.path isn't a very good place for it currently, but it's what we have. I'm not massively enthusiastic about it being in shlex, but I can't think of a better place for it. So I'm inclined to stick with the status quo, or if it's *really* worth doing anything, move it to shlex. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MALPP3GV7NGLQKSUG4BW2ZIRGIRH6PLS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
On Sat, 12 Feb 2022 at 16:02, Chris Angelico wrote:
>
> On Sun, 13 Feb 2022 at 02:57, Eric V. Smith wrote:
> > See Paul’s example, copied above. Maybe the code isn’t expecting it.
> >
>
> There wasn't an actual example, just a hypothetical one. I have never
> once seen something in real usage where you interpolate environment
> variables into a path, without expecting the environment variables to
> be paths.
>
> It's different with URLs, but pathlib doesn't handle URLs, it handles paths.
My example was not intended to illustrate that having slashes within
variables wasn't reasonable, but rather that concatenating a string to
a variable without an intervening slash *could* be confusing. But
equally it might not be:
backup = os.path.expandvars("${ORIGFILE}.bak")
The point I was trying to make is that thinking of expandvars as
acting on strings is straightforward, whereas thinking of the operands
as paths can lead to expectations that might be wrong. I'm arguing
that we should not link expandvars with paths, even though
historically it's part of os.path.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BDJ6WRBBACUFQIFIUHPE2M5VYAFAVBVF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
On Fri, 11 Feb 2022 at 18:36, Eric Fahlgren wrote: > > Yeah, I have to agree with Neil. I had exactly this issue a couple years > ago, and it took me an hour or two to figure out that it was a > property/descriptor-protocol causing the issue, at which point the fix became > trivial. Just knowing to think "it's a property, stupid!" was the hard part > and just stating that in the error message would have saved me the > frustration. I'm inclined to say just raise an issue on bpo. If it's easy enough, it'll just get done. If it's hard, having lots of people support the idea won't make it any easier. I don't think this is something that particularly needs evidence of community support before asking for it. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FSKUTUAMA4A4EK5BN7UPCHZ3D4GF6X74/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
On Fri, 11 Feb 2022 at 16:37, Christopher Barker wrote:
>
> On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka wrote:
>>
>> expandvars() does not operate on paths, it operates on strings and
>> bytestrings. There is nothing path-specific here. Expanding environment
>> variables consists of three distinct steps:
>
> sure -- but it does live in os.paths now, the docs talk about paths, and it
> is useful for paths -- so it seems a fine idea to have that functionality in
> pathlib.
One way that tying it to paths is bad is that it ignores the path
structure. If environment variable a is "d1/f1" and b is "d2/f2" then
"${a}x${b}" is "d1/f1xd2/f2", which could be very confusing to someone
who sees the value of b and expects the result to be a file in a
directory called d2. Yes, I know that the documentation could make
this clear (the docs in os.path don't, BTW) and I know that it's no
different than the os.path version, but adding an expandvars method to
pathlib feels like throwing good money after bad...
Let's leave it where it is and keep the status quo, or fix it
*properly* and put it somewhere more logical like shlex. Personally I
don't use it that often, so I'm fine with just leaving it alone.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2XSYXAFLMMVGJDYJYRM2CDZO2WV5YDX6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Datetime operation in itertools count
On Thu, 10 Feb 2022 at 17:11, Christopher Barker wrote: > agreed. But we seem to be getting a mixed message here: > > 1) it's too coplex with too many variable that have to be thought through and > won't satisfy everyone anyway. > > and > > 2) It's just a simple one-liner > > Those are kind of incompatible ideas ;-) Indeed, so which is being proposed here? My answer is the same in both cases (I don't think it's worth adding to the stdlib) but which justification I need to express depends on which option is being proposed :-) > This feels to me not so different then math.isclose() -- not that complex, > but complex enough that it's good to put a well thought through > implementation in the stdlib. Maybe. It still needs someone to get down to details and propose something specific. And I'll still be between -0.5 and -1 on it, but you don't need to convince me personally, you just need some level of support from *some* of the core devs, and/or broad community support sufficient to persuade at least one core dev to merge a PR implementing the idea. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WXP7GWZ4G2UNPPKICX7KXIHR3RFHXBFX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Datetime operation in itertools count
On Thu, 10 Feb 2022 at 16:44, Christopher Barker wrote: > > Since a started this:-) > > 1) the complexities are exactly why this *might* be a candidate for the > stdlib. Those are the things that someone is likely to get wrong, or not > think of, when they write something quick themselves, and only lightly test. Fair. But no-one has come up with a use case to justify doing the work to handle those complexities. All the discussion has tended to be around how it "wouldn't be too hard". > 2) it doesn’t have to be everything for everyone- it has to be many things > for many (most) people. Agreed, but that's mostly just a matter of degree. At a minimum, if it deliberately omits certain situations, those need to be documented. Otherwise there's a maintenance cost from people asking for such support and debating whether it's "implied" by the existence of the function in the stdlib. > 3) DST is a nightmare, plain and simple. The datetime module was useful for > years even before it gained the ability to deal with it at all.[*] > [*] now that I think about it, I would probably only do this without DST — > including DST would require a DST database, which the stdlib doesn’t include. https://docs.python.org/3/library/zoneinfo.html Having a stdlib function that handles range-type sequences for dates, but does not handle the various timezone-aware datetime types is bound to cause some level of confusion. Having said that, maybe it's simple to do this right. That's my point, someone needs to do the work to think all this through. I'm not *against* the idea, I just don't think it's worth the effort given the (fairly trivial) benefits that have been claimed so far. In particular, I have no use for it personally - the one-liners already posted in this thread would be perfectly fine for any use I can imagine, and I see no reason to add such one-liners to the stdlib. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QQ5XGZPZ7GUJDOK5HE4M5DADNLLN5J6F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Datetime operation in itertools count
On Thu, 10 Feb 2022 at 15:21, Aman Pandey wrote: > > Hello Stephen, I think you misunderstood it. we are not talking about > modifying the existing built-in function range rather adding a new function > in datetime module that will generate the date and time between two periods. > if we add a function like that in the datetime module the code will be > exactly like the one you gave. > Christopher was mentioning that he visualizes that function in the datetime > module as something similar in syntax and execution like the built-in range > function. > > what do you think if we add some function like that in datetime module > wouldn't it be helpful? I think something like this might occasionally be helpful. However, for simple examples, it's pretty easy to write your own, sufficiently so that people would expect more of a stdlib version. And understanding the edge cases, correctly handling them, and designing an API which makes the function easy to use while still having the power to cover everyone's use cases, is a *lot* harder. It's that part of the problem that is receiving the pushback here. To give a concrete example, consider a range with a start of 1:30am on a particular day, and a step of 1 day. If the range extends over a DST change, then there's one day in the range where either there are no valid 1:30am times, or there are *two*, equally valid 1:30am times (depending on whether the clock is "going forwards" or "going backwards"). What should the stdlib function do in this case? How should the function deal with the fact that people can legitimately expect different behaviours (for some applications "raise an exception" could be the only safe option, for others, "use the nearest valid time" might be)? Having flags that pick between different behaviours scales badly, and is typically not a good design. For your own code, you can write the behaviour that works best for you, and for your application. For the stdlib, the behaviour has to address the needs of *everyone*. My feeling is that the complexity of a "does the right thing for everyone" stdlib implementation would outweigh any benefit gained from not having to write your own short function, tailored to your particular needs. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5BNPSKGEJ6WE2GBYO4FGG5NMXXRJHJ7S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Datetime operation in itertools count
On Tue, 8 Feb 2022 at 14:00, Aman Pandey wrote: > > I wanted to generate all the dates between two date ranges for which I was > using count function in the itertools and to my surprise count function > doesn't support datetime operation. > > For example > >import datetime > >from itertools import count > >count(datetime.date.today(), datetime.timedelta(1)) > > Why is count function only limited to numbers shouldn't we make it generic > that it should support operation like datetime where addition between the > objects is possible. Because it's implemented in C for speed, and limiting it to numbers makes it both easier to implement (in C) and faster. > Would like to hear thoughts from you people. start = date.datetime.today() (start + datetime.timedelta(n) for n in count()) does exactly the same as your code does, so it's not *that* hard to get the functionality you want already. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/H5KBZIBFRSVFW2ZWDCHU4CXJ5X36COWU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Consider moving abstract method checking logic from ABCMeta into object
On Tue, 8 Feb 2022 at 00:09, Neil Girdhar wrote: > > Currently, some type checkers rightly complain that a method is decorated > with abc.abstractmethod when the class's type does not inherit from ABCMeta. > Adding a metaclass is a fairly heavy dependency since you're forced to poison > all of your other metaclasses with the same base metaclass. It also brings > in possibly unwanted type registration that ABC comes with. > > Now that abstractmethod's usage is extremely well-understood, would it make > sense to move the checking logic out of ABCMeta? > > It could either be put into object so that no base class is necessary (at the > cost of slightly slower class creation), or else in a non-meta base class > (say, HasAbstractMethods) now that __init_subclass__ is in all extant > versions of Python. Inheriting from such a non-meta base class would avoid > the poisoning problem described above. > > As far as I can tell, neither solution breaks code. If it's valid usage, why not just get the type checkers fixed? Or if, as you say, the type checkers are complaining correctly, why do you want to do it? Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZDRY7S56HX5HPBWPHRWG5EAHPW5QNQTF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Limit scope of variables using round brackets
On Mon, 17 Jan 2022 at 18:51, John Sturdy wrote: > > My idea is to support the style in which each variable comes into existence > at a single well-defined point, whatever path is taken through the code, and > so in the case of that example, it would be encouraging the use of > conditional expressions. But that's a style that Python explicitly rejected right back when it was first designed, and it's fundamental to the language that you *don't* explicitly declare variables. So sorry, but it's never going to happen[1]. If you want to be really precise, technically "the style in which each variable comes into existence at a single well-defined point" is actually what Python already does. The "well-defined point" is the start of the scope (function or class definition) where the variable is used, though, and not at some new "let" keyword. To see this, look at the following: >>> def f(): ... print(n) ... n = 1 ... >>> f() Traceback (most recent call last): File "", line 1, in File "", line 2, in f UnboundLocalError: local variable 'n' referenced before assignment The variable "n" exists when the print statement runs (it's unbound, but it exists - that's what the exception says), and that's because the variable comes into existence at the *start* of the scope (function). And the choice to only have a limited number of ways to define scopes is *also* a fundamental design principle of Python, so arguing that suites should each define their own scope won't get you very far either. Essentially, you're proposing to change Python to no longer be Python, in some fairly fundamental ways. Don't be surprised if you get very few supporters for your idea... Paul [1] In theory, the SC could say that such a change is fine, but I can't see that ever happening. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QTSJEOV4K2USOL6UWXKMU5UOYXKTHZ2W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Limit scope of variables using round brackets
On Mon, 17 Jan 2022 at 17:27, Christopher Barker wrote: > But this is not how Python works, and it never has, it would be a really > massive change, and I for one, would not like it :-( I agree with this. > I guess what I'm getting at is that I'm pretty sure I would find this useful > rarely, and an annoyance often. And this. To be perfectly honest, I think a change like this would basically be turning Python into a different language (and not one I'd like). Even if it were done as the OP suggests using a "let" keyword to make it (technically) "optional", I'd end up seeing it in other people's code, and possibly being expected to deal with it on projects I'd be working on, and I'd hate that. So not for me, sorry. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GVEKMURRJNS62AUPST7PIPJYY4UCT3ML/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On Mon, 17 Jan 2022 at 10:12, Steven D'Aprano wrote:
> That would make the creation of frozensets more efficient, possibly
> encourage people who currently are writing slow and inefficient code
> like
>
> targets = (3, 5, 7, 11, 12, 18, 27, 28, 30, 35, 57, 88)
> if n in targets:
> do_something()
>
> to use a frozenset, as they probably should already be doing.
More realistically, would they not use a set already, as in
targets = {3, 5, 7, 11, 12, 18, 27, 28, 30, 35, 57, 88}
if n in targets:
do_something()
?
Is using a frozenset a significant improvement for that case? Because
I doubt that anyone currently using a tuple would suddenly switch to a
frozenset, if they haven't already switched to a set. Sure, there
might be the odd person who sees the release notes and is prompted by
the mention of frozenset literals to re-think their code, but that's
probably a vanishingly small proportion of the audience for this
change.
BTW, I should say that I'm actually +0.5 on the idea. It seems like a
reasonable thing to want, and if an acceptable syntax can be found,
then why not? But I doubt it's going to have a major impact either
way.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EYQC3PH3W24K7NTQ66KB3DL334LYDK5A/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On Mon, 17 Jan 2022 at 01:11, Chris Angelico wrote:
>
> On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
> >
> > On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > > >>> def f():
> > > ... return frozenset({1, 2, 3})
> > > ...
> > > >>> a = f.__code__.co_consts[1]
> > > >>> a
> > > frozenset({1, 2, 3})
> > > >>> b = f()
> > > >>> assert a == b
> > > >>> a is b
> > > False
> > >
> > > Each time you call the function, you get a distinct frozenset object.
> >
> > I may just be reiterating your point here (if I am, I'm sorry - I'm
> > not completely sure), but isn't that required by the definition of the
> > frozenset function. You're calling frozenset(), which is defined to
> > "Return a new frozenset object, optionally with elements taken from
> > iterable". The iterable is the (non-frozen) set {1, 2, 3}.
>
> Where is that definition?
https://docs.python.org/3/library/functions.html#func-frozenset
> According to help(frozenset), it will
> "[b]uild an immutable unordered collection of unique elements", so it
> doesn't necessarily have to be a brand new object.
I'd read "build" as meaning it is a new object. But regardless, I view
the language documentation as authoritative here.
> With mutables, it
> does have to return a new one every time (list(x) will give you a
> shallow copy of x even if it's already a list), but with immutables,
> it's okay to return the same one (str and tuple will return self).
That's an optimisation, not a guarantee, so while it's relevant, it's
not sufficient (IMO).
However, it's not clear how relevant this is to the actual proposal,
so the precise details probably aren't that important.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/7ISKPLVO3KFDGMQL5UKNBGO3QGVZWFNA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> >>> def f():
> ... return frozenset({1, 2, 3})
> ...
> >>> a = f.__code__.co_consts[1]
> >>> a
> frozenset({1, 2, 3})
> >>> b = f()
> >>> assert a == b
> >>> a is b
> False
>
> Each time you call the function, you get a distinct frozenset object.
I may just be reiterating your point here (if I am, I'm sorry - I'm
not completely sure), but isn't that required by the definition of the
frozenset function. You're calling frozenset(), which is defined to
"Return a new frozenset object, optionally with elements taken from
iterable". The iterable is the (non-frozen) set {1, 2, 3}.
The function
def f1():
return f{1, 2, 3}
(using f{...} as a frozenset literal) does something different - it
returns the *same* object, compiled once at function definition time,
every time it's called.
So frozenset literals would allow us to express something that we
can't currently express (at least not without going through some
complicated contortions) in Python. I'm not sure it's a particularly
*important* thing to be able to do, but whatever ;-)
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/K5DDGSLSMVFA35HLWFJE43XYOKSPAWWL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Applications user/system directories functions
https://pypi.org/project/platformdirs/ is intended to cover this sort
of requirement.
Paul
On Wed, 15 Dec 2021 at 13:47, JGoutin via Python-ideas
wrote:
>
> Hello,
>
> The idea is to add 3 functions to get "config", "data" and "cache"
> directories that are commonly used to store application files in user home /
> system.
>
> This look very straightforward to get theses directories path, but in
> practices it depends on many factors like OS, environnement variables, user
> or system dir.
>
> For instance, with the "config" directory:
> * Linux, user: os.path.join(os.getenv("XDG_CONFIG_HOME",
> os.path.expanduser("~/.config")), app_name)
> * Linux, system: os.path.join("/etc", app_name)
> * Windows, user: os.path.join(os.path.expandvars("%APPDATA%"), app_name)
> * Windows, system: os.path.join(os.path.expandvars("%CSIDL_COMMON_APPDATA%"),
> app_name)
>
> For linux, the full spec is here:
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> I see many applications that just use "~/.app_name" to not have to handle
> theses cases.
>
>
> The functions prototypes may look like and may be added to "shutil" (or
> "os.path" ?):
>
> def getcachedir(app_name: str=None, system: bool=False):
>
> With
> * app_name: The application name
> * system: If the required directory is the systemd directory or user
> direcotry.
>
>
> This may also be implemented as an external library, but I am not sure I
> would like add add a dependency to my projects "just for this".
>
>
> I can implement this if people are interested with this feature.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MHEWO4U6SBDU7OU3JH4A62EWCANDM7I2/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JZ4D2ZLW4XAESJ4EPBB2UWJODTJSNVBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
On Thu, 9 Dec 2021 at 20:55, deavid wrote: > > So well, my question here is: why is this not a thing? Has anyone proposed > something like this before? I feel I must have missed something important. IMO, making types mandatory would severely penalise the use of Python for scripting, exploratory coding, and similar adhoc work. This is a significant part of the user base, and we have to consider such users. Having typing as optional allows those people who get benefits from typing to achieve those benefits without impacting others who don't need that level of strictness. So basically -1 from me. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RKKBRWC5WTHUQNPAF3QUWISTXZMISHHP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Thu, 9 Dec 2021 at 11:51, Chris Angelico wrote:
>
> Are = and := confusing? They are also very similar, and they have some
> subtle distinctions. Is it a problem for two different operators to
> look similar when they do very similar things?
Maybe. I don't use assignment expressions - I don't really have any
good uses for them. And no project I maintain is able to use them yet
as we support older Python versions. So I'm honestly not sure. I'd be
more concerned about confusing := and ==, as both can appear in the
same expression. But again I don't know.
And I don't know *for certain* about =>. It's a concern, not a
showstopper. No-one has yet (as far as I can recall) shown real-life
cases, such as a PR against an existing project that changes code to
use the new syntax. There's no requirement on a PEP to do that much
work up front, so I'm not demanding that you do. But I'll remain
concerned about confusability until I see some "real world" evidence
like that. And like with assignment expressions, the PEP might still
get accepted even though I'm concerned.
> Argument defaults look like assignment because it makes sense for them
> to look like assignment. That's not an accident.
I didn't say it was. But there comes a point when too many things all
look like X because they are similar to X, and we run out of easily
distinguishable variations. Are we at that point yet? I don't know.
Might we be? In my opinion, yes we might. And the PEP should document
*your* view on the question, which can be "I think it's fine, but
everyone disagrees with me", or "the majority of people on the list
think it's OK", or "there were concerns expressed but they were all
theoretical and I believe the benefits of this proposal outweigh the
theoretical risk". Or whatever. It's your PEP, not mine. Your view is
what should be in there.
> If this is accepted, it will become a standard idiom to see "=>[]" or
> "=>{}" or whatever, and seeing "=[]" will continue to look wrong. I
> think you're underestimating people's ability to understand code.
I think you're (at a minimum) overestimating *my* ability to spot
mistakes like this. I'm certain that I've missed similar things in
reviews in the past. Maybe I'm not typical. Maybe you're thinking more
of people writing their own code, and less about maintainers reviewing
externally submitted code. Or maybe projects will define standards and
good practices that prohibit over-use of late-bound defaults, or
prefer None sentinels where possible, or just impose a general "keep
it simple" rule and use that to minimise the risk of confusion.
And maybe people will end up cargo culting "you use => for mutable
values like [] or {}, and = for everything else" and not actually
understanding when values get bound at all. And people do the right
thing by accident, so everything is fine (sort of).
> But maybe we ARE using the term "confusing" in different ways. Maybe
> I'm trying to respond to completely the wrong thing. If the concern is
> that the new syntax is "confusing" but I'm interpreting that word
> wrongly, please clarify.
I think your responses above are addressing what I mean by
"confusing". But your responses are essentially that you don't agree
with me. That's fine, and I'm not demanding that we have to agree
here. But to be a fair reflection of the discussion, the PEP should
note this concern and be clear that there was disagreement with your
position. That is literally all I am asking here.
If the PEP ends up containing a section with a list of concerns people
have, and your statement that you don't agree with them, that's 100%
fine. Maybe it makes the PEP less persuasive. I don't have a problem
with that - after all, I'm the one arguing that the status quo is
fine. You're the one arguing that the change is worth making, so
presumably you believe the section in the PEP that describes the
benefits of this change outweighs this.
> > > I'm not sure what concerns need to be addressed, because I don't
> > > understand the concerns.
> >
> > Fair, but you can state them, surely? Even if you're just copying what
> > people say into the PEP, and noting that these are open issues that
> > the PEP author cannot address without further explanation of the
> > issue, that's better than having nothing (and having the same
> > objections raised over and over again). At the moment the PEP doesn't
> > even *have* an "open issues" section.
>
> No, I can't, because every time I try to pin down actual issues, they
> slip away. I can't nail jelly to the PEP.
Rob Cliffe did an excellent summary. Just copy and paste that. If you
really don't understand any of the points in spite of his summary and
everyone's comments, just note in the PEP that this was the objection
and it's not been addressed because you didn't understand what the
problem was. And move on.
> > > EVERYONE is arguing against the proposal.
> >
> > So your response to my concern that opinion is divided on the PEP, is
> > to say that
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Thu, 9 Dec 2021 at 06:49, Christopher Barker wrote: > > (I started writing this this morning, and there’s been quite a bit more > discussion since, but I don’t think it’s completely too late) Your email client is doing "white on white" again. You should try to get that fixed :-( I agree, without an actual proposal for how deferred expressions work, it's impossible to be specific about what might be affected. And holding one proposal hostage to something that might never happen isn't reasonable. So I'm happy to class a lot of the discussion about deferred expressions as off-topic. My point was more specific, though - that whenever deferred expressions have been discussed in the past (and they do come up every so often) it's fairly clear that one case they would be expected to handle would be calculating function defaults at call time (at least, that's my impression). So if they ever do get implemented, they would render this PEP obsolete. I'm not aware of any case where we've added a language feature knowing that people were interested in something strictly more general. Indeed, switch statements were rejected for years because they "weren't general enough", without any specific more general feature being on the table. So my objection is that I don't see why this particular PEP warrants an exception to that precedent, and why in this specific case, "never is often better than *right* now" doesn't apply. What's changed to make late bound defaults worth fixing right now? That's *not* a rhetorical question - I'm happy if someone can tell me, if now is the right time to do this, then what's different about getting this in 3.11, as opposed to 3.8, or 3.14? And I'm fine with an imprecise answer here - assignment expressions got in mostly because "they've been asked about for years, we have the momentum right now, and Guido wants to do it". If the argument here is similarly imprecise, that's fine - a precise argument would be *stronger*, but a lot of the concerns being raised are imprecise, I'm not expecting to hold the responses to a standard the concerns don't achieve. But I would like a response. Paul PS While I'm posting, a *huge* thanks to Rob Cliffe for preparing and posting that summary of the concerns. That was extremely helpful. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7MQO2MTRBHTUD5HIE5G4XHHP5TNAI6VR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Wed, 8 Dec 2021 at 23:40, Chris Angelico wrote: > > I have attempted to explain the syntax. What is confusing? > > def f(x=spam): ... > > def f(x=>spam): ... Are we using the term "confusing" in different ways? I'm saying that it's easy to confuse the two forms = and =>, as they look very similar, and in many (nearly all?) cases, do exactly the same (although I assume => would be slower, as I doubt the compiler would be able to tell that it could optimise away an unnecessary late binding). It's not that I find the syntax or semantics hard to understand, but that the two forms are easily confused with each other. And it's not that I can't see which is which on a careful reading. It's in a maintenance context where I imagine the issues - a PR that includes a typo using = instead of =>, which doesn't get picked up in code review because the reviewer missed the typo. Or a function that uses a default of =[] when =>[] was intended, and gets a subtle timing error that the tests don't pick up and reviewers misread as "using that late binding syntax" rather than thinking "=[] is a known gotcha". Note that the same argument applies for a lot of alternative spellings as well: :=, >=, =:, ?=, all have the same problem. It's more the structure that's the issue. And yes, I know people don't confuse a+b and a-b. This is a people problem, so it can't be dealt with by applying a set of objective, mechanical rules on what works and what doesn't. But that doesn't mean it's all opinion. User interface design (which is what this is, essentially) is *hard*, unfortunately. I suspect your next question will be "what do you expect me to do about that?" And I'll be honest, I don't know. It's your proposal, not mine. Reconsider some of the other proposals for syntax? Explore approaches other than "the syntax is deliberately similar to the existing early-bind syntax" which is stated as a design principle in the PEP? Note the concern in the PEP, with some concrete details on what proportion of people in the discussion believed it would be an issue, and state that you don't consider it a significant risk? Sometimes the colour of the bikeshed *is* important. But you get to pick. > I'm not sure what concerns need to be addressed, because I don't > understand the concerns. Fair, but you can state them, surely? Even if you're just copying what people say into the PEP, and noting that these are open issues that the PEP author cannot address without further explanation of the issue, that's better than having nothing (and having the same objections raised over and over again). At the moment the PEP doesn't even *have* an "open issues" section. > Maybe I'm just getting caught up on all the > side threads about "deferreds are better" and "it should be a magical > function instead" and I've lost some of the basics? Feel free to > repost a simple concern and I will attempt to respond. Well, I did that when you asked the last time. Maybe you don't think my concerns are "simple", but I don't know what to do about that - if you are saying my concerns "aren't stated simply enough" for a response, I'm out of ideas for how to proceed. If my ideas were that simple to state, they'd be simple to fix, and I wouldn't be worried about them. I could explain any one of my objections in more detail. But how would a paragraph or two of explanation "simplify" things? > > Yes, many of the concerns are somewhat subjective, and many of them > > are subject to a certain amount of interpretation. That's the nature > > of this sort of issue. If I said to you that the biggest issue here > > was that "in the group of people on python-ideas who were motivated > > enough to get involved in discussions, about half of the participants > > were arguing against the proposal"¹ would that be a concrete enough > > objection for you? Count it as my 5th objection, if you like. I know > > we're not putting the PEP to a vote here, but proposed changes *are* > > supposed to achieve a certain level of consensus (in the normal course > > of events - of course the SC can approve anything, even if it's hugely > > unpopular, that's their privilege). > EVERYONE is arguing against the proposal. So your response to my concern that opinion is divided on the PEP, is to say that actually, no-one likes it? I get that you're frustrated, but that doesn't seem useful. > Quite frankly, I'm just > about ready to throw the whole thing in, because this entire thread > has devolved to complaints that are nearly impossible to respond to - > or are just repetition of things that ARE responded to in the PEP. OK, well I've given my reservations (and note that I have repeatedly used the terms "reservations" and "concerns" rather than "objections", and that's deliberate). I won't continue to discuss or clarify them unless you have specific questions, as I feel that doing so will just increase your frustration here, and I don't want to do that. But if you *do* feel there's merit in trying to
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote: > Part of the problem is that it is really REALLY hard to figure out > what the actual objections are. I asked, and the one clear answer I > got was one subjective opinion that the cognitive load exceeded the > benefit. Great! That's one person's concern. I've responded to that by > clarifying parts of the cognitive load problem, and that's about as > far as that can go. Um, what parts of my response were unclear? I gave 4 specific points, Brendan gave 4 more (there wasn't much overlap with mine, either). Multiple people have mentioned that the proposed syntax is confusing. You don't have to respond to everyone individually, and indeed you shouldn't - it's the cumulative effect that matters. Telling 10 people that their concern "is one person's concern" doesn't address the fact that 10 people felt similarly. And honestly, there's only about 10 active participants in this thread, so even 5 people with reservations about the syntax is still "half the people who expressed an opinion". Yes, many of the concerns are somewhat subjective, and many of them are subject to a certain amount of interpretation. That's the nature of this sort of issue. If I said to you that the biggest issue here was that "in the group of people on python-ideas who were motivated enough to get involved in discussions, about half of the participants were arguing against the proposal"¹ would that be a concrete enough objection for you? Count it as my 5th objection, if you like. I know we're not putting the PEP to a vote here, but proposed changes *are* supposed to achieve a certain level of consensus (in the normal course of events - of course the SC can approve anything, even if it's hugely unpopular, that's their privilege). Paul ¹ That's just my gut feeling. Feel free to check the actual numbers and counter my argument with more precise facts. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MZIA2BTDWLYJ3IMNGRNWFHOQ5U62NMMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
