I'm interested in proposing several additions to the Python standard
library, and I would like more information on the procedure for doing so.
Are all additions done via a PEP? If not what is the procedure. If so, I've
read that the first step was to email this board and get feedback.
I have a
r usefulness of any of these functions to the
stdlib?
On Sat, Nov 10, 2018 at 9:14 PM Steven D'Aprano wrote:
> On Sat, Nov 10, 2018 at 08:36:52PM -0500, Jonathan Crall wrote:
> > I'm interested in proposing several additions to the Python standard
> > library, and I would like more information
ginal question by the OP.
>
> Another interesting issue is the granularity of such a project. I
> sometimes, and somewhat foolishly, make libraries such as toolz or boltons
> a dependency of my projects, for just one or two function calls from my
> code.
>
> Regards,
>
> S.
Based on the conversation so far, I agree with @Kyle Stanley's breakdown of
the proposal. I think shelving the "*Add a new way to create and specify
executor*" and focusing on "*Add a SerialExecutor, which does not use
threads or processes*" is the best way forward.
For context, I'm a machine
I'd like to propose an improvement to `concurrent.futures`. The library's
ThreadPoolExecutor and ProcessPoolExecutor are excellent tools, but there
is currently no mechanism for configuring which type of executor you want.
Also, there is no duck-typed class that behaves like an executor, but does
ve it.
On the other hand I think a SerialExecutor is something that is sorely
missing from the standard library.
On Sat, Feb 15, 2020 at 5:16 PM Andrew Barnert wrote:
> > On Feb 15, 2020, at 13:36, Jonathan Crall wrote:
> >
> > Also, there is no duck-typed class that behaves like an e
For what its worth, I find the proposed syntax confusing and difficult to
read. Conceptually it makes sense, but using existing set operations seems
like a far more readable way to handle this case.
On Tue, Dec 31, 2019 at 11:03 AM Richard Damon
wrote:
> On 12/31/19 1:20 AM,
Given that this is unlikely to see any change in core Python, perhaps you
can get a decent solution with a third party library? If your main issue is
that repr doesn't provide an "eval-able" string, then may I suggest using
the "most-used" function in the ubelt utility library: ubelt.repr2
Two
I just want to point out that I can think of a valid use case for `clf`.
I'm not sure if it was mentioned.
In the case where you have a script that produces a lot of output, a common
task might be scrolling to the beginning to check an output. If your screen
was not fresh, and you had a lot of
they advertised as reusable used this (but then again I also
get peeved when people execute print statements at import time).
On Fri, Oct 16, 2020 at 5:02 PM Paul Moore wrote:
> On Fri, 16 Oct 2020 at 20:43, Jonathan Crall wrote:
> >
> > @Chris Angelico If you are more application foc
0 at 5:40 AM Jonathan Crall wrote:
> >
> > I just want to point out that I can think of a valid use case for `clf`.
> I'm not sure if it was mentioned.
> >
> > In the case where you have a script that produces a lot of output, a
> common task might be scrolling to the b
FWIW I'm +1 on `d.keys()[i]`, `d.values()[i]`, `d.items()[i]`. I don't
see any major issue with adding a __getitem__ to the view classes. I think
it's a great idea, and it would make my life easier and would replace the
primary use case where I currently use `ubelt.peek
I disagree that doing arithmetic on boolean variables doesn't make sense.
Indicator variables which take a value of either zero are one are extremely
common. Dirac or Kronecker delta functions are also examples of functions
where it arithmetically makes sense to talk about values in the boolean
I wouldn't mind if this *only *worked for the specific characters "print".
However, I think that allowing developers to call complex methods without
parentheses will lead to very difficult to read code.I think that
surrounding arguments with non-whitespace buffer characters is important
for
h is the only reason I'm giving it special status.
Regardless, I'd rather not have this feature. As you said it's not 100%
backwards compatible, so the usefulness is limited.
On Thu, Jun 11, 2020 at 11:49 AM Steven D'Aprano
wrote:
> On Wed, Jun 10, 2020 at 08:00:26PM -0400, Jonathan Crall wrote
Thanks for the link, the rationale for rejection seems reasonable.
On Fri, Dec 11, 2020 at 8:19 PM Chris Angelico wrote:
> On Sat, Dec 12, 2020 at 11:42 AM Jonathan Crall
> wrote:
> >
> > I'm not sure if this has been asked / suggested before.
> >
> > I'm wond
I'm not sure if this has been asked / suggested before.
I'm wondering if there is any interest in conditional or loop-based `with`
statements. I think it could be done without a syntax change.
### Napkin proposal
Context managers could define `__if__` or `__for__`, and if those dunder
methods
@Iasizoillo
> Only if you don't setup vars like official example* or not calc some
statistic after timered block
I wrote the official docs, so I'm aware of that case. In the case where
setup
variables are required it make sense to me to have an extra level of
indentation. It just bothers me that
I'd like to give a shoutout to a package I wrote called mkinit, which helps
autogenerate explicit `__init__.py` files to mitigate some of the issues
you mentioned (especially with respect to `from blah import *`).
https://github.com/Erotemic/mkinit
On Sat, Apr 10, 2021 at 3:08 PM Guido van
I ran into another case where I wish I had some sort of conditional if.
I was writing code to cache autogenerated demodata.
import ubelt as ub
from os.path import join
import json
kwargs = {'example': 'config'}
dpath = ub.ensure_app_cache_dir('my_modname', 'demodata')
ote:
> Hello,
>
> On Sat, 6 Feb 2021 19:57:33 -0500
> Jonathan Crall wrote:
>
> > I ran into another case where I wish I had some sort of conditional
> > if.
>
> Right, conditional "if" is exactly what we miss in Python.
>
> Yes, it's a typo, but i
That's effectively every module I write. I don't think that's uncommon or
bad practice.
On Sat, Oct 2, 2021, 12:05 AM Chris Angelico wrote:
> On Sat, Oct 2, 2021 at 2:01 PM Jonathan Crall wrote:
> >
> > @Steven D'Aprano Yes my original post is somewhat pithy and has som
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
Python just checking that there is a dunder main
function, and calling it. That would be in the spirit of dunder getattr,
which imo is one of the best improvements Python has made.
On Fri, Oct 1, 2021, 9:01 PM Steven D'Aprano wrote:
> On Fri, Oct 01, 2021 at 03:35:26PM -0400, Jonathan Cr
gt; Behavior:
>>
>> 1. Load module as normal.
>> 2. If __name__ is "__main__" or module is named in python -m, call
>> __main__ function.
>>
>> Paul
>>
>>
>> On Fri, 2021-10-01 at 15:35 -0400, Jonathan Crall wrote:
>>
>&g
le as normal.
> 2. If __name__ is "__main__" or module is named in python -m, call
> __main__ function.
>
> Paul
>
>
> On Fri, 2021-10-01 at 15:35 -0400, Jonathan Crall wrote:
>
> I was curious if / what sort of proposals have been considered for
> sim
@Marc-Andre
One of the motivations of this proposal is to incentivize writing code in a
local scope, rather than a global one. People in this thread have made the
argument "Python is a scripting language, so it should do that". Ok, fine.
Yes `print('hello world')` is more idiomatic than the one
IMO (a subset of) pytest is the superior unit-testing framework. Just
having functions prefixed with `test_` is easy and intuitive. It also works
well with xdoctest, but I would use it even if that wasn't the case. (That
being said, I think the current implementation of fixtures - where you
can't
Not a huge fan of an f-prefix for a frozen set (I prefer just recognizing
the case and optimizing the byte code, I don't think frozensets are used
often enough to justify its own syntax), but I love {,} for an empty set.
On Tue, Jan 18, 2022 at 4:13 PM Rob Cliffe via Python-ideas <
y done via the Python C-API, but in terms of keeping things
lightweight, I might need some help on how to effectively use the wide
c-string API to implement this.
On Mon, Apr 10, 2023 at 4:46 AM Barry wrote:
>
>
> On 10 Apr 2023, at 02:18, Jonathan Crall wrote:
>
>
> There's no
the
feature to CPython?
On Sun, Apr 9, 2023 at 4:09 PM Barry Scott wrote:
>
> On 04/04/2023 15:18, Jonathan Crall wrote:
>
> I have what I think is a fairly low impact quality of life improvement to
> suggest for the python CLI.
>
> When I'm not working in Python I tend to be working
I have what I think is a fairly low impact quality of life improvement to
suggest for the python CLI.
When I'm not working in Python I tend to be working in bash. But often I
want to break out and do something quick in Python. I find the `python -c `
CLI very useful for this. For one liners it's
I like the idea of a vetted package index that pip can point to. The more I
think about it, the more I think that it needs some sort of peer review
system as the barrier to entry, and my thoughts to to establishing some
DeSci DAO that could distribute the peer review of packages amongst a set
of
> On Mon, Jul 24, 2023 at 10:04 AM Chris Angelico wrote:
> can you tell me what this vetting procedure proves that isn't already
proven by mere popularity itself?
I think that's what this thread is trying to discuss. Do I have the exact
perfect implementation? No. But I imagine it to be akin to
If popular packages weren't favored that would be a problem. Popularity
should be correlated with "trustworthiness" or whatever the metric this
curated repo seeks to maximize. I think the important thing is that the
packages are both popular and have passed some sort of vetting procedure.
For
35 matches
Mail list logo
