[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Mon, Mar 7, 2022, 9:12 PM Jelle Zijlstra wrote: > > > El lun, 7 mar 2022 a las 19:57, Christopher Barker () > escribió: > >> On Mon, Mar 7, 2022 at 3:43 PM Chris Angelico wrote: >> >>> On Tue, 8 Mar 2022 at 10:39, Jelle Zijlstra >>> wrote: >>> > >>> > >>> > >>> > El lun, 7 mar 2022 a las 15:35, Chris Angelico () >>> escribió: >>> >but python-ideas is 100% shooting ideas to pieces. >> >> >> 100% really? Maybe my sense of time is blurred, but some ideas do make it >> through. >> >> PEP 618 (zip(strict=True)) and PEP 616 (str.removeprefix) originated on > python-ideas and were accepted. > Even more recently, PEP 680 (tomllib in the standard library). The python-ideas discussion was short and very positive. Then the PEP was written and the "meat" of the discussion was done on discuss.python.org Python-ideas: https://mail.python.org/archives/list/python-ideas@python.org/thread/IWJ3I32A4TY6CIVQ6ONPEBPWP4TOV2V7/ Discuss: https://discuss.python.org/t/pep-680-tomllib-support-for-parsing-toml-in-the-standard-library/13040 ___ > 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/QIW26KTHWLFG5OJZO5WSX73MOMVKXUUP/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Finn (Mobile) ___ 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/KOSC3JGGISTFIKEGAQ6PY6KJENLTMPKL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Applications user/system directories functions
On Wed, Dec 15, 2021, 8:32 PM Finn Mason wrote:
> It would be a good idea to add something like appdirs to the stdlib. Maybe
> something like os.path.userdata() (as an example name). I have four
> questions:
>
> 1. What should the functions be called, and module should they go in? I
> personally say os.path module, with names such as userdata() for
> consistency with the rest of the os module.
>
> 2. Should the functions take the app name and author, or just return the
> base path, e.g. ~/. local/share? The latter makes more sense to me if I had
> to pick one, but my personal recommendation would be to make the name and
> author optional arguments, so userdata() returned (on Linux)
> ~/.local/share, but userdata(appname="foo") returned ~/.local/share/foo.
> This seems to be the behavior of the appdirs functions.
>
> 3. Should we include something like the AppDirs class, which is a wrapper
> of sorts for the functions? I personally say no, it's not necessary or
> important.
>
> 4. Should this also be added to pathlib? I say definitely, probably in the
> form of class constructors (e.g. Path.user_data()).
>
Tildes would be expanded, of course. (I forgot to mention that.)
--
Finn (Mobile)
--
> Finn (Mobile)
>
> On Wed, Dec 15, 2021, 5:35 PM Christopher Barker
> wrote:
>
>> On Wed, Dec 15, 2021 at 4:29 PM Christopher Barker
>> wrote:
>>
>>> On Wed, Dec 15, 2021 at 2:57 PM Neil Girdhar
>>> wrote:
>>>
>>>> +1 for appdirs. It's a shame that more projects don't yet use it.
>>>>
>>>
>> I agree -- I've wanted something like that for years in the stdlib.
>>
>> wxPython has wx.StandardPaths -- and it's really handy. But a wrapper
>> around a C++ version, so not useful outside of wx.
>>
>> -CHB
>>
>>
>>>
>>>> On Wednesday, December 15, 2021 at 9:03:07 AM UTC-5 Matt del Valle
>>>> wrote:
>>>>
>>>>> There is appdirs which does precisely what you're looking for:
>>>>>
>>>>> https://pypi.org/project/appdirs/
>>>>>
>>>>> That said, it does seem to be a core bit of functionality that would
>>>>> be nice to have in the os and pathlib modules without needing an external
>>>>> dependency. I'm not going to weigh in on the pros/cons of adding it to the
>>>>> stdlib, I'll leave that to others who I'm sure will have strong opinions
>>>>> on
>>>>> the matter :)
>>>>>
>>>>> On Wed, Dec 15, 2021 at 1:47 PM JGoutin via Python-ideas <
>>>>> python...@python.org> 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 sy
[Python-ideas] Re: Applications user/system directories functions
It would be a good idea to add something like appdirs to the stdlib. Maybe
something like os.path.userdata() (as an example name). I have four
questions:
1. What should the functions be called, and module should they go in? I
personally say os.path module, with names such as userdata() for
consistency with the rest of the os module.
2. Should the functions take the app name and author, or just return the
base path, e.g. ~/. local/share? The latter makes more sense to me if I had
to pick one, but my personal recommendation would be to make the name and
author optional arguments, so userdata() returned (on Linux)
~/.local/share, but userdata(appname="foo") returned ~/.local/share/foo.
This seems to be the behavior of the appdirs functions.
3. Should we include something like the AppDirs class, which is a wrapper
of sorts for the functions? I personally say no, it's not necessary or
important.
4. Should this also be added to pathlib? I say definitely, probably in the
form of class constructors (e.g. Path.user_data()).
--
Finn (Mobile)
On Wed, Dec 15, 2021, 5:35 PM Christopher Barker
wrote:
> On Wed, Dec 15, 2021 at 4:29 PM Christopher Barker
> wrote:
>
>> On Wed, Dec 15, 2021 at 2:57 PM Neil Girdhar
>> wrote:
>>
>>> +1 for appdirs. It's a shame that more projects don't yet use it.
>>>
>>
> I agree -- I've wanted something like that for years in the stdlib.
>
> wxPython has wx.StandardPaths -- and it's really handy. But a wrapper
> around a C++ version, so not useful outside of wx.
>
> -CHB
>
>
>>
>>> On Wednesday, December 15, 2021 at 9:03:07 AM UTC-5 Matt del Valle wrote:
>>>
There is appdirs which does precisely what you're looking for:
https://pypi.org/project/appdirs/
That said, it does seem to be a core bit of functionality that would be
nice to have in the os and pathlib modules without needing an external
dependency. I'm not going to weigh in on the pros/cons of adding it to the
stdlib, I'll leave that to others who I'm sure will have strong opinions on
the matter :)
On Wed, Dec 15, 2021 at 1:47 PM JGoutin via Python-ideas <
python...@python.org> 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...@python.org
> To unsubscribe send an email to python-id...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python...@python.org/message/MHEWO4U6SBDU7OU3JH4A62EWCANDM7I2/
>
[Python-ideas] Re: List comprehension operators
list(range(1, 101)) I think we don't need a whole new syntax for something that's already an easy one-liner. -- Finn (Mobile) On Tue, Dec 14, 2021, 8:52 AM a.kolpakov2010--- via Python-ideas < python-ideas@python.org> wrote: > It would be awesome to be able to create a list with just: > > li = [1—100] > > or > > li = [1 .. 100] > ___ > 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/CQOPU4ZMADKD5WOV5G3ZB4OAWDP4YKF6/ > 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/EAAI7EAOXRCV2HK4QQ7QS36VUQ6B3MBR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python standard library TOML module
Yes!! This is something I've thought about proposing for a while, but I was too lazy to do it. TOML is a wonderful language with an important place in the Python ecosystem. -- Finn (Mobile) On Fri, Dec 10, 2021, 9:57 AM Sebastian Koslowski < sebastian.koslow...@gmail.com> wrote: > There is already some info/discussion over on the bug tracker: > > https://bugs.python.org/issue40059 > > Sebastian > ___ > 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/ZQOD6TEOWAB47WL2IMQS2W67IAKS46NR/ > 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/YNA3NQDQEUY56M54INRQHJCYD44I4SI7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages
On Sun, Dec 5, 2021, 12:11 PM Brendan Barnwell wrote: > On 2021-12-04 20:01, David Mertz, Ph.D. wrote: > > > > There are perfectly good ways to "fake" either one if you only have the > > other. Probably more work is needed to simulate early binding, but there > > are ways to achieve the same effect. > > > > However, that language would not be Python. That ship sailed in 1991. > > What's being discussed here isn't changing the behavior of binding in > > `def f(foo=bar)`. > > > > Instead, it's a discussion of adding ADDITIONAL syntax for late-binding > > behavior. I think the proposed syntax is the worst of all the options > > discussed. But the real issue is that the cases where it is relevant are > > vanishingly rate, and the extra cognitive, teaching, and maintenance > > burden is significant. > > This is a key point that I mentioned in another message (although > that > message doesn't seem to have reaches the list for some reason). > Steven's list is very useful but I don't see any mention there of > languages that allow BOTH late-binding and early-binding, and > distinguishes them with some kind of syntactic flag in the signature. > Is its not being done before really a good argument against it? It may be that there simply hasn't been a need in the other languages. Also, on a kind of side note, what would be a situation where early binding is advantageous to late binding? I can't think of one off the top of my head. -- > Brendan Barnwell > "Do not follow where the path may lead. Go, instead, where there is no > path, and leave a trail." > --author unknown > ___ > 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/WFCIHHCDJBMBX7J4SNHBNMXTHIP7SJ6D/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Finn (Mobile) ___ 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/6H5K6SGUDIXPISJVG4SYP2PCGWCWPTRI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: easier writing to multiple streams
On Thu, Nov 25, 2021, 6:06 AM Eyal Gruss wrote:
> hi
>
> first post here :)
> i have a recurring use pattern where i want to save to file everything i
> print to the screen. i have used the standard logging module and found it
> too cumbersome for my simple use case, and i find myself changing all my
> print()'s to custom myprint()'s. i am interested in suggesting several
> additions to the standard libraries, as i feel this use case is common
> enough, important enough, and currently painful enough to justify such
> changes, and that all four of the following suggestions could be useful in
> a complementary fashion.
>
I'm not sure this is actually so common. How do you know it is? Also, it's
not very painful to do, just occasionally annoying. If you want, you could
write`_print = print` and then redefine print() as you want. I doubt that's
good practice, but it works.
1. allow the print() "file" argument to take a list of streams (currently
> it can take only a single stream). e.g:
>
> with open('output.txt', 'w') as f:
>print('hello', file=[sys.stdout, f])
>
> this seems like the quickest and least resistant path for the user. need
> to decide how multiple streams will work with the flush argument.
>
This could very possibly be backwards-incompatible.
2. modify contextlib.redirect_stdout() to take an additional boolean
> argument which we can call tee/replicate/duplicate/clone etc. when True it
> will duplicate instead of just redirecting:
>
> with open('output.txt', 'w') as f:
> with redirect_stdout(f, tee=True): # will duplicate instead of
> redirecting
> print('hello')
>
> or we could add a new context manager contextlib.copy_stdout()
>
> 3. allow the contextlib.redirect_stdout() "new_target" argument to take a
> list of streams, or allow specifying multiple arguments for multiple
> streams. e.g:
>
> with open('output.txt', 'w') as f:
> with redirect_stdout(sys.stdout, f): # or
> redirect_stdout([sys.stdout, f])
> print('hello')
>
> this has the benefit over the tee argument of allowing more than one
> additional stream, but you need to explicitly specify stdout. so would be
> nice to have both modifications.
>
> 4. add to the standard io library a new class which gives you the write
> interface of a single stream, but is a wrapper that will write to multiple
> streams:
>
> with open('output.txt', 'w') as f:
>multi = io.OutputStreamCollection(sys.stdout, f)
>multi.write('hello\n')
># or: print('hello', file=multi)
>
Is this necessary if the other ideas are implemented?
this is similar to:
> https://stackoverflow.com/questions/9130755/wrapper-to-write-to-multiple-streams,
> and we need to decide about the rest of the stream methods.
>
> eyal.
> ___
> 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/7I55RDLFAV6A3K762TE3BW42WTTUE4ET/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Finn (Mobile)
___
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/BHVN4G54KQVWRFOLIG7TB6NHOJNEVRDV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Structure Pattern for annotation
I love the proposal for dicts, but I agree that this discourages duck typing. Could the curly braces notation represent Mapping, not dict specifically? +1 to shortening tuples but not other sequences. -- Finn Mason On Thu, Oct 14, 2021, 6:46 AM Paul Moore wrote: > On Thu, 14 Oct 2021 at 13:04, Ricky Teachey wrote: > > > > I think all of this additional syntax is just a mistake. > > > > The reason is it will encourage people to not properly annotate their > input types for duck typing. Some of these shortcuts might be nice for > output types. But the more general trying.Mapping, typing.Sequence and > friends should be preferred for input types. If terse shortcuts are > available for the concrete data structure types, but not for the generic > types, a lot of people are going to feel nudged to type hint their python > improperly. > > +1. I'm not sure how much of my reservations about this whole > discussion are ultimately reservations about typing in general, but I > feel that the more we make it easier to express "exact" types, the > more we encourage people to constrain their APIs to take precise types > rather than to work with duck types. (I saw an example recently where > even Mapping was over-specified, all that was needed was __getitem__, > not even __len__ or __iter__). > > I know protocols allow duck typing in a static type checking context - > maybe the energy focused on "making basic types easier to write" > should be focused on making protocols easier to write, instead. > > 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/KALBNJN2T4HAZFK4PZUV5RGAKXAVWCMD/ > 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/C6HATFD4GXM73TDB6IMLBDIJPRVICIKI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a Version type
Thank you for the feedback. I was unaware of the packaging package and PEP
440. I recognize that there are definitely some problems with my idea.
I took a look at the packaging package, and I think it might be a good idea
to put something like it in the stdlib. The Version type there from what I
can tell has everything I wanted plus more.
--
Finn Mason
On Sun, Oct 10, 2021, 7:25 AM Steven D'Aprano wrote:
> On Sat, Oct 09, 2021 at 08:16:58PM -0600, Finn Mason wrote:
>
> > I feel like there could be a better way to define versions. There's no
> real
> > standard way to specify versions in Python, other than "use semantic
> > versioning."
>
> It is a common myth that Python uses semantic versioning. It doesn't.
>
> https://www.python.org/dev/peps/pep-0440/#semantic-versioning
>
> Also, semantic versioning is not the gold standard of versioning
> schemes. Another popular one is calendar versioning:
>
> https://calver.org/
>
>
> So you have a separate field for alpha, beta, pre and post. Great. So
> what happens if they conflict?
>
> Version(major=3, minor=10, patch=2, alpha=3, beta=7, pre=1)
>
> That suggests that this is all three of alpha, beta and pre-release all
> at once.
>
> If your data structure will allow something like that, there needs to be
> some sort of meaning for it.
>
> How do you store valid semantic versions such as these examples taken
> straight from the semver website?
>
> 1.0.0-x.7.z.92
> 1.0.0-x-y-z.–
> 1.0.0-beta+exp.sha.5114f85
> 1.0.0+21AF26D3—-117B344092BD
>
> https://semver.org/
>
>
> If all you want is to cover Python's versioning system, you can just use
> the same named tuple as used by sys.version_info:
>
> https://docs.python.org/3/library/sys.html#sys.version_info
>
>
>
> > To maintain backwards compatibility, comparisons such as `Version(1, 2)
> ==
> > (1, 2)` and `Version(1, 2) == "1.2"` will return `True`.
>
> What backwards compatibility? Since this Version type doesn't exist,
> there is no older behaviour that needs to not change.
>
> If you want to compare Version instances with strings and tuples, it is
> probably better, and cleaner, to be explict about it:
>
> version.compare_as_string("1.2")
>
> str(version) == "1.2"
>
> and reserve the equality operator for pure Version to Version
> comparisons. That way, any unexpected type passed by mistake (a bug)
> won't accidentally return True or False, but raise a TypeError.
>
>
> > A problem is that not all versioning systems are covered by this
> proposal.
>
> Indeed, even semantic versioning is not covered. Nor is Python's
> versioning system.
>
>
> --
> 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/LGP24B62RQBPGWP2LFN6LRCVXWJ6Y5PE/
> 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/32JCIFZT6YSEHKTYTIYE347KZWEEY7AZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
On Sat, Oct 9, 2021, 9:56 PM Steven D'Aprano wrote: > [Snip...] Newbies won't know first() lives in itertools, and those experienced > enough to know it is there probably won't bother to use it. > A very good point. Let's get back to the original topic. Should `dict.items()` be indexable now that dicts are ordered? I say yes. Why shouldn't it? -- Finn Mason > ___ 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/OOR2AUMA7UMHHVW7XLLUXHTNKGRXTPU4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Adding a Version type
Hello all, I was thinking about the following idioms: __version__ = "1.0" import sys if sys.version_info < (3, 6): # Yell at the user I feel like there could be a better way to define versions. There's no real standard way to specify versions in Python, other than "use semantic versioning." This can cause problems such as: * Uncertainty of the type of the version (commence the pattern matching! Or `if... elif` statements if that's your thing) * No real way to specify an alpha, beta, pre, or post version number in a tuple of ints, e.g. `(2, 1, 0, "post0")` doesn't really work. I propose a new `Version` type, a standard way to define versions. The signature would look something like `Version(major: int, minor: int = 0, patch: Optional[int] = None, alpha: Optional[int] = None, beta: Optional[int] = None, pre: Optional[int] = None, post: Optional[int] = None)`. To maintain backwards compatibility, comparisons such as `Version(1, 2) == (1, 2)` and `Version(1, 2) == "1.2"` will return `True`. `str(Version(1, 2))` will return `"1.2"` (to clarify, if `patch` were 0 instead of None, it would return `"1.2.0"`). There will be an `as_tuple()` method to give the version number as a tuple (maybe named tuple?), e.g. `Version(1, 2).as_tuple()` will return `(1, 2)`. A problem is that not all versioning systems are covered by this proposal. For example, I've done some programming in C#, and many C# programs use a four number system instead of the three number system usually used in Python code, i.e. major.minor.patch.bugfix instead of major.minor.patch. (This may not seem very different, but it often is.) Where to place this type is an open question. I honestly have no good ideas. This could just be implemented as a PyPI package, but there may not be a point in adding a whole dependency to use a semantic type that other people probably aren't using (which wouldn't be the case if it were part of core Python). This would be implemented in Python 3.11 or 3.12, but I'd recommend a backport on PyPI if implemented. Questions? Thoughts? Suggestions to improve it? ___ 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/7HA26ZGQSLOJ5X33WI6B626S6WB5NUBW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
On Wed, Oct 6, 2021, 9:23 AM Ricky Teachey wrote: > On Wed, Oct 6, 2021 at 10:55 AM Finn Mason wrote: > >> I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many >> people use that feature. I honestly still think of them as unordered ;) >> > > I've seen several people say this so I'll be a voice on the other side: I > am not a pro developer so my practices should probably not be weighted all > that much. But nevertheless, I have been constantly relying on order-ness > in regular dicts ever since it was non-official thing in cpython. I > actually did a little happy dance in my chair when RH announced this at > pycon years ago. > > I am sure I am not the only one. > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going home > or actually going home." - Happy Chandler > Perhaps I'm wrong about that. However, I would still like things relying on ordered dictionaries to be implemented in OrderedDict first. I might be alone in this opinion, though. ___ 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/VEHD2ERZOYJDBLKZZX2XLBCXL55LPFB4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many people use that feature. I honestly still think of them as unordered ;) Let's talk code clarity. After all, to quote GvR, "Code is more often read than written." (I may have gotten the wording wrong, I just wrote it off the top of my head.) To me, the presence of a dict suggests that order doesn't matter. If you want order, communicate that by using `collections.OrderedDict`, a fully-featured dict subclass where the point is the order! You can get the first or last key/item pairs with `.popitem()`. It works! OrderedDict documentation: https://docs.python.org/3.10/library/collections.html#collections.OrderedDict We could add indexing to OrderedDict, which would return key/value pairs. (While we're talking about collections, why don't we return a namedtuple ;) ) As for adding functions to `itertools`, sure, I'm for it. We don't need people writing `next(iter(iterable))` just to get the first item. -- Finn On Wed, Oct 6, 2021, 8:02 AM Steven D'Aprano wrote: > On Wed, Oct 06, 2021 at 11:11:09AM +0100, Alex Waygood wrote: > > > The temptation to insist "see, YAGNI!" at this point I shall resist. > > > > *You* might not need it, but I've seen it come up a lot on Stack > > Overflow, and all too often people end up going for the much less > > efficient solution. I personally have also written code with practical > > applications using `next(iter(mydict))`. > > Under what circumstances do you care what the first key in a dict is, > without going on to care about the second, third, fourth etc? > > They are surely extremely niche, or artificial, or both, e.g. the > Stackoverflow problem you link to: "find the first non-repeating > character in a string -- using only one loop". Why the *first* rather > than any, or all? > > In any case, the presence of one or two uses for a piece of > functionality doesn't mandate that we make this a builtin. Your solution > with next() is perfectly adequate. > > The other suggested methods are even more obscure. Why have a method > for returning the first value, without knowing the key? > > "I don't know what the first key is, and I don't care, but I know that > whatever it is, it maps to the value 17." > > Now what are you going to do with that knowledge? This seems like a > method in desperate need of a use-case. > > > [...] > > I agree that it's a lot of methods to add. That's precisely why I > > prefer Inada Naoki's suggestion of additions to itertools > > Whether they are added to dict or itertools, there are still nine of > them, and they are pretty much near clones of each other: > > # first_ and last_ whatsits > next([iter|reversed](obj.[keys|values|items]())) > > if you will excuse the misuse of hybrid Python/BNF syntax :-) > > > > -- > 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/T3TOFAFBPGY44LOVKSMVZJGBNQ7MUNEL/ > 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/3RKWSNOO4J7WJWBYFXMA7HKPBVZVIF3S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: More efficient list copying
On Sat, Oct 2, 2021, 11:20 PM Christopher Barker wrote: [Snip...] > > But sure, if we can eliminate inefficiencies in Python standard data > types, then why not? > I agree. If we can eliminate inefficiencies in core Python features, that would be great. I don't work with this kind of thing, so I won't make any further judgement. > ___ 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/UVB3VG7W6WYTLJV7ZPIHECF3BDN3YI2H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?
I've found that the `if __name__ == "__main__"` idiom is unintuitive and feels unnecessary, and I'd like a cleaner way to write it. However, I don't like the idea of functions being "magically called." One of the things I don't like about C/C++ and so many other languages is the presence of a `main()` function that's implicitly called when you run the script. I don't think functions should be run without being called in the code. (TBH, I never did get far learning C++, so I'm no authority here.) I never liked how you can't import your package in its own __main__.py file (or maybe I'm missing something, packaging isn't my strong suit), so at first I thought, "Here's a way to move the script code into __init__.py!" `python -m package` could just call the main function in __init__.py! Everything could be so simple! However, after reading others' responses to the idea, I'm convinced that this wouldn't be good (i.e. there could be two copies of the module in memory). Keep __main__.py it is. Backwards compatibility isn't an issue. If your code needs to be compatible with previous versions of Python, don't use it. Problem solved. One compelling idea for me is the idea of automatic basic argument parsing. The main function could have command line arguments as arguments to it (like how `main` in other languages takes `argv` as an argument, but we could be specific here, by saying something like `def main(command, verbose=False)`), and the function that calls this main function purses arguments and passes them to the main function. We could use type hints and introspection to make this even more powerful. However, it could get very messy very quickly with options. I do think that this would be good motivation to do this, though. After all, using argparse can only be so much fun. My proposal is to make it look something like: run(main) Where `run` (a placeholder name for the proposed function) only executes if name equals main, and may do argument parsing and pass the arguments to `main`. -- Finn M. On Sat, Oct 2, 2021, 3:19 PM Anthony Baire wrote: > why not evaluate the condition directly in the decorator, python 3.9 > allows that ;-p > > @lambda x: __name__ == "__main__" and x() > def main(): > ... > > > On 01/10/2021 21:35, Jonathan Crall wrote: > > I was curious if / what sort of proposals have been considered for > simplifying the pattern: > > ``` > def main(): > ... > > if __name__ == "__main__": > main() > ``` > > I imagine this topic must have come up before, so I'd be interested in any > relevant history. > > But unless I'm missing something, it seems like adding some easier > alternative to this cumbersome entrypoint syntax would be worth considering. > > My motivation for writing this suggestion is in an attempt to stop a > common anti-pattern, where instead of defining a `main` function (or a > function by any other name) an simply calling that by adding the above two > lines, a lot of Python users I work with will just start dumping their > logic into the global scope of the module. > > Needless to say, this can have consequences. If there was some default > builtin, let's call it `__main__` for now (open to suggestions), that took > a function as an argument and conditionally executed it if `__name__ == > "__main__"` in the caller's scope, that would allow us to simplify the > above boilerplate to a single line with no extra indentation: > > ``` > def main(): > ... > > __main__(main) > ``` > > In addition to being simpler, it would allow users to avoid the trap of > adding logic that impacts the global scope. It would also save me some > keystrokes, which I'm always grateful for. > > Furthermore, it could be used as a decorator (and the use-case wouldn't be > unreasonable!), and we all know how much new Python users love decorators > when they find out about them. > > ``` > @__main__ > def main(): > ... > ``` > > Maybe having such a builtin would discourage globals and help new users > get the use-decorators-everywhere bug out of their system. > > -- > -Dr. Jon Crall (him) > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to > python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/FKQS2NEI5RQMTX53N77KQQDFZ6HZONXU/ > 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/4Y6JQJMMNXJVS2GBTBJUBOZXE43J7QFV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list
[Python-ideas] Re: os.workdir() context manager
On Tue, Sep 14, 2021, 7:58 PM David Mertz, Ph.D. wrote: > I think this would be convenient. > > And yes, it's not thread safe. But neither is os.chdir() to start with. > Someone whose script, or library, wants to chdir can already shoot > themselves in the foot. This makes that slightly less likely, not more. > I agree. In terms of the bikeshed color, I think putting this in `pathlib` is the > best approach for "modern Python." > I disagree. The way I see it, `pathlib` is home of *Path(). No functions. Just *Path(). Then again, I didn't write pathlib. I could be misunderstanding the intent. However, workdir() doesn't deal with Paths. Sure, it takes a PathLike as an argument, but it doesn't perform operations on a Path or return a Path. I think changing the CWD belongs squarely in the os module. > ___ 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/FRCHASRXJLEUCMYBPPRJLLBCCQS22AVR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
BTW, should it be `WorkDir` instead of `workdir` because it's a class, or would that be too inconsistent? On Tue, Sep 14, 2021, 6:47 PM Finn Mason wrote: > > On Tue, Sep 14, 2021, 5:36 PM Cameron Simpson wrote: > >> On 15Sep2021 07:50, Chris Angelico wrote: >> >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote: >> >> I know I'm atypical, but I have quite a lot of multithreaded stuff, >> >> including command line code. So while it'd be ok to avoid this context >> >> manager for my own code, I fear library modules, either stdlib or pypi, >> >> quietly using this in their code, making them unuseable in the general >> >> case. Unrepairably unuseable, for the user. >> > >> >Library code shouldn't be changing the working directory, context >> >manager or not. That belongs to the application. >> >> Entirely agree. >> >> I'm concerned that convenient stackable chdir is a bug magnet, and would >> creep into library code. Maybe not in the stdlib, but there's no point >> writing such a context manager if it isn't going to be used, and >> therefore it could get used in library code. Imagine when a popular pypi >> module starts using it internally and breaks a multithreaded app >> previously relying on it? >> > > I don't think we should worry about it "creeping into library code." The > thread-unsafety is not a cause of this context manager. It comes from the > preexisting `os.chdir()`. If the library is changing the CWD, it's already > thread-unsafe. It's not because of the new context manager. All > `os.workdir()` does is make things easier. > However, if it's implemented (which I personally support), there should > still of course be a warning in the documentation. But I'd like to > emphasize that *it is not because of `workdir()` itself, but the > underlying `chdir()`!* > > On 14Sep2021 15:16, Guido van Rossum wrote: > >Here I think we need to drop our perfectionist attitude. > > I completely agree. > >> ___ 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/J4L3I3QWV65GPKHJ5RZ4NASGX7ZIS774/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
On Tue, Sep 14, 2021, 5:36 PM Cameron Simpson wrote: > On 15Sep2021 07:50, Chris Angelico wrote: > >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote: > >> I know I'm atypical, but I have quite a lot of multithreaded stuff, > >> including command line code. So while it'd be ok to avoid this context > >> manager for my own code, I fear library modules, either stdlib or pypi, > >> quietly using this in their code, making them unuseable in the general > >> case. Unrepairably unuseable, for the user. > > > >Library code shouldn't be changing the working directory, context > >manager or not. That belongs to the application. > > Entirely agree. > > I'm concerned that convenient stackable chdir is a bug magnet, and would > creep into library code. Maybe not in the stdlib, but there's no point > writing such a context manager if it isn't going to be used, and > therefore it could get used in library code. Imagine when a popular pypi > module starts using it internally and breaks a multithreaded app > previously relying on it? > I don't think we should worry about it "creeping into library code." The thread-unsafety is not a cause of this context manager. It comes from the preexisting `os.chdir()`. If the library is changing the CWD, it's already thread-unsafe. It's not because of the new context manager. All `os.workdir()` does is make things easier. However, if it's implemented (which I personally support), there should still of course be a warning in the documentation. But I'd like to emphasize that *it is not because of `workdir()` itself, but the underlying `chdir()`!* On 14Sep2021 15:16, Guido van Rossum wrote: >Here I think we need to drop our perfectionist attitude. I completely agree. > ___ 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/DIQXTTKRASFB2DMQZ4THMS4TK2ALK7BA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
I think that this is a great idea. However, pipes only point to one
character, which can be confusing. (Citation: many tracebacks before 3.10.)
I'm wondering: Could failed assertions step you into `pdb`, if they are
used for testing purposes? Could there be a way to specify different levels
of assertions? For example, maybe certain assertions are turned off with -O
or -OO, others turned off only with -O, and some that never are?
There are lots of ways `assert` could be improved, and the question is how?
What is/are the best way(s)?
--
Finn Mason
On Mon, Sep 13, 2021, 5:36 AM Juancarlo Añez wrote:
> What about asserts that are not used for testing, but as classic “unless
>> there’s a bug, this should hold”?
>
>
> To me this relates to the thread about having a structured *assert* that
> doesn't go away with *-O*.
>
> My purpose when addressing *assert* was precisely the *“unless there’s a
> bug, this should hold”* kind of assertions.
>
> In that context, introducing additional yet known costs (as in this
> "power" idea), providing for different exception types (maybe all
> descending from AssertError?), and allowing for a block to prepare the
> exception, are all worth it.
>
> Introducing the new syntax for *assert* would imply zero cost for
> existing assertions.
>
> On Sun, Sep 12, 2021 at 10:28 AM Guido van Rossum
> wrote:
>
>> This is cool.
>>
>> AFAIK pytest does something like this. How does your implementation
>> differ?
>>
>> What is your argument for making this part of the language? Why not a 3rd
>> party library?
>>
>> What about asserts that are not used for testing, but as classic “unless
>> there’s a bug, this should hold”? Those may not want to incur the extra
>> cost.
>>
>> —Guido
>>
>> On Sun, Sep 12, 2021 at 07:09 wrote:
>>
>>> Hi all,
>>>
>>> I’d like your comments and feedback on an enhancement that introduces
>>> power assertions to the Python language.
>>>
>>> Proposal
>>>
>>> This feature is inspired by a similar feature of the Groovy language[1],
>>> and is effectively a variant of the `assert` keyword.
>>> When an assertion expression evaluates to `False`, the output shows not
>>> only the failure, but also a breakdown of the evaluated expression from the
>>> inner part to the outer part.
>>>
>>> For example, a procedure like:
>>> ```python
>>> class SomeClass:
>>> def __init__(self):
>>> self.val = {'d': 'e'}
>>>
>>> def __str__(self):
>>> return str(self.val)
>>>
>>> sc = SomeClass()
>>>
>>> assert sc.val['d'] == 'f'
>>> ```
>>>
>>> Will result in the output:
>>>
>>> ```python
>>> Assertion failed:
>>>
>>> sc.val['d'] == f
>>> | ||
>>> | eFalse
>>> |
>>> {'d': 'e'}
>>> ```
>>> See link [2] if the formatting above is screwed up.
>>>
>>> In the output above we can see the value of every part of the expression
>>> from left to right, mapped to their expression fragment with the pipe (`|`).
>>> The number of rows that are printed depend on the value of each fragment
>>> of the expression.
>>> If the value of a fragment is longer than the actual fragment (`{'d':
>>> 'e'}` is longer than `sc`), then the next value (`e`) will be printed on a
>>> new line which will appear above.
>>> Values are appended to the same line until it overflows in length to
>>> horizontal position of the next fragment.
>>>
>>> The information that’s displayed is dictated by the type.
>>> If the type is a constant value, it will be displayed as is.
>>> If the type implements `__str__`, then the return value of that will be
>>> displayed.
>>>
>>> It is important to note that expressions with side effects are affected
>>> by this feature. This is because in order to display this information, we
>>> must store references to the instances and not just the values.
>>>
>>> Rational
>>>
>>> Every test boils down to the binary statement "Is this true or false?",
>>> whether you use the built-in assert keyword or a more advanced assertion
>>> method provided by a testing framework.
>>> When an assertion fails, the output is binary too — "Expected x, but got
>>> y".
>>>
>>> There are helpful libraries like Hamcrest which give you a more verbose
>>> breakd
[Python-ideas] Re: Add check_methods function to standard library
Hello, This to thread has gotten no responses at all, so: Ping! On Sun, Aug 22, 2021, 3:16 PM Finn Mason wrote: > Sorry, the formatting was terrible. I copy and pasted it from the original > issue without really thinking about it. > Here's the same thing, but actually readable: > > In _collections_abc.py is a private function titled _check_methods(). It > takes a class and a number of method names (as strings), checks if the > class has all of the methods, and returns NotImplemented if any are > missing. The code is below: > > def _check_methods(C, *methods): > mro = C.__mro__ > for method in methods: > for B in mro: > if method in B.__dict__: > if B.__dict__[method] is None: > return NotImplemented > break > else: > return NotImplemented > return True > > This is an incredibly convenient function (referred to as check_methods > here on out) for creating abstract base classes, and is much simpler than > using hasattr for each method you want to check. For example: > > from abc import ABCMeta > # Without check_methods > class A(metaclass=ABCMeta): > @classmethod > def __subclasshook__(cls, subclass): > return (hasattr(subclass, 'foo') and > callable(subclass.foo) and > hasattr(subclass, 'bar') and > callable(subclass.bar) or > NotImplemented) > > # With check_methods > class B(metaclass=ABCMeta): > @classmethod > def __subclasshook(cls, subclass): > return check_methods(subclass, 'foo', 'bar') > > This would be a great function to add to the standard lib, perhaps in the > abc module. One problem with check_methods() as defined in > _collections_abc.py is that it doesn't check if the name is callable. Also, > type hints and more readable variables may be desirable. The final code, if > implemented, may look something like this: > > # In imports section: from typing import Literal > def check_methods(Class: type, *methods: str) -> Literal[True, > NotImplemented]: > """Check if class `Class` has methods `methods`.""" > mro = Class.__mro__ > for method in methods: > for Base in mro: > if (attr := getattr(Base, method, None)) is not None: > if not callable(attr): > return NotImplemented > break > else: > return NotImplemented > return True > > Again, this would be a great function to add to the `abc` module or a > similar one. I've proposed this in issue 44941. > Another possible implementation may be similar to a dataclass that > implements __subclasshook__ for you with the desired method checks. > > -- > Finn > ___ 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/GCOXW4CJUDRWFRYGTAU2LJO5RUANYQMR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improve traceback for common `with` statement mistake
Thank you for testing that. I dug through the change log, and found
bpo-12022:
https://bugs.python.org/issue12022
It *has* been fixed in 3.11, but not mentioned in the What's New document.
Should it be?
On Sun, Sep 5, 2021, 5:49 PM Chris Angelico wrote:
> On Mon, Sep 6, 2021 at 9:37 AM Finn Mason wrote:
> >
> > Hello all,
> >
> > In Python 3.10 and 3.11, exception tracebacks are being greatly
> improved. I noticed that there's nothing related to a fairly common (in my
> personal experience) cryptic traceback relating to the `with` statement:
> >
> > >>> with ContextManager as ctx:
> > ... # do something with `ctx`
> > ...
> > Traceback (most recent call last):
> > File "", line 1, in
> > AttributeError: __enter__
>
> I'm seeing a different message, so it looks like something HAS been
> improved:
>
> Python 3.11.0a0 (heads/main:ed524b4569, Aug 14 2021, 11:29:01) [GCC
> 8.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import contextlib
> >>> with contextlib.ExitStack: ...
> ...
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'ABCMeta' object does not support the context manager protocol
>
>
> > This occurs when one forgets to use a instance of a context manager
> class and uses the class itself. It's obviously not a very helpful
> traceback. ("Is it not a context manager?" "Is it the wrong class?")
> Something like the following would be better.
> >
> > >>> with ContextManager as ctx:
> > ... # do something with `ctx`
> > ...
> > Traceback (most recent call last):
> > File "", line 1, in
> > AttributeError: is not a context manager. Did you
> mean "with ContextManager()..."?
> >
> > The actual traceback message should probably be more specific than
> " is not a context manager".
> > Thoughts?
> >
>
> The "did you mean" part depends on or assumes that it can figure out
> that calling it would have given a viable context manager. This could
> be done by probing whether thing.__enter__ exists, but I'm not sure
> that'd be entirely safe. Also, it won't catch those made from
> generators:
>
> >>> @contextlib.contextmanager
> ... def foo(): yield
> ...
> >>> with foo: ...
> ...
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'function' object does not support the context manager protocol
> >>> with foo(): ...
> ...
> Ellipsis
> >>> foo
>
>
>
> In any case, the biggest advantage (IMO) comes from naming the type,
> which will make it easy to distinguish the object from its type.
>
> 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/NGP5LQSRS2XPNHIRBN3O76UGMEB623TW/
> 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/56MVDUFOD6GLSTCWIKZBJQO65P3HHJ6N/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Improve traceback for common `with` statement mistake
Hello all,
In Python 3.10 and 3.11, exception tracebacks are being greatly improved. I
noticed that there's nothing related to a fairly common (in my personal
experience) cryptic traceback relating to the `with` statement:
>>> with ContextManager as ctx:
... # do something with `ctx`
...
Traceback (most recent call last):
File "", line 1, in
AttributeError: __enter__
This occurs when one forgets to use a instance of a context manager class
and uses the class itself. It's obviously not a very helpful traceback.
("Is it not a context manager?" "Is it the wrong class?") Something like
the following would be better.
>>> with ContextManager as ctx:
... # do something with `ctx`
...
Traceback (most recent call last):
File "", line 1, in
AttributeError: is not a context manager. Did you
mean "with ContextManager()..."?
The actual traceback message should probably be more specific than " is not a context manager".
Thoughts?
--
Finn
___
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/5NHD4LS4NGTXNM5RDKCCSBXQPURBTC4Q/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: NAN handling in statistics functions
I've honestly never really used an Enum, so I'm not an expert here.
An idea might be using string flags, but setting module level constants
equal to the string flag, so that you can use either. For example (using
the ipython shell because it's easier in email with quoting and all):
In [1]: import statistics as stats
In [2]: stats.NAN_IGNORE
Out [2]: 'ignore'
In [3]: stats.median([3, float('nan'), 5], nan_policy=stats.NAN_IGNORE) ==
stats.median([3, float('nan'), 5], nan_policy='ignore')
Out [3]: True
I do think that it doesn't matter too much and an issue should be submitted
soon.
On Tue, Aug 31, 2021, 4:59 PM Christopher Barker
wrote:
> First:
>
> I started this specifically in the context of the stats package and the
> NaN handling flag, but it did turn into a ore general discussion of Enums,
> so a final thought:
>
> On Tue, Aug 31, 2021 at 4:17 AM Ronald Oussoren
> wrote:
>
>>
>> Not just static typing, but static analysis in general. Tools like flake8
>> will complain about typos, completion tools can help typing, ….
>>
> ...
>
>
>> I tend to use constants instead of string literals because of better
>> static analysis, and try to convert uses to enums over time. String flags
>> work as well, but I’ve had too much problems due to typo’s in string
>> literals that weren’t caught by incomplete tests. Being able to at least
>> run a listing tool to find basic issues like typo’s is very convenient.
>> But YMMV.
>>
>
> I think this is the crux or it -- Enums are far more suited to static
> analysis.
>
> And that reflects a shift in Python over the years. Most of the changes in
> Python have made it a better "systems" language, and some have made it a
> somewhat more awkward "scripting" language.
>
> Features to support static analysis are a good example -- far less
> important for "scripting' that "systems programming".
>
> Personally, I find it odd -- I've spent literally a couple decades telling
> people that Python's dynamic nature is a net plus, and the bugs that static
> typing (and static analysis I suppose) catch for you are generally shallow
> bugs. (for example: misspelling a string flag is a shallow bug).
>
> But here we are.
>
> Anyway, if you are writing a quick script to calculate a few statistics, I
> think a string flag is easier. If you are writing a big system with some
> statistical calculations built in, you will appreciate the additional
> safety of an Enum. It's hard to optimize for different use cases.
>
> - CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
> ___
> 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/LJ334TFG67PR3G2E6WNZC7YEG3K2XMEN/
> 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/LRJFFW25UJIH6HNQ6LOTZ5T6M27Y23KC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: NAN handling in statistics functions
Perhaps a math.hasnan() function for collections could be implemented with
binary search?
math.hasnan(seq)
Though it is true that if you're using datasets large enough to care about
speed, you should probably be using the SciPy stack instead of statistics
in the first place.
On Fri, Aug 27, 2021, 11:25 AM Christopher Barker
wrote:
> If folks want faster processing (checking for, replacing) of NaNs in
> sequences, a function written in C could be added to the math module. Or
> the statistics module)
>
> Now that I said that, it might make sense to put such a function in the
> statistics package, for use their anyway.
>
> Personally, I think if you are working with large enough datasets to care,
> you probably should use numpy anyway.
>
> -CHB
>
> On Fri, Aug 27, 2021 at 3:39 AM Jeff Allen wrote:
>
>> On 26/08/2021 19:41, Brendan Barnwell wrote:
>>
>> On 2021-08-23 20:53, Steven D'Aprano wrote:
>>
>> So I propose that statistics functions gain a keyword only parameter to
>> specify the desired behaviour when a NAN is found:
>>
>> - raise an exception
>> - return NAN
>> - ignore it (filter out NANs)
>>
>> which seem to be the three most common preference. (It seems to be
>> split roughly equally between the three.)
>>
>> Thoughts? Objections?
>>
>> I'd like to suggest that there isn't a single answer that is most natural
>> for all functions. There may be as few as two.
>>
>> Guido's proposal was that mean return nan because the naive arithmetic
>> formula would return nan. The awkward first example was median(), which is
>> based on order (comparison). Now Brendan has pointed out:
>>
>> One important thing we should think about is whether to add similar
>> handling to `max` and `min`. These are builtin functions, not in the
>> statistics module, but they have similarly confusing behavior with NAN:
>> compare `max(1, 2, float('nan'))` with `max(float('nan'), 1, 2)`.
>>
>> The real behaviour of max() is to return the first argument that is not
>> exceeded by any that follow, so:
>>
>> >>> max(nan, nan2, 1, 2) is nan
>> True
>> >>> max(nan2, nan, 1, 2) is nan2
>> True
>>
>> As a definition, that is not as easy to understand as "return the largest
>> argument". The behaviour is because in Python, x>nan is False. This choice,
>> which is often sensible, makes the set of float values less than totally
>> ordered. It seems to me to be an error in principle to apply a function
>> whose simple definition assumes a total ordering, to a set that cannot be
>> ordered. So most natural to me would be to raise an error for this class of
>> function.
>>
>> Meanwhile, functions that have a purely arithmetic definition most
>> naturally return nan. Are there any other classes of function than
>> comparison or arithmetic? Counting, perhaps or is that comparison again?
>>
>> Proposals for a general solution, especially if based on a replacement
>> value, are more a question of how you would like to pre-filter your set. An
>> API could offer some filters, or it may be clearer left to the caller. It
>> is no doubt too late to alter the default behaviour of familiar functions,
>> but there could be a "strict" mode.
>>
>> --
>>
>> Jeff Allen
>>
>> ___
>> 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/FQNZLNISKHV74CYJMU2HPG5273VMWXUK/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
> ___
> 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/7CQK5AOT4L5IN4YVVSG7JONAQQCHN6CO/
> 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/LML46EUS4APAZWD2YFTIKV2PMZL25NBY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: synatx sugar for quickly run shell command and return stdout of shell command as string result
> But Python isn't a language that needs everything to be done with
command invocations and pipes. If you're doing long pipelines like
this, there's probably something wrong. Why use external programs to do
things that Python can do far more viably itself?
That's a really good point. I think the main use case is scripts run from
the command line, like pip or virtualenv, for example. It's uncommon enough
that's it's definitely not necessary.
The "grep hello | sort | cat file.txt" example is just that: an example.
I'm no expert on system calls from within Python. Does it open a new
process that Python doesn't have to wait on? If so, it might be more viable.
On Thu, Aug 26, 2021, 9:22 PM Chris Angelico wrote:
> On Fri, Aug 27, 2021 at 1:15 PM Finn Mason wrote:
> >
> > > Is this too magical?
> > > result = run('cat file.txt') | run('sort) | run('grep hello',
> capture_output=True, text=True).stdout
> >
> > Interesting idea, especially overloading the union/pipe operator (|). I
> like it a lot. It reminds me of pathlib.Path (which is a wonderful tool),
> with its slash operator overload.
> > Python is supposed to be easy to read and understand, and anything that
> makes complicated system stuff less messy is welcome, I think.
>
> It's perfectly legal to do this sort of thing, but it doesn't really
> belong in the stdlib (more on that later).
>
> > Another idea (which I am less in favor of) is a more functional
> approach, like:
> >
> > run('grep hello', run('sort', run('cat file.txt')))
> >
>
> That's a bit more viable. I'd be inclined to have a keyword argument
> here, for instance:
>
> run('grep hello', stdin=run('sort', sttdin=run('cat file.txt')))
>
> but I agree, it makes good sense to have an argument able to take a
> variety of data types, including another program's output.
>
>
> But Python isn't a language that needs everything to be done with
> command invocations and pipes. If you're doing long pipelines like
> this, there's probably something wrong. Why use external programs to
> do things that Python can do far more viably itself?
>
> with open('file.txt') as f:
> result = [l.strip("\r\n") for l in sorted(f) if "hello" in l]
>
> Trying to make a more Pythonic syntax for an operation that Python
> does better in a completely different way is a bit of a half-hearted
> solution. I'd recommend either sticking to a full "run the shell and
> hand it this command line", or going the whole way and doing the job
> 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/WUZH3G46CUIEMMVOKAMOG6W5KKXB5RS5/
> 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/WOJPANCRKCDPHQKWDTZVPTYRAETJ4H7T/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: synatx sugar for quickly run shell command and return stdout of shell command as string result
> Is this too magical?
> result = run('cat file.txt') | run('sort) | run('grep hello',
capture_output=True, text=True).stdout
Interesting idea, especially overloading the union/pipe operator (|). I
like it a lot. It reminds me of pathlib.Path (which is a wonderful tool),
with its slash operator overload.
Python is supposed to be easy to read and understand, and anything that
makes complicated system stuff less messy is welcome, I think.
Another idea (which I am less in favor of) is a more functional approach,
like:
run('grep hello', run('sort', run('cat file.txt')))
In this version, it looks more like Python functions than pipes, where the
last (optional) argument is what's piped in. This makes more sense in a
functional context and may eliminate the need for capture_output=True,
text=True, .stdout, and similar idioms.
Like I said, I'm not as much in favor of this, though, because it doesn't
resemble an actual call as much. However, it's still an idea.
It might be helpful to point out that Jeremiah's version would have to be
implemented as a class because of the union operator overload.
On Thu, Aug 26, 2021, 8:44 PM Jeremiah Paige wrote:
>
>
> On Thu, Aug 26, 2021 at 5:53 AM Evan Greenup via Python-ideas <
> python-ideas@python.org> wrote:
>
>> Currently, when what to execute external command, either os.system() or
>> subprocess functions should be invoked.
>>
>> However, it is not so convenient, it would be nice to use "``" symbol to
>> brace the shell command inside.
>>
>> like:
>>
>> stdout_result_str = `cat file.txt | sort | grep hello`
>>
>> Its is enhanced feature which combine both subprocess and os.system
>>
>> Because, subprocess can return output of file, but does not support pipe
>> in command.
>>
>
> subprocess.run('cat file.txt | sort |grep hello', shell=True
> capture_output=True, check=True, text=True, encoding="utf8").stdout
> you can use any piping or redirection you like.
>
> However, I do like the idea of run() having the ability to easily chain
> commands without the need to pull in the shell.
> Is this too magical? result = run('cat file.txt') | run('sort) | run('grep
> hello', capture_output=True, text=True).stdout
> I'm sure there are other approaches. We don't often have to worry about
> file handles in python, and it would be nice
> to remove this worry from subprocess pipes even more than it already is.
> ___
> 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/TXUDW3XOKASHSYD4JJYOFXCBFRXPGS5H/
> 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/O36BRLR4Q2NULI3HQQY27ALZCJ362U3Q/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
Tim, you're right. I'm sorry. When this was first posted, I was sure it would be resolved quickly and easily. I very badly communicated that. On Thu, Aug 26, 2021, 12:59 AM Tim Hoffmann wrote: > Hi Finn, > > as a personal feedback: I perceive this comment as disrespectful and not > welcoming. I've been trying to make a constructive contribution and this > comment comes across as "Hooray we got rid of that/him. And anyway the > suggestion was nonsensical. Why have we been talking about it at all?". > It's hard to read context from a short mail. Maybe I'm misinterperting. If > not, it's still your right to feel that way, but please reconsider if it's > necessary to post such comments. > > Tim > > Finn Mason hat am 26.08.2021 01:50 geschrieben: > > > Yay, it's over! > (I can't believe it got this much attention.) > > On Wed, Aug 25, 2021, 3:19 PM Tim Hoffmann via Python-ideas < > python-ideas@python.org> wrote: > > Ok, I have no problem ignoring PEP-8 where it's not applicable. I've > brought this topic up, because I thought there could be a improvement > either in PEP-8 and/or by adding something to the language. I still do > think that, but I accept that the problem it solves is not considered > relevant enough here to take further action. > > Anyway, thanks all for the discussion! > > Tim > ___ > 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/HXW4IDNA5D4XBVJROGBKM2XQ6GTG5IVJ/ > 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/Z5DS56L26HKKTIZ4TBSVQW4NXPACIERI/ > 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/DNKVE6NELDUJG3AF6BG2DUPSABWLVP3Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add explicit method overloading to STL
> You may also be interested in a package I wrote for doing this kind of thing: > https://pypi.org/project/signature-dispatch/ After reading about this project, I'm interested in the idea of callable modules in Python. However, that's another issue for another day and another person. On Wed, Aug 25, 2021, 6:46 PM Finn Mason wrote: > >> Don't know if this is already a PEP, but I'd love to see something like > this > >> < > https://www.codementor.io/@arpitbhayani/overload-functions-in-python-13e32ahzqt > > > >> in > >> Python— a decorator @overload that creates multiple copies of > >> functions/methods based on their arguments' types. (This is much > narrower > >> in scope than PEP 3124, before anyone asks.) > > Do you mean something like functools.singledispatch? > > It seems there are already tools for overloading. In terms of type hints, > there's @typing.overload. > From what I can tell, overloading the implementation is generally frowned > upon in Python. > I'd like to know how your idea is different from PEP 3124. Could you > please explain? > ___ 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/3CLGWTLPONUDKT5RGNAWRKKE5POKAIMV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add explicit method overloading to STL
>> Don't know if this is already a PEP, but I'd love to see something like this >> < https://www.codementor.io/@arpitbhayani/overload-functions-in-python-13e32ahzqt > >> in >> Python— a decorator @overload that creates multiple copies of >> functions/methods based on their arguments' types. (This is much narrower >> in scope than PEP 3124, before anyone asks.) > Do you mean something like functools.singledispatch? It seems there are already tools for overloading. In terms of type hints, there's @typing.overload. >From what I can tell, overloading the implementation is generally frowned upon in Python. I'd like to know how your idea is different from PEP 3124. Could you please explain? ___ 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/JK7GVLALAZTNJPZ3S65KDNZHKAPQKJGE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: NAN handling in statistics functions
Perhaps a warning could be raised but the NaNs are ignored. For example:
Input: statistics.mean([4, 2, float('nan')])
Output: [warning blah blah blah]
3
Or the NaNs could be treated as zeros and a warning raised:
Input: statistics.mean([4, 2, float('nan')])
Output: [warning blah blah blah]
2
I do feel there should be a catchable warning but not an outright
exception, and a non-NaN value should still be returned. This allows
calculations to still quickly and easily be made with or without NaNs, but
an alternative course of action can be taken in the presence of a NaN value
if desired.
In any case, the current behavior should definitely be changed.
On Tue, Aug 24, 2021, 1:46 AM Marc-Andre Lemburg wrote:
> On 24.08.2021 05:53, Steven D'Aprano wrote:
> > At the moment, the handling of NANs in the statistics module is
> > implementation dependent. In practice, that *usually* means that if your
> > data has a NAN in it, the result you get will probably be a NAN.
> >
> > >>> statistics.mean([1, 2, float('nan'), 4])
> > nan
> >
> > But there are unfortunate exceptions to this:
> >
> > >>> statistics.median([1, 2, float('nan'), 4])
> > nan
> > >>> statistics.median([float('nan'), 1, 2, 4])
> > 1.5
> >
> > I've spoken to users of other statistics packages and languages, such as
> > R, and I cannot find any consensus on what the "right" behaviour should
> > be for NANs except "not that!".
> >
> > So I propose that statistics functions gain a keyword only parameter to
> > specify the desired behaviour when a NAN is found:
> >
> > - raise an exception
> >
> > - return NAN
> >
> > - ignore it (filter out NANs)
> >
> > which seem to be the three most common preference. (It seems to be
> > split roughly equally between the three.)
> >
> > Thoughts? Objections?
>
> Sounds good. This is similar to the errors argument we have
> for codecs where users can determine what the behavior should be
> in case of an error in processing.
>
> > Does anyone have any strong feelings about what should be the default?
>
> No strong preference, but if the objective is to continue calculations
> as much as possible even in the face of missing values, returning NAN
> is the better choice.
>
> Second best would be an exception, IMO, to signal: please be explicit
> about what to do about NANs in the calculation. It helps reduce the
> needed backtracking when the end result of a calculation
> turns out to be NAN.
>
> Filtering out NANs should always be an explicit choice to make.
> Ideally such filtering should happen *before* any calculations
> get applied. In some cases, it's better to replace NANs with
> use case specific default values. In others, removing them is the
> right thing to do.
>
> Note that e.g. SQL defaults to ignoring NULLs in aggregate functions
> such as AVG(), so there are standard precedents for ignoring NAN values
> per default as well. And yes, that default can lead to wrong results
> in reports which are hard to detect.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Aug 24 2021)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
>
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
> https://www.malemburg.com/
>
> ___
> 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/L5QB4GUPYXNYBFKG43VSGOWVE27Y5BIF/
> 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/SSGI4JJMLXU52QMB2BRTSII7YBII2N7R/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
Yay, it's over! (I can't believe it got this much attention.) On Wed, Aug 25, 2021, 3:19 PM Tim Hoffmann via Python-ideas < python-ideas@python.org> wrote: > Ok, I have no problem ignoring PEP-8 where it's not applicable. I've > brought this topic up, because I thought there could be a improvement > either in PEP-8 and/or by adding something to the language. I still do > think that, but I accept that the problem it solves is not considered > relevant enough here to take further action. > > Anyway, thanks all for the discussion! > > Tim > ___ > 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/HXW4IDNA5D4XBVJROGBKM2XQ6GTG5IVJ/ > 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/Z5DS56L26HKKTIZ4TBSVQW4NXPACIERI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
I agree with Guido. The only problem here is third-party libraries that don't use bool() to indicate emptiness. If you need to support those, use len(). But this doesn't mean a change to the standard library, because those third-party libraries are, well, third-party. We don't need a more explicit way to specify emptiness. bool(seq) is fine. On Wed, Aug 25, 2021, 8:05 AM Guido van Rossum wrote: > My conclusion is that you should ignore PEP 8 for your use case and write > “if len(a) == 0”. > > On Wed, Aug 25, 2021 at 06:13 Tim Hoffmann via Python-ideas < > python-ideas@python.org> wrote: > >> Guido van Rossum wrote: >> > So then the next question is, what's the use case? What code are people >> > writing that may receive either a stdlib container or a numpy array, and >> > which needs to do something special if there are no elements? Maybe >> > computing the average? AFAICT Tim Hoffman (the OP) never said. >> >> There's two parts to the answer: >> >> 1) There functions e.g. in scipy and matplotlib that accept both numpy >> arrays and lists of flows. Speaking from matplotlib experience: While >> eventually we coerce that data to a uniform internal format, there are >> cases in which we need to keep the original data and only convert on a >> lower internal level. We often can return early in a function if there is >> no data, which is where the emptiness check comes in. We have to take extra >> care to not do the PEP-8 recommended emptiness check using `if not data`. >> >> 2) Even for cases that cannot have different types in the same code, it >> is unsatisfactory that I have to write `if not seq` but `if len(array) == >> 0` depending on the expected data. IMHO whatever the recommended syntax for >> emptiness checking is, it should be the same for lists and arrays and >> dataframes. >> ___ >> 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/Q6KZEXFLJ6TEFSDQM3SXXIVGNFNURPYT/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > ___ > 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/JVNSGTXFPCODPGEPX2N4SWB7LIMPGTVS/ > 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/DT2LCRXU5PNEJTM53CMFLELVZW7DCCJJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add check_methods function to standard library
Sorry, the formatting was terrible. I copy and pasted it from the original issue without really thinking about it. Here's the same thing, but actually readable: In _collections_abc.py is a private function titled _check_methods(). It takes a class and a number of method names (as strings), checks if the class has all of the methods, and returns NotImplemented if any are missing. The code is below: def _check_methods(C, *methods): mro = C.__mro__ for method in methods: for B in mro: if method in B.__dict__: if B.__dict__[method] is None: return NotImplemented break else: return NotImplemented return True This is an incredibly convenient function (referred to as check_methods here on out) for creating abstract base classes, and is much simpler than using hasattr for each method you want to check. For example: from abc import ABCMeta # Without check_methods class A(metaclass=ABCMeta): @classmethod def __subclasshook__(cls, subclass): return (hasattr(subclass, 'foo') and callable(subclass.foo) and hasattr(subclass, 'bar') and callable(subclass.bar) or NotImplemented) # With check_methods class B(metaclass=ABCMeta): @classmethod def __subclasshook(cls, subclass): return check_methods(subclass, 'foo', 'bar') This would be a great function to add to the standard lib, perhaps in the abc module. One problem with check_methods() as defined in _collections_abc.py is that it doesn't check if the name is callable. Also, type hints and more readable variables may be desirable. The final code, if implemented, may look something like this: # In imports section: from typing import Literal def check_methods(Class: type, *methods: str) -> Literal[True, NotImplemented]: """Check if class `Class` has methods `methods`.""" mro = Class.__mro__ for method in methods: for Base in mro: if (attr := getattr(Base, method, None)) is not None: if not callable(attr): return NotImplemented break else: return NotImplemented return True Again, this would be a great function to add to the `abc` module or a similar one. I've proposed this in issue 44941. Another possible implementation may be similar to a dataclass that implements __subclasshook__ for you with the desired method checks. -- Finn ___ 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/H67HZERAUVCKTV5UH4QI7A7T536PCE7N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
While this does comply with "explicit is better than implicit", there's another line of the Zen of Python that this idea definitely violates: "There should be one-- and preferably only one-- obvious way to do it." (Followed by the line "Although that way may not be obvious at first...", which I'd say also applies; after all, the boolean value of a sequence may not be obvious to a new Python programmer.) The way I see it, the issue is a conflict between these two ideas of what Python code should look like. My strong opinion is against adding isempty(); I see no point. Once you learn Python, it makes sense that an empty sequence is False. I think most Python coders learn that early on. We get it. The "if (not) seq" idiom makes sense, especially since everyone has been doing that for the last twenty years. It's readable. If this is about the fundamentally unknowable type of seq, use type hints. And if you really want to be that explicit, use "if len(seq) == 0" (which could be just "if len(seq)" but that's ruins the whole point). I think isempty() doesn't solve problems. It's completely unnecessary. And if it's somehow actually implemented, implement it as a method of sequence types! A built-in function should either be totally necessary (see: print(), input(), all the basic ones you know and love), or at least make a job much easier and more readable (see: zip(), enumerate(), all(), any(), and more). Python may be a language designed to be readable, but even it isn't English and doesn't need to be. -- Finn ___ 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/BXPL4NYYOSS66LIHNY6GJH3KJCHUDGPD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add check_methods function to standard library
Hello, In _collections_abc.py is a private function titled `_check_methods`. It takes a class and a number of method names (as strings), checks if the class has all of the methods, and returns NotImplemented if any are missing. The code is below: ``` def _check_methods(C, *methods): mro = C.__mro__ for method in methods: for B in mro: if method in B.__dict__: if B.__dict__[method] is None: return NotImplemented break else: return NotImplemented return True ``` This is an incredibly convenient function (referred to as check_methods here on out) for creating abstract base classes, and is much simpler than using `hasattr` for each method you want to check. For example: ``` >>> from abc import ABCMeta >>> # Without check_methods >>> class A(metaclass=ABCMeta): ... @classmethod ... def __subclasshook__(cls, subclass): ... return (hasattr(subclass, 'foo') and ... callable(subclass.foo) and ... hasattr(subclass, 'bar') and ... callable(subclass.bar) or ... NotImplemented) ... >>> # With check_methods >>> class B(metaclass=ABCMeta): ... @classmethod ... def __subclasshook(cls, subclass): ... return check_methods(subclass, 'foo', 'bar') ... >>> ``` This would be a great function to add to the standard lib, perhaps in the `abc` module. One problem with `check_methods` as defined in _collections_abc.py is that it doesn't check if the name is callable. Also, type hints and more readable variables may be desirable. The final code, if implemented, may look something like this: ``` # In imports section: from typing import Literal def check_methods(Class: type, *methods: str) -> Literal[True, NotImplemented]: """Check if class `Class` has methods `methods`.""" mro = Class.__mro__ for method in methods: for Base in mro: if (attr := getattr(Base, method, None)) is not None: if not callable(attr): return NotImplemented break else: return NotImplemented return True ``` Again, this would be a great function to add to the `abc` module or a similar one. I've proposed this in issue 44941. Another possible implementation may be similar to a dataclass that implements __subclasshook__ for you with the desired method checks. --Finn ___ 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/HGYBHDH6ZCSYUERI55R6JQSJMX52NNR7/ Code of Conduct: http://python.org/psf/codeofconduct/
