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
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?
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
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
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
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
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
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
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 wa
xable
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-idea
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
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'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
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'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
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
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,
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
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
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
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 F
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`
...
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
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,
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) |
> 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
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.)
&g
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
> >> P
>> 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
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
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
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
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
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
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 =
35 matches
Mail list logo
