[Python-ideas] Re: Error handling toggle / levels

2019-09-26 Thread Ilya Kulakov
Wow, I have never realized that except’s expression is a full featured expression! Best Regards Ilya Kulakov > On Sep 26, 2019, at 7:00 AM, Serhiy Storchaka wrote: > > 26.09.19 12:07, salemalbr...@gmail.com пише: >> So when coding, at deferent stages we need different

[Python-ideas] Re: Add a time-based synchronization primitive

2019-09-25 Thread Ilya Kulakov
Complement to the proposed idea. Some time ago I thought how cool it would be if one could implement a custom scheduler for Python's asyncio that used runtime metrics (defined by the user) to dynamically adjust priorities (with respect to the defined execution order). E.g. if the developer prior

Re: [Python-ideas] Deprecation utilities for the warnings module

2018-09-17 Thread Ilya Kulakov
(vs warn inside __init__/__new__) - Much easier to be seen by static analyzers Best Regards, Ilya Kulakov ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Deprecation utilities for the warnings module

2018-09-15 Thread Ilya Kulakov
>> Therefore it's not redundant to subclass *Warning for namespacing alone. > > Not redundant? You mean you must subclass? In that case my concern stands. An unfortunate typo, meant "it's redundant". > And what does that match against? The module name of the exception type right? It matches

Re: [Python-ideas] Deprecation utilities for the warnings module

2018-09-14 Thread Ilya Kulakov
Hi Anders, If correctly understood your concern, it's about usage of stdlib's *Warning classes directly that makes all warnings coming from different libraries indistinguishable. I think that's not the case, since warnings.filterwarnings allows to specify custom filter using a regular expression

[Python-ideas] Deprecation utilities for the warnings module

2018-09-13 Thread Ilya Kulakov
(Apologies if it's a duplicate. I originally posted to python-id...@googlegroups.com) I've been recently working on an internal library written entirely in Python. The library while being under development was as actively used by other teams. The product was under pressure and hasty design decisi

Re: [Python-ideas] Extend the warnings module with Deprecation utility methods and classes

2018-08-31 Thread Ilya Kulakov
Very nice, thank you. It would be a good start to collect usage patterns like this as seen in the wild for design consideration and test cases. > On Aug 30, 2018, at 10:43 PM, Joshua Harlow wrote: > > And mirrored at https://github.com/openstack/debtcollector >

[Python-ideas] Extend the warnings module with Deprecation utility methods and classes

2018-08-30 Thread Ilya Kulakov
Sooner or later authors and maintainers of libraries change public interfaces of their creations. Usually one of the two approaches is taken: 1. Outright breaking change 2. Soft deprecation later followed by [1] While [1] is perfectly suitable for libraries with limited audience, [2] is what p

Re: [Python-ideas] Stub class for Generic to further improve PEP 560

2017-11-30 Thread Ilya Kulakov
> Anyway, my expectation is that going along this way (i.e. removing all > runtime API apart from a necessary minimum) > will give a minor speed-up as compared to PEP 560 at the cost of a breaking > change (even for small number of developers). I don't think the change will be breaking: usage of

Re: [Python-ideas] Stub class for Generic to further improve PEP 560

2017-11-30 Thread Ilya Kulakov
A very rough implementation: typing.py: class _GenericMetaNoop(type): def __getitem__(self, params): return self class _GenericNoop(metaclass=_GenericMetaNoop) pass GenericStub = Generic if TYPE_CHECKING else _GenericNoop elsewhere.py: import typing

Re: [Python-ideas] Stub class for Generic to further improve PEP 560

2017-11-30 Thread Ilya Kulakov
My point is to have a class with public interface identical to typing.Generic, but without all runtime overhead. It's based on the assumption that few developers benefit with typing.Generic addition during production application execution. Those who do, can subclass typing.Generic directly. > O

[Python-ideas] Stub class for Generic to further improve PEP 560

2017-11-30 Thread Ilya Kulakov
will alias typing.Generic whenever typing.TYPE_CHECKING == True and a no-op stub otherwise. Best Regards, Ilya Kulakov ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://pyth

[Python-ideas] Complete typing.Union with the rest of set-like functions

2017-11-13 Thread Ilya Kulakov
I needed to declare a type that would mean "Any but None" and didn't find how. Current implementation allows to expand set of allowed types, not narrow it. Perhaps typing needs the rest of set operators in addition to Union? Best Regard

Re: [Python-ideas] Thread.__init__ should call super()

2017-10-30 Thread Ilya Kulakov
good reason for "old" classes to lag behind? I don't know. Perhaps some mechanism (invisible to a user) can be designed to avoid that. E.g. super() may leave a flag which should signal interpreter to "skip" all direct calls of a function and warn about it (Deprecati

[Python-ideas] Thread.__init__ should call super()

2017-10-27 Thread Ilya Kulakov
Since one of the legit use-cases of using the Thread class is subclassing, I think it's __init__ should call super() to support cooperative inheritance. Or perhaps there is a good reason for not doing so? Best Regards, Ilya Kulakov ___ Python-