[Python-Dev] Dinamically set __call__ method
Hi folks,
I am trying to replace dinamically the __call__ method of an object using
setattr.
Example:
$ cat testcall.py
class A:
def __init__(self):
setattr(self, '__call__', self.newcall)
def __call__(self):
print("OLD")
def newcall(self):
print("NEW")
a=A()
a()
I expect to get "NEW" instead of "OLD", but in Python 3.4 I get "OLD".
$ python2.7 testcall.py
NEW
$ python3.4 testcall.py
OLD
I have a few questions:
- Is this an expected behavior?
- Is possible to replace __call__ dinamically in Python 3? How?
Best regards,
Roberto
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New security-annou...@python.org mailing list
I can't see the lists either. Same message "No such list security-announce". Cheers. On Wed, Sep 27, 2017, 18:05 Jesus Cea wrote: > On 21/09/17 17:30, Barry Warsaw wrote: > > https://mail.python.org/mailman/listinfo/security-announce > > "No such list security-announce". > > > https://mail.python.org/mailman/listinfo/security-sig > > "No such list security-sig". > > -- > Jesús Cea Avión _/_/ _/_/_/_/_/_/ > j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ > Twitter: @jcea_/_/_/_/ _/_/_/_/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/robertomartinezp%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ThreadedProcessPoolExecutor
Hi, I've made a custom concurrent.futures.Executor mixing the ProcessPoolExecutor and ThreadPoolExecutor. I've published it here: https://github.com/nilp0inter/threadedprocess This executor is very similar to a ProcessPoolExecutor, but each process in the pool have it's own ThreadPoolExecutor inside. The motivation for this executor is mitigate the problem we have in a project were we have a very large number of long running IO bounded tasks, that have to run concurrently. Those long running tasks have sparse CPU bounded operations. To resolve this problem I considered multiple solutions: 1. Use asyncio to run the IO part as tasks and use a ProcessPoolExecutor to run the CPU bounded operations with "run_in_executor". Unfortunately the CPU operations depends on a large memory context, and using a ProcessPoolExecutor this way force the parent process to picklelize all the context to send it to the task, and because the context is so large, this operation is itself very CPU demanding. So it doesn't work. 2. Executing the IO/CPU bounded operations in different processes with multiprocessing.Process. This actually works, but the number of idle processes in the system is too large, resulting in a bad memory footprint. 3. Executing the IO/CPU bounded operations in threads. This doesn't work because the sum of all CPU operations saturate the core where the Python process is running and the other cores are wasted doing nothing. So I coded the ThreadedProcessPoolExecutor that helped me maintaining the number of processes under control (I just have one process per CPU core) allowing me to have a very high concurrency (hundreds of threads per process). I have a couple of questions: The first one is about the license. Given that I copied the majority of the code from the concurrent.futures library, I understand that I have to publish the code under the PSF LICENSE. Is this correct? My second question is about the package namespace. Given that this is an concurrent.futures.Executor subclass I understand that more intuitive place to locate it is under concurrent.futures. Is this a suitable use case for namespace packages? Is this a good idea? Best regards, Roberto ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ThreadedProcessPoolExecutor
El mié., 21 mar. 2018 a las 16:23, Guido van Rossum () escribió: > Roberto, > > That looks like an interesting class. I presume you're intending to > publish this as a pip package on PyPI.python.org? > > Precisely. I'm no lawyer, but I believe you can license your code under a new license > (I recommend BSD) as long as you keep a copy and a mention of the PSF > license in your distribution as well. (Though perhaps you could structure > your code differently and inherit from the standard library modules rather > than copying them?) > I am using inheritance as much as I can. But due to some functions being at the module level, instead of being Executor methods (for the sake of being pickelizable, I suppose); I am being forced to copy some of them just to modify a couple of lines. > In terms of the package namespace, do not put it in the same namespace as > standard library code! It probably won't work and will cause world-wide > pain and suffering for the users of your code. Invent your project name and > use that as a top-level namespace, like everyone else. :-) > > Ok, I don't want to cause world-wide pain (yet). Thank you! Best regards, Roberto > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Which version is better? Phyton 27 or Phyton 35?
Hi, I am having a hard time trying to choose one of this two products: Phyton 27: http://www.amazon.com/Phyton-27-Systemic-Bactericide-Fungicide/dp/B00VKPL8FU Phyton 35: http://www.amazon.com/Phyton-Bactericide-fungicide-Substitute-Liter/dp/B00BGE65VM Phyton 35 is announced as the "Substitute for Phyton 27" but I feel that Phyton 27 is more tested and have a bigger user base. Can you help to choose? Best regards, Roberto ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AutoNumber Enum
Why the 'start' parameter default is 1? 0 (zero) is more consistent with
other parts of the language: indexes, enumerate, range...
El mié., 29 de jun. de 2016 21:26, Ethan Furman
escribió:
> On 06/29/2016 12:11 PM, Guido van Rossum wrote:
>
> > And how would you implement that without support from the compiler?
> > Does it use a hook that catches the NameError?
>
> It's built into the _EnumDict class dictionary used during class creation.
>
> Current (edited) code from the aenum package that implements this:
>
> class _EnumDict(dict):
> """Track enum member order and ensure member names are not reused.
>
> EnumMeta will use the names found in self._member_names as the
> enumeration member names.
> """
> def __init__(self, locked=True, start=1, multivalue=False):
> super(_EnumDict, self).__init__()
> # list of enum members
> self._member_names = []
> # starting value for AutoNumber
> self._value = start - 1
> # when the magic turns off
> self._locked = locked
> ...
>
> def __getitem__(self, key):
> if (
> self._locked
> or key in self
> or _is_sunder(key)
> or _is_dunder(key)
> ):
> return super(_EnumDict, self).__getitem__(key)
> try:
> # try to generate the next value
> value = self._value + 1
> self.__setitem__(key, value)
> return value
> except:
> # couldn't work the magic, report error
> raise KeyError('%s not found' % key)
>
> def __setitem__(self, key, value):
> """Changes anything not sundured, dundered, nor a descriptor.
> Single underscore (sunder) names are reserved.
> """
> if _is_sunder(key):
> raise ValueError('_names_ are reserved for future Enum use')
> elif _is_dunder(key):
> if key == '__order__':
> key = '_order_'
> if _is_descriptor(value):
> self._locked = True
> elif key in self._member_names:
> # descriptor overwriting an enum?
> raise TypeError('Attempted to reuse name: %r' % key)
> elif not _is_descriptor(value):
> if key in self:
> # enum overwriting a descriptor?
> raise TypeError('%s already defined as: %r' % ...
> self._member_names.append(key)
> if not self._locked:
> if isinstance(value, int):
> self._value = value
> else:
> count = self._value + 1
> self._value = count
> value = count, value
> else:
> # not a new member, turn off the autoassign magic
> self._locked = True
> super(_EnumDict, self).__setitem__(key, value)
>
> Disclaimer: some errors may have crept in as I deleted unrelated
> content. For the full code check out the _EnumDict class in the aenum
> package.
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/robertomartinezp%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] collections.abc for data and non-data descriptors
Hi, I miss abstract base classes in collections.abc implementing the descriptor protocol. Any reason why they do not exist? What do you think of adding NonDataDescriptor and DataDescriptor ABCs? Best regards, Roberto ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.abc for data and non-data descriptors
I need to check if some objects obey the descriptor protocol in the
construction of a metaclass. I expect to be able to write something like:
if isinstance(myobj, abc.DataDescriptor):
# do something
The other idea crossing my mind is something like:
if all(hasattr(myobj, attr) for attr in ('__get__', '__set__')):
# do something
El mar., 17 ene. 2017 a las 18:07, Guido van Rossum ()
escribió:
> Well, these are an example of the purest duck typing. Just implement
> __get__ and/or __set__ (and __delete__) and you're good.
>
> What's the situation where you miss them?
>
> --Guido
>
> On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
> robertomartin...@gmail.com> wrote:
>
> Hi,
>
> I miss abstract base classes in collections.abc implementing the
> descriptor protocol. Any reason why they do not exist?
>
> What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
>
> Best regards,
> Roberto
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.abc for data and non-data descriptors
Well, for me having to check both __get__ and __str__ for a data descriptor
feels inelegant.
After read the documentation of collections.abc again "This module provides
abstract base classes that can be used to test whether a class provides a
particular interface; for example, whether it is hashable or whether it is
a mapping." I ask: what is the criteria to decide which interfaces are
worth implemented as an ABC in the standard library?
To my understanding, any well defined python protocol should have a proper
ABC.
El mar., 17 ene. 2017 a las 18:55, Guido van Rossum ()
escribió:
> For this use case I see nothing wrong with hasattr(myobj, '__set__').
>
> On Tue, Jan 17, 2017 at 9:41 AM, Roberto Martínez <
> robertomartin...@gmail.com> wrote:
>
> I need to check if some objects obey the descriptor protocol in the
> construction of a metaclass. I expect to be able to write something like:
>
> if isinstance(myobj, abc.DataDescriptor):
># do something
>
> The other idea crossing my mind is something like:
>
> if all(hasattr(myobj, attr) for attr in ('__get__', '__set__')):
> # do something
>
>
> El mar., 17 ene. 2017 a las 18:07, Guido van Rossum ()
> escribió:
>
> Well, these are an example of the purest duck typing. Just implement
> __get__ and/or __set__ (and __delete__) and you're good.
>
> What's the situation where you miss them?
>
> --Guido
>
> On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
> robertomartin...@gmail.com> wrote:
>
> Hi,
>
> I miss abstract base classes in collections.abc implementing the
> descriptor protocol. Any reason why they do not exist?
>
> What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
>
> Best regards,
> Roberto
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.abc for data and non-data descriptors
Oh, I understand. Maybe is not worth the effort anyway.
Thank you
El mar., 17 ene. 2017 a las 19:40, Guido van Rossum ()
escribió:
But you can never get people to use the new ABCs consistently.
Anyway, I'm not -1, I'm just -0 -- I don't think it'll make any difference
and you're better off just checking for __set__ (if it only has __set__ but
not __get__, do you care what it is?).
On Tue, Jan 17, 2017 at 10:18 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
Well, for me having to check both __get__ and __str__ for a data descriptor
feels inelegant.
After read the documentation of collections.abc again "This module provides
abstract base classes that can be used to test whether a class provides a
particular interface; for example, whether it is hashable or whether it is
a mapping." I ask: what is the criteria to decide which interfaces are
worth implemented as an ABC in the standard library?
To my understanding, any well defined python protocol should have a proper
ABC.
El mar., 17 ene. 2017 a las 18:55, Guido van Rossum ()
escribió:
For this use case I see nothing wrong with hasattr(myobj, '__set__').
On Tue, Jan 17, 2017 at 9:41 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
I need to check if some objects obey the descriptor protocol in the
construction of a metaclass. I expect to be able to write something like:
if isinstance(myobj, abc.DataDescriptor):
# do something
The other idea crossing my mind is something like:
if all(hasattr(myobj, attr) for attr in ('__get__', '__set__')):
# do something
El mar., 17 ene. 2017 a las 18:07, Guido van Rossum ()
escribió:
Well, these are an example of the purest duck typing. Just implement
__get__ and/or __set__ (and __delete__) and you're good.
What's the situation where you miss them?
--Guido
On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
Hi,
I miss abstract base classes in collections.abc implementing the descriptor
protocol. Any reason why they do not exist?
What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
Best regards,
Roberto
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
--
--Guido van Rossum (python.org/~guido)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
