's docs, and is
exactly what this idea is all about.
My question is why? Was there an objection for implementing such a thing,
or was it complex enough to postpone for the time being?
On Tue, Sep 29, 2020 at 2:51 PM Bar Harel wrote:
> I think it can be easily solved much like a normal
he methods were defined
dynamically. Plus it'll support dynamic __getattr__ on a child metaclass as
an added bonus.
Bar Harel.
On Thu, Sep 24, 2020, 7:28 PM Ben Avrahami wrote:
>
>
> On Thu, Sep 24, 2020 at 7:02 PM Eric V. Smith wrote:
>
>> Does anyone know if attrs handl
I've found a note about this from Guido back in 2000:
https://mail.python.org/archives/list/python-...@python.org/thread/BIAEXJPSO4ZSUAEKYHGHSOIULSMV3CYK/#HURE3EIQLNHVSMTUSUHGCQF5IGIN7XVE
Not sure if it went anywhere back then.
On Tue, Aug 25, 2020 at 4:27 PM Ben Avrahami wrote:
> consider the
>
> Given dict.setdefault, a parallel method like set.add_unique, which
> returns the existing element or None, might be the better approach.
>
Although it breaks the convention of these methods returning the item, I'm
not sure returning the element is a good idea.
"set.add_unique(None)" will ret
I believe I'm -0 for modifying the existing add() and +0 for a new function.
By the way, a good phrasing of the general mutating/non-mutating convention
opens the built-in types section of the docs:
"Some collection classes are mutable. The methods that add, subtract, or
rearrange their members i
Since there's no standard for this in json, deciding to serialize to str is
quite arbitrary.
I personally serialize UUIDs to binary data as it takes less space.
Some serialize it to hexadecimal.
Tbh, it sounds like a good idea but can have it's pitfalls.
On Wed, Jun 10, 2020, 4:43 PM J. Pic wr
>
> But if the libraries are already doing logging, can't I already do that?
>
> And if the libraries aren't doing logging, this won't magically add
> logging to them, will it?
>
As a best practice, libraries log into a NullHandler to avoid setting up
the root logger, and to prevent sending messag
It's one thing to say that the interpreter takes care of importing
logging and setting up a basic logger, and that's great, but I still
have to import logging and call the `logging.info(...)` functions,
so what does this proposal give us, *in detail* please, and how do I use
it?
You would be able
o kills me with
obscure error messages, you're welcome to give it a go :-)
Thank you for being awesome!
Bar Harel
On Sat, Jun 6, 2020 at 1:40 AM wrote:
> Did this idea ever went anywhere? I thought I saw a bpo issue for this but
> I can't find it anymore and it's not present i
Hey Steve,
How about set.symmetric_difference()?
Does it not do what you want?
Best regards,
Bar Harel
On Sun, Mar 22, 2020, 10:03 PM Steve Jorgensen wrote:
> Currently, the `issubset` and `issuperset` methods of set objects accept
> arbitrary iterables as arguments. An iterable that i
Last resort logger works only if no handlers are set.
NullHandler for example is used on most libraries in order to prevent
setting up the logging system, but it can cause errors not to show.
Also, LastResort is set for the "Warning" level. -L will give you
the flexibility you need in order to deb
-L will act as logging.basicConfig(level=level), but on a temporary
basis, much like -W sets warning's filters.
If you don't setup logging, or don't want to (cause you're checking some
library functions), this will be super handy.
If you do setup logging, it has the same caveats as setting the wa
0, 2020 at 8:51 AM Mike Miller
> wrote:
>
>>
>> On 2020-02-19 17:12, Bar Harel wrote:
>> > Another idea I've had that may be of use:
>> >
>> > PYTHONLOGGING environment variable.
>> >
>> > Setting PYTHONLOGGING to any log level or level
>
> > If you want it only temporarily for debugging purposes, or permanently
> for all scripts in your system, it's not really feasible.
>
> Hmm, I'm not sure that I like the idea of overriding the default logging
> level being set system-wide, or that there would be an especially strong
> use case
here a practical reason why the above doesn't work for you? Otherwise, I
>> see no reason to add a new environment variable that effectively does the
>> same thing.
>>
>>
>> On Wed, Feb 19, 2020 at 8:16 PM Bar Harel wrote:
>>
>>> Another idea I
Will be useful mostly for debugging purposes instead of temporarily
modifying the code.
Kinda surprised it doesn't exist tbh.
Bar Harel
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@
developer's
name, much like PyPa or aio-libs.
These questions are eventually up for discussion. I'm just a single
developer with a small perspective, and don't pretend to know the answer :-)
Perhaps more devs will weigh in and give their opinion.
Always happy to learn,
Bar
grammer uses it irresponsibly (shame), we still have
future.result(timeout) to cover us and issue a warning if we must.
Any inputs would be appreciated,
Bar Harel.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
async and function calls to await.
This creates a lot of work, from porting code to maintaining both variants,
to just having code duplication all around.
Not necessarily using this syntax, a way for making decorators support both
normal and async, could be a first step towards shared codebase.
-
problem, makes sense, we can even implement an
itemsetter much like itemgetter for completeness, as the implementation
will probably be easy and well understood.
What do you say?
-- Bar Harel
On Tue, Oct 22, 2019, 3:25 AM Kyle Lahnakoski
wrote:
>
> On 2019-10-21 10:44, gedizgu...@gmail.com
would have either changed the signature of the executor
creation to have a new 'max_queue' keyword-only argument, or allow you to
enter the queue as an input, but I still believe that any attempt to create
such an interface will just cause more complications than the simple 3 line
sol
On Wed, Sep 4, 2019, 10:40 PM Dan Sommers <
2qdxy4rzwzuui...@potatochowder.com> wrote:
> I'm sure I'm missing something, but isn't that the point of a
> ThreadPoolExecutor? Yes, you can submit more requests than you
> have resources to execute concurrently, but the executor itself
> limits the nu
o matter what kind of asynchronous
work you do. Why change it?
Sincerely,
Bar Harel
___
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.
Aren't you able to catch the cancellation error and retrieve the data from
the inner task's .result()?
On Wed, Jul 31, 2019, 8:00 AM Guido van Rossum wrote:
> I wonder if Nathaniel has something to add? Trio has a different approayto
> cancellation. Of course it is also an entirely new library..
I'm with Steven D`Aprano here. Implicit string concat, in my experience, is
something clear, concise and convenient.
I've had a bug because of it only once or twice during my whole career, and
not only that "occasional" bug would have occurred either way because of a
missing comma or plus sign, bu
I have a simple way to solve this I believe.
Why not just expose "_chain_future()" from asyncio/futures.py to the
public, instead of copying and pasting parts of it?
It already works, being used everywhere in the stdlib, it supports both
asyncio and concurrent.futures, it's an easily testable ext
A bit radical but do you believe we can contact Google to alter the search
results?
It's for the benefit of the user after all, and many just switch to python
3 in the version picker anyway.
On Thu, Sep 7, 2017, 4:18 AM Guido van Rossum wrote:
> That's a good idea. Could you suggest it to
> http
we care about
> personally, and some of us sometimes volunteer to mentor users who show an
> interest in learning. IMO posting "bump" several times does not exhibit
> such interest.
>
> On Sun, May 14, 2017 at 9:37 AM, Bar Harel wrote:
>
>> I guess so.
>>
>&
into the
>> stdlib works? Just posting "bump" messages to the mailing list doesn't
>> really help, it just sounds rude.If you need help understanding how to
>> add/improve a stdlib module, please ask a specific about that topic.
>>
>> On Sun, May 14, 2017
Bump
On Wed, Jan 4, 2017, 8:01 PM Lisa Roach wrote:
> +1 to this as well, I think this would be really useful in the stdlib.
>
> On Mon, Dec 26, 2016 at 5:40 AM, Bar Harel wrote:
>
>> Any updates with a singledispatch for methods?
>>
>> On Tue, Sep 20, 2016, 5:49
Any updates with a singledispatch for methods?
On Tue, Sep 20, 2016, 5:49 PM Bar Harel wrote:
> At last! Haven't used single dispatch exactly because of that. Thank you
> savior!
> +1
>
> On Tue, Sep 20, 2016, 6:03 AM Tim Mitchell
> wrote:
>
>> Hi All,
>
At last! Haven't used single dispatch exactly because of that. Thank you
savior!
+1
On Tue, Sep 20, 2016, 6:03 AM Tim Mitchell
wrote:
> Hi All,
>
> We have a modified version of singledispatch at work which works for
> methods as well as functions. We have open-sourced it as methoddispatch
> (p
Hey guys,
This is something that has been discussed before several times, whether in
Python mailing list and whether in stackoverflow, each providing different
answers.
I believe that we should add a naming convention in pep8 to solve this
issue.
Enums in Python are a unique creature - it's a cl
33 matches
Mail list logo
