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._
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 s
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
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
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 improvemen
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
>> 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 i
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
> >
> >> i
ort 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
> 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 ov
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?
> > >
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
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
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`
...
Trac
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
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 re
ls
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 Juan
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
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
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 like
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
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'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 to
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 ;)
>>
>
>
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
versionin
ict.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/m
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
> > s
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
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 al
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 effe
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 alre
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 =
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
consist
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?
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 matches
Mail list logo