Re: [Python-Dev] PEP 557: Data Classes

[Eric V. Smith]

On 9/9/2017 11:41 AM, Gustavo Carneiro wrote:

Hi, it is not clear whether anything is done to total_cost:

     def total_cost(self) -> float:

Does this become a property automatically, or is it still a method 
call?  To that end, some examples of *using* a data class, not just 
defining one, would be helpful.


If it remains a normal method, why put it in this example at all? Makes 


Nothing is done with total_cost, it's still a method. It's meant to show 
that you can use methods in a Data Class.  Maybe I should add a method 
that has a parameter, or at least explain why that method is present in 
the example.


I'm not sure how I'd write an example showing you can you do everything 
you can with an undecorated class. I think some text explanation would 
be better.


Eric.

___
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] PEP 559 - built-in noop()

[Guido van Rossum]

I can't tell whether this was meant seriously, but I don't think it's worth
it. People can easily write their own dummy function and give it any damn
semantics they want. Let's reject the PEP.

On Sat, Sep 9, 2017 at 11:46 AM, Barry Warsaw  wrote:

> I couldn’t resist one more PEP from the Core sprint.  I won’t reveal where
> or how this one came to me.
>
> -Barry
>
> PEP: 559
> Title: Built-in noop()
> Author: Barry Warsaw 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 2017-09-08
> Python-Version: 3.7
> Post-History: 2017-09-09
>
>
> Abstract
> 
>
> This PEP proposes adding a new built-in function called ``noop()`` which
> does
> nothing but return ``None``.
>
>
> Rationale
> =
>
> It is trivial to implement a no-op function in Python.  It's so easy in
> fact
> that many people do it many times over and over again.  It would be useful
> in
> many cases to have a common built-in function that does nothing.
>
> One use case would be for PEP 553, where you could set the breakpoint
> environment variable to the following in order to effectively disable it::
>
> $ setenv PYTHONBREAKPOINT=noop
>
>
> Implementation
> ==
>
> The Python equivalent of the ``noop()`` function is exactly::
>
> def noop(*args, **kws):
> return None
>
> The C built-in implementation is available as a pull request.
>
>
> Rejected alternatives
> =
>
> ``noop()`` returns something
> 
>
> YAGNI.
>
> This is rejected because it complicates the semantics.  For example, if you
> always return both ``*args`` and ``**kws``, what do you return when none of
> those are given?  Returning a tuple of ``((), {})`` is kind of ugly, but
> provides consistency.  But you might also want to just return ``None``
> since
> that's also conceptually what the function was passed.
>
> Or, what if you pass in exactly one positional argument, e.g.
> ``noop(7)``.  Do
> you return ``7`` or ``((7,), {})``?  And so on.
>
> The author claims that you won't ever need the return value of ``noop()``
> so
> it will always return ``None``.
>
> Coghlin's Dialogs (edited for formatting):
>
> My counterargument to this would be ``map(noop, iterable)``,
> ``sorted(iterable, key=noop)``, etc. (``filter``, ``max``, and
> ``min`` all accept callables that accept a single argument, as do
> many of the itertools operations).
>
> Making ``noop()`` a useful default function in those cases just
> needs the definition to be::
>
>def noop(*args, **kwds):
>return args[0] if args else None
>
> The counterargument to the counterargument is that using ``None``
> as the default in all these cases is going to be faster, since it
> lets the algorithm skip the callback entirely, rather than calling
> it and having it do nothing useful.
>
>
> Copyright
> =
>
> This document has been placed in the public domain.
>
>
> ..
>Local Variables:
>mode: indented-text
>indent-tabs-mode: nil
>sentence-end-double-space: t
>fill-column: 70
>coding: utf-8
>End:
>
>
> ___
> 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] PEP 559 - built-in noop()

[Victor Stinner]

Previous discussion: https://bugs.python.org/issue10049

Issue closed as rejected.

Victor

2017-09-09 14:33 GMT-07:00 Victor Stinner :
> I was able to find a real keyboard, so here is a more complete code:
> ---
> class Noop:
> def __call__(self, *args, **kw):
> return self
> def __enter__(self, *args, **kw):
> return self
> def __exit__(self, *args):
> return
> def __repr__(self):
> return 'nope'
> ---
>
> Example:
> ---
> noop = Noop()
> print(noop)
> print(noop())
> with noop() as nope:
> print(nope)
> with noop as well:
> print(well)
> ---
>
> Output:
> ---
> nope
> nope
> nope
> nope
> ---
>
> IHMO the real question is if we need a Noop.nope() method?
>
> Victor
>
> 2017-09-09 12:54 GMT-07:00 Victor Stinner :
>> I always wanted this feature (no kidding).
>>
>> Would it be possible to add support for the context manager?
>>
>> with noop(): ...
>>
>> Maybe noop can be an instance of:
>>
>> class Noop:
>>   def __enter__(self, *args, **kw): return self
>>   def __exit__(self, *args): pass
>>   def __call__(self, *args, **kw): return self
>>
>> Victor
>>
>> Le 9 sept. 2017 11:48 AM, "Barry Warsaw"  a écrit :
>>>
>>> I couldn’t resist one more PEP from the Core sprint.  I won’t reveal where
>>> or how this one came to me.
>>>
>>> -Barry
>>>
>>> PEP: 559
>>> Title: Built-in noop()
>>> Author: Barry Warsaw 
>>> Status: Draft
>>> Type: Standards Track
>>> Content-Type: text/x-rst
>>> Created: 2017-09-08
>>> Python-Version: 3.7
>>> Post-History: 2017-09-09
>>>
>>>
>>> Abstract
>>> 
>>>
>>> This PEP proposes adding a new built-in function called ``noop()`` which
>>> does
>>> nothing but return ``None``.
>>>
>>>
>>> Rationale
>>> =
>>>
>>> It is trivial to implement a no-op function in Python.  It's so easy in
>>> fact
>>> that many people do it many times over and over again.  It would be useful
>>> in
>>> many cases to have a common built-in function that does nothing.
>>>
>>> One use case would be for PEP 553, where you could set the breakpoint
>>> environment variable to the following in order to effectively disable it::
>>>
>>> $ setenv PYTHONBREAKPOINT=noop
>>>
>>>
>>> Implementation
>>> ==
>>>
>>> The Python equivalent of the ``noop()`` function is exactly::
>>>
>>> def noop(*args, **kws):
>>> return None
>>>
>>> The C built-in implementation is available as a pull request.
>>>
>>>
>>> Rejected alternatives
>>> =
>>>
>>> ``noop()`` returns something
>>> 
>>>
>>> YAGNI.
>>>
>>> This is rejected because it complicates the semantics.  For example, if
>>> you
>>> always return both ``*args`` and ``**kws``, what do you return when none
>>> of
>>> those are given?  Returning a tuple of ``((), {})`` is kind of ugly, but
>>> provides consistency.  But you might also want to just return ``None``
>>> since
>>> that's also conceptually what the function was passed.
>>>
>>> Or, what if you pass in exactly one positional argument, e.g. ``noop(7)``.
>>> Do
>>> you return ``7`` or ``((7,), {})``?  And so on.
>>>
>>> The author claims that you won't ever need the return value of ``noop()``
>>> so
>>> it will always return ``None``.
>>>
>>> Coghlin's Dialogs (edited for formatting):
>>>
>>> My counterargument to this would be ``map(noop, iterable)``,
>>> ``sorted(iterable, key=noop)``, etc. (``filter``, ``max``, and
>>> ``min`` all accept callables that accept a single argument, as do
>>> many of the itertools operations).
>>>
>>> Making ``noop()`` a useful default function in those cases just
>>> needs the definition to be::
>>>
>>>def noop(*args, **kwds):
>>>return args[0] if args else None
>>>
>>> The counterargument to the counterargument is that using ``None``
>>> as the default in all these cases is going to be faster, since it
>>> lets the algorithm skip the callback entirely, rather than calling
>>> it and having it do nothing useful.
>>>
>>>
>>> Copyright
>>> =
>>>
>>> This document has been placed in the public domain.
>>>
>>>
>>> ..
>>>Local Variables:
>>>mode: indented-text
>>>indent-tabs-mode: nil
>>>sentence-end-double-space: t
>>>fill-column: 70
>>>coding: utf-8
>>>End:
>>>
>>>
>>> ___
>>> 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/victor.stinner%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

Re: [Python-Dev] PEP 559 - built-in noop()

[Koos Zevenhoven]

On Sat, Sep 9, 2017 at 10:54 PM, Victor Stinner 
wrote:

> I always wanted this feature (no kidding).
>
> Would it be possible to add support for the context manager?
>
> with noop(): ...
>
> Maybe noop can be an instance of:
>
> class Noop:
>   def __enter__(self, *args, **kw): return self
>   def __exit__(self, *args): pass
>   def __call__(self, *args, **kw): return self
>
>

​This worries me. Clearly, assuming a None-coercing noop, we must have:

noop(foo) is None
noop[foo] is None
noop * ​foo is None
foo * noop is None
noop + foo is None
foo + noop is None
noop - noop is None
...
noop / 0 is None
...
(noop == None) is None

which can all sort of be implicitly extrapolated to be in the PEP.

But how are you planning to implement:

(noop is None) is None
(obj in noop) is None
(noop in obj) is None

or

(None or noop) is None
(None and noop) is None

and finally:

foo(noop) is None

?

Sooner or later, someone will need all these features, and the PEP does not
seem to address the issue in any way.

-- Koos




> Victor
>
> Le 9 sept. 2017 11:48 AM, "Barry Warsaw"  a écrit :
>
>> I couldn’t resist one more PEP from the Core sprint.  I won’t reveal
>> where or how this one came to me.
>>
>> -Barry
>>
>> PEP: 559
>> Title: Built-in noop()
>> Author: Barry Warsaw 
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 2017-09-08
>> Python-Version: 3.7
>> Post-History: 2017-09-09
>>
>>
>> Abstract
>> 
>>
>> This PEP proposes adding a new built-in function called ``noop()`` which
>> does
>> nothing but return ``None``.
>>
>>
>> Rationale
>> =
>>
>> It is trivial to implement a no-op function in Python.  It's so easy in
>> fact
>> that many people do it many times over and over again.  It would be
>> useful in
>> many cases to have a common built-in function that does nothing.
>>
>> One use case would be for PEP 553, where you could set the breakpoint
>> environment variable to the following in order to effectively disable it::
>>
>> $ setenv PYTHONBREAKPOINT=noop
>>
>>
>> Implementation
>> ==
>>
>> The Python equivalent of the ``noop()`` function is exactly::
>>
>> def noop(*args, **kws):
>> return None
>>
>> The C built-in implementation is available as a pull request.
>>
>>
>> Rejected alternatives
>> =
>>
>> ``noop()`` returns something
>> 
>>
>> YAGNI.
>>
>> This is rejected because it complicates the semantics.  For example, if
>> you
>> always return both ``*args`` and ``**kws``, what do you return when none
>> of
>> those are given?  Returning a tuple of ``((), {})`` is kind of ugly, but
>> provides consistency.  But you might also want to just return ``None``
>> since
>> that's also conceptually what the function was passed.
>>
>> Or, what if you pass in exactly one positional argument, e.g.
>> ``noop(7)``.  Do
>> you return ``7`` or ``((7,), {})``?  And so on.
>>
>> The author claims that you won't ever need the return value of ``noop()``
>> so
>> it will always return ``None``.
>>
>> Coghlin's Dialogs (edited for formatting):
>>
>> My counterargument to this would be ``map(noop, iterable)``,
>> ``sorted(iterable, key=noop)``, etc. (``filter``, ``max``, and
>> ``min`` all accept callables that accept a single argument, as do
>> many of the itertools operations).
>>
>> Making ``noop()`` a useful default function in those cases just
>> needs the definition to be::
>>
>>def noop(*args, **kwds):
>>return args[0] if args else None
>>
>> The counterargument to the counterargument is that using ``None``
>> as the default in all these cases is going to be faster, since it
>> lets the algorithm skip the callback entirely, rather than calling
>> it and having it do nothing useful.
>>
>>
>> Copyright
>> =
>>
>> This document has been placed in the public domain.
>>
>>
>> ..
>>Local Variables:
>>mode: indented-text
>>indent-tabs-mode: nil
>>sentence-end-double-space: t
>>fill-column: 70
>>coding: utf-8
>>End:
>>
>>
>> ___
>> 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/victor.
>> stinner%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/
> k7hoven%40gmail.com
>
>


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
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] PEP 559 - built-in noop()

[Oleg Broytman]

On Sat, Sep 09, 2017 at 02:33:18PM -0700, Victor Stinner 
 wrote:
> I was able to find a real keyboard, so here is a more complete code:
> ---
> class Noop:
> def __call__(self, *args, **kw):
> return self
> def __enter__(self, *args, **kw):
> return self
> def __exit__(self, *args):
> return
> def __repr__(self):
> return 'nope'
> ---
> 
> Example:
> ---
> noop = Noop()
> print(noop)
> print(noop())
> with noop() as nope:
> print(nope)
> with noop as well:
> print(well)
> ---
> 
> Output:
> ---
> nope
> nope
> nope
> nope
> ---
> 
> IHMO the real question is if we need a Noop.nope() method?

   Yep. It must return self so one can chain as many calls as she wants.

> Victor

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] PEP 559 - built-in noop()

[Victor Stinner]

I was able to find a real keyboard, so here is a more complete code:
---
class Noop:
def __call__(self, *args, **kw):
return self
def __enter__(self, *args, **kw):
return self
def __exit__(self, *args):
return
def __repr__(self):
return 'nope'
---

Example:
---
noop = Noop()
print(noop)
print(noop())
with noop() as nope:
print(nope)
with noop as well:
print(well)
---

Output:
---
nope
nope
nope
nope
---

IHMO the real question is if we need a Noop.nope() method?

Victor

2017-09-09 12:54 GMT-07:00 Victor Stinner :
> I always wanted this feature (no kidding).
>
> Would it be possible to add support for the context manager?
>
> with noop(): ...
>
> Maybe noop can be an instance of:
>
> class Noop:
>   def __enter__(self, *args, **kw): return self
>   def __exit__(self, *args): pass
>   def __call__(self, *args, **kw): return self
>
> Victor
>
> Le 9 sept. 2017 11:48 AM, "Barry Warsaw"  a écrit :
>>
>> I couldn’t resist one more PEP from the Core sprint.  I won’t reveal where
>> or how this one came to me.
>>
>> -Barry
>>
>> PEP: 559
>> Title: Built-in noop()
>> Author: Barry Warsaw 
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 2017-09-08
>> Python-Version: 3.7
>> Post-History: 2017-09-09
>>
>>
>> Abstract
>> 
>>
>> This PEP proposes adding a new built-in function called ``noop()`` which
>> does
>> nothing but return ``None``.
>>
>>
>> Rationale
>> =
>>
>> It is trivial to implement a no-op function in Python.  It's so easy in
>> fact
>> that many people do it many times over and over again.  It would be useful
>> in
>> many cases to have a common built-in function that does nothing.
>>
>> One use case would be for PEP 553, where you could set the breakpoint
>> environment variable to the following in order to effectively disable it::
>>
>> $ setenv PYTHONBREAKPOINT=noop
>>
>>
>> Implementation
>> ==
>>
>> The Python equivalent of the ``noop()`` function is exactly::
>>
>> def noop(*args, **kws):
>> return None
>>
>> The C built-in implementation is available as a pull request.
>>
>>
>> Rejected alternatives
>> =
>>
>> ``noop()`` returns something
>> 
>>
>> YAGNI.
>>
>> This is rejected because it complicates the semantics.  For example, if
>> you
>> always return both ``*args`` and ``**kws``, what do you return when none
>> of
>> those are given?  Returning a tuple of ``((), {})`` is kind of ugly, but
>> provides consistency.  But you might also want to just return ``None``
>> since
>> that's also conceptually what the function was passed.
>>
>> Or, what if you pass in exactly one positional argument, e.g. ``noop(7)``.
>> Do
>> you return ``7`` or ``((7,), {})``?  And so on.
>>
>> The author claims that you won't ever need the return value of ``noop()``
>> so
>> it will always return ``None``.
>>
>> Coghlin's Dialogs (edited for formatting):
>>
>> My counterargument to this would be ``map(noop, iterable)``,
>> ``sorted(iterable, key=noop)``, etc. (``filter``, ``max``, and
>> ``min`` all accept callables that accept a single argument, as do
>> many of the itertools operations).
>>
>> Making ``noop()`` a useful default function in those cases just
>> needs the definition to be::
>>
>>def noop(*args, **kwds):
>>return args[0] if args else None
>>
>> The counterargument to the counterargument is that using ``None``
>> as the default in all these cases is going to be faster, since it
>> lets the algorithm skip the callback entirely, rather than calling
>> it and having it do nothing useful.
>>
>>
>> Copyright
>> =
>>
>> This document has been placed in the public domain.
>>
>>
>> ..
>>Local Variables:
>>mode: indented-text
>>indent-tabs-mode: nil
>>sentence-end-double-space: t
>>fill-column: 70
>>coding: utf-8
>>End:
>>
>>
>> ___
>> 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/victor.stinner%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

Re: [Python-Dev] PEP 559 - built-in noop()

[Antoine Pitrou]

On Sat, 9 Sep 2017 11:46:30 -0700
Barry Warsaw  wrote:
> 
> Rationale
> =
> 
> It is trivial to implement a no-op function in Python.  It's so easy in fact
> that many people do it many times over and over again.  It would be useful in
> many cases to have a common built-in function that does nothing.

You forgot to mention the advantage of battle-testing the noop()
function on our buildbot fleet!  You don't want to compromise your
application code with a weak noop() function.

> The C built-in implementation is available as a pull request.

Does it guarantee reentrancy?

Regards

Antoine.


___
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] PEP 559 - built-in noop()

[Serhiy Storchaka]

09.09.17 21:46, Barry Warsaw пише:

One use case would be for PEP 553, where you could set the breakpoint
environment variable to the following in order to effectively disable it::

 $ setenv PYTHONBREAKPOINT=noop


Are there other use cases? PEP 553 still is not approved, and you could 
use other syntax for disabling breakpoint(), e.g. setting 
PYTHONBREAKPOINT to an empty value.


It looks to me that in all other cases it can be replaced with `lambda 
*args, **kwds: None` (actually the expression can be even simpler in 
concrete cases). I can't remember any case when I needed an noop() 
function (unlike to an identity() function or null context manager).


___
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] PEP 559 - built-in noop()

[Victor Stinner]

I always wanted this feature (no kidding).

Would it be possible to add support for the context manager?

with noop(): ...

Maybe noop can be an instance of:

class Noop:
  def __enter__(self, *args, **kw): return self
  def __exit__(self, *args): pass
  def __call__(self, *args, **kw): return self

Victor

Le 9 sept. 2017 11:48 AM, "Barry Warsaw"  a écrit :

> I couldn’t resist one more PEP from the Core sprint.  I won’t reveal where
> or how this one came to me.
>
> -Barry
>
> PEP: 559
> Title: Built-in noop()
> Author: Barry Warsaw 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 2017-09-08
> Python-Version: 3.7
> Post-History: 2017-09-09
>
>
> Abstract
> 
>
> This PEP proposes adding a new built-in function called ``noop()`` which
> does
> nothing but return ``None``.
>
>
> Rationale
> =
>
> It is trivial to implement a no-op function in Python.  It's so easy in
> fact
> that many people do it many times over and over again.  It would be useful
> in
> many cases to have a common built-in function that does nothing.
>
> One use case would be for PEP 553, where you could set the breakpoint
> environment variable to the following in order to effectively disable it::
>
> $ setenv PYTHONBREAKPOINT=noop
>
>
> Implementation
> ==
>
> The Python equivalent of the ``noop()`` function is exactly::
>
> def noop(*args, **kws):
> return None
>
> The C built-in implementation is available as a pull request.
>
>
> Rejected alternatives
> =
>
> ``noop()`` returns something
> 
>
> YAGNI.
>
> This is rejected because it complicates the semantics.  For example, if you
> always return both ``*args`` and ``**kws``, what do you return when none of
> those are given?  Returning a tuple of ``((), {})`` is kind of ugly, but
> provides consistency.  But you might also want to just return ``None``
> since
> that's also conceptually what the function was passed.
>
> Or, what if you pass in exactly one positional argument, e.g.
> ``noop(7)``.  Do
> you return ``7`` or ``((7,), {})``?  And so on.
>
> The author claims that you won't ever need the return value of ``noop()``
> so
> it will always return ``None``.
>
> Coghlin's Dialogs (edited for formatting):
>
> My counterargument to this would be ``map(noop, iterable)``,
> ``sorted(iterable, key=noop)``, etc. (``filter``, ``max``, and
> ``min`` all accept callables that accept a single argument, as do
> many of the itertools operations).
>
> Making ``noop()`` a useful default function in those cases just
> needs the definition to be::
>
>def noop(*args, **kwds):
>return args[0] if args else None
>
> The counterargument to the counterargument is that using ``None``
> as the default in all these cases is going to be faster, since it
> lets the algorithm skip the callback entirely, rather than calling
> it and having it do nothing useful.
>
>
> Copyright
> =
>
> This document has been placed in the public domain.
>
>
> ..
>Local Variables:
>mode: indented-text
>indent-tabs-mode: nil
>sentence-end-double-space: t
>fill-column: 70
>coding: utf-8
>End:
>
>
> ___
> 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/
> victor.stinner%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

Re: [Python-Dev] PEP 559 - built-in noop()

[Ben Hoyt]

I don't think the rationale justifies an entire builtin. You could just use
"PYTHONBREAKPOINT=int" to disable, or support "PYTHONBREAKPOINT=0" as I
think someone else suggested. I personally can't remember the last time I
needed a noop() function. I've more often needed an identity() function,
and even that has been proposed several times but shot down, mainly because
different people have different needs. (Often "None" provided for function
arguments means identity anyway, like for sorted() and filter().)

If anything, I think it should be functools.noop() and
PYTHONBREAKPOINT=functools.noop

I think we need more justification and examples of where this would be
helpful to justify a new builtin.

-Ben

On Sat, Sep 9, 2017 at 2:46 PM, Barry Warsaw  wrote:

> I couldn’t resist one more PEP from the Core sprint.  I won’t reveal where
> or how this one came to me.
>
> -Barry
>
> PEP: 559
> Title: Built-in noop()
> Author: Barry Warsaw 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 2017-09-08
> Python-Version: 3.7
> Post-History: 2017-09-09
>
>
> Abstract
> 
>
> This PEP proposes adding a new built-in function called ``noop()`` which
> does
> nothing but return ``None``.
>
>
> Rationale
> =
>
> It is trivial to implement a no-op function in Python.  It's so easy in
> fact
> that many people do it many times over and over again.  It would be useful
> in
> many cases to have a common built-in function that does nothing.
>
> One use case would be for PEP 553, where you could set the breakpoint
> environment variable to the following in order to effectively disable it::
>
> $ setenv PYTHONBREAKPOINT=noop
>
>
> Implementation
> ==
>
> The Python equivalent of the ``noop()`` function is exactly::
>
> def noop(*args, **kws):
> return None
>
> The C built-in implementation is available as a pull request.
>
>
> Rejected alternatives
> =
>
> ``noop()`` returns something
> 
>
> YAGNI.
>
> This is rejected because it complicates the semantics.  For example, if you
> always return both ``*args`` and ``**kws``, what do you return when none of
> those are given?  Returning a tuple of ``((), {})`` is kind of ugly, but
> provides consistency.  But you might also want to just return ``None``
> since
> that's also conceptually what the function was passed.
>
> Or, what if you pass in exactly one positional argument, e.g.
> ``noop(7)``.  Do
> you return ``7`` or ``((7,), {})``?  And so on.
>
> The author claims that you won't ever need the return value of ``noop()``
> so
> it will always return ``None``.
>
> Coghlin's Dialogs (edited for formatting):
>
> My counterargument to this would be ``map(noop, iterable)``,
> ``sorted(iterable, key=noop)``, etc. (``filter``, ``max``, and
> ``min`` all accept callables that accept a single argument, as do
> many of the itertools operations).
>
> Making ``noop()`` a useful default function in those cases just
> needs the definition to be::
>
>def noop(*args, **kwds):
>return args[0] if args else None
>
> The counterargument to the counterargument is that using ``None``
> as the default in all these cases is going to be faster, since it
> lets the algorithm skip the callback entirely, rather than calling
> it and having it do nothing useful.
>
>
> Copyright
> =
>
> This document has been placed in the public domain.
>
>
> ..
>Local Variables:
>mode: indented-text
>indent-tabs-mode: nil
>sentence-end-double-space: t
>fill-column: 70
>coding: utf-8
>End:
>
>
> ___
> 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/
> benhoyt%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

Re: [Python-Dev] PEP 559 - built-in noop()

[MRAB]

On 2017-09-09 19:46, Barry Warsaw wrote:

I couldn’t resist one more PEP from the Core sprint.  I won’t reveal where or 
how this one came to me.

-Barry

PEP: 559
Title: Built-in noop()
Author: Barry Warsaw 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2017-09-08
Python-Version: 3.7
Post-History: 2017-09-09


Abstract


This PEP proposes adding a new built-in function called ``noop()`` which does
nothing but return ``None``.


[snip]

I'd prefer the more tradition "nop". :-)
___
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] PEP 559 - built-in noop()

[Barry Warsaw]

I couldn’t resist one more PEP from the Core sprint.  I won’t reveal where or 
how this one came to me.

-Barry

PEP: 559
Title: Built-in noop()
Author: Barry Warsaw 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2017-09-08
Python-Version: 3.7
Post-History: 2017-09-09


Abstract


This PEP proposes adding a new built-in function called ``noop()`` which does
nothing but return ``None``.


Rationale
=

It is trivial to implement a no-op function in Python.  It's so easy in fact
that many people do it many times over and over again.  It would be useful in
many cases to have a common built-in function that does nothing.

One use case would be for PEP 553, where you could set the breakpoint
environment variable to the following in order to effectively disable it::

$ setenv PYTHONBREAKPOINT=noop


Implementation
==

The Python equivalent of the ``noop()`` function is exactly::

def noop(*args, **kws):
return None

The C built-in implementation is available as a pull request.


Rejected alternatives
=

``noop()`` returns something


YAGNI.

This is rejected because it complicates the semantics.  For example, if you
always return both ``*args`` and ``**kws``, what do you return when none of
those are given?  Returning a tuple of ``((), {})`` is kind of ugly, but
provides consistency.  But you might also want to just return ``None`` since
that's also conceptually what the function was passed.

Or, what if you pass in exactly one positional argument, e.g. ``noop(7)``.  Do
you return ``7`` or ``((7,), {})``?  And so on.

The author claims that you won't ever need the return value of ``noop()`` so
it will always return ``None``.

Coghlin's Dialogs (edited for formatting):

My counterargument to this would be ``map(noop, iterable)``,
``sorted(iterable, key=noop)``, etc. (``filter``, ``max``, and
``min`` all accept callables that accept a single argument, as do
many of the itertools operations).

Making ``noop()`` a useful default function in those cases just
needs the definition to be::

   def noop(*args, **kwds):
   return args[0] if args else None

The counterargument to the counterargument is that using ``None``
as the default in all these cases is going to be faster, since it
lets the algorithm skip the callback entirely, rather than calling
it and having it do nothing useful.


Copyright
=

This document has been placed in the public domain.


..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:



signature.asc
Description: Message signed with OpenPGP
___
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] PEP 554 v2 (new "interpreters" module)

[Nathaniel Smith]

On Sep 8, 2017 4:06 PM, "Eric Snow"  wrote:


   run(code):

  Run the provided Python code in the interpreter, in the current
  OS thread.  If the interpreter is already running then raise
  RuntimeError in the interpreter that called ``run()``.

  The current interpreter (which called ``run()``) will block until
  the subinterpreter finishes running the requested code.  Any
  uncaught exception in that code will bubble up to the current
  interpreter.


This phrase "bubble up" here is doing a lot of work :-). Can you elaborate
on what you mean? The text now makes it seem like the exception will just
pass from one interpreter into another, but that seems impossible – it'd
mean sharing not just arbitrary user defined exception classes but full
frame objects...

-n
___
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] PEP 554 v2 (new "interpreters" module)

[Nathaniel Smith]

On Sep 9, 2017 9:07 AM, "Nick Coghlan"  wrote:


To immediately realise some level of efficiency benefits from the
shared memory space between the main interpreter and subinterpreters,
I also think these low level FIFOs should be defined as accepting any
object that supports the PEP 3118 buffer protocol, and emitting
memoryview() objects on the receiving end, rather than being bytes-in,
bytes-out.


Is your idea that this memoryview would refer directly to the sending
interpreter's memory (as opposed to a copy into some receiver-owned
buffer)? If so, then how do the two subinterpreters coordinate the buffer
release when the memoryview is closed?

-n
___
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] PEP 554 v2 (new "interpreters" module)

[Nick Coghlan]

On 9 September 2017 at 01:04, Paul Moore  wrote:
> On 9 September 2017 at 00:04, Eric Snow  wrote:
>>add_recv_fifo(name=None):
>>
>>   Create a new FIFO, associate the two ends with the involved
>>   interpreters, and return the side associated with the interpreter
>>   in which "add_recv_fifo()" was called.  A FIFOReader gets tied to
>>   this interpreter.  A FIFOWriter gets tied to the interpreter that
>>   called "add_recv_fifo()".
>>
>>   The FIFO's name is set to the provided value.  If no name is
>>   provided then a dynamically generated one is used.  If a FIFO
>>   with the given name is already associated with this interpreter
>>   (or with the one in which "add_recv_fifo()" was called) then raise
>>   KeyError.
>>
>>add_send_fifo(name=None):
>>
>>   Create a new FIFO, associate the two ends with the involved
>>   interpreters, and return the side associated with the interpreter
>>   in which "add_recv_fifo()" was called.  A FIFOWriter gets tied to
>>   this interpreter.  A FIFOReader gets tied to the interpreter that
>>   called "add_recv_fifo()".
>>
>>   The FIFO's name is set to the provided value.  If no name is
>>   provided then a dynamically generated one is used.  If a FIFO
>>   with the given name is already associated with this interpreter
>>   (or with the one in which "add_send_fifo()" was called) then raise
>>   KeyError.
>
> Personally, I *always* read these names backwards - from the POV of
> the caller. So when I see "add_send_fifo", I then expect to be able to
> send stuff on the returned FIFO (i.e., I get a writer back). But
> that's not how it works.

I had the same problem with the current names: as a message sender, I
expect to request a send queue, as a message receiver, I expect to
request a receive queue.

Having to request the opposite of what I want to do next seems backwards:

send_fifo = other_interpreter.add_recv_fifo(__name__) # Wut?
send_fifo.push(b"Hello!")

I think it would be much clearer if the API looked like this for an
inline subinterpreter invocation.:

# Sending messages
other_interpreter = interpreters.create()
send_fifo = other_interpreter.get_send_fifo(__name__)
send_fifo.push(b"Hello!")
send_fifo.push(b"World!")
send_fifo.push(None)

# Receiving messages
receiver_code = textwrap.dedent(f"""
import interpreters
recv_fifo = interpreters.get_current().get_recv_fifo({__name__})
while True:
msg = recv_fifo.pop()
if msg is None:
break
print(msg)
""")
other_interpreter.run(receiver_code)

To enable concurrent communication between the sender & receiver,
you'd currently need to move the "other_interpreter.run()" call out to
a separate thread, but I think that's fine for now.

The rules for get_recv_fifo() and get_send_fifo() would be:

- named fifos are created as needed and always stored on the
*receiving* interpreter
- you can only call get_recv_fifo() on the currently running
interpreter: other interpreters can't access your receive fifos
- get_recv_fifo() never fails - the receiving interpreter can have as
many references to a receive FIFO as it likes
- get_send_fifo() can fail if the named fifo already exists on the
receiving interpreter and the designated sender is an interpreter
other than the one calling get_send_fifo()
- interpreters are free to use the named FIFO mechanism to send
messages to themselves

To immediately realise some level of efficiency benefits from the
shared memory space between the main interpreter and subinterpreters,
I also think these low level FIFOs should be defined as accepting any
object that supports the PEP 3118 buffer protocol, and emitting
memoryview() objects on the receiving end, rather than being bytes-in,
bytes-out.

Such a memoryview based primitive can then potentially be expanded in
the future to support additional more-efficient-than-multiprocessing
serailisation based protocols, where the sending interpreter
serialises into a region of memory, shares that region with the
subinterpreter via a FIFO memoryview, and then the subinterpreter
deserialises directly from the sending interpreter's memory region,
without the serialised form ever needing to be streamed or copied
anywhere (which is much harder to avoid when coordinating across
multiple operating system processes).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] PEP 557: Data Classes

[Gustavo Carneiro]

Hi, it is not clear whether anything is done to total_cost:

def total_cost(self) -> float:

Does this become a property automatically, or is it still a method call?
To that end, some examples of *using* a data class, not just defining one,
would be helpful.

If it remains a normal method, why put it in this example at all? Makes
little sense...

Otherwise I really like this idea, thanks!


On 8 September 2017 at 15:57, Eric V. Smith  wrote:

> I've written a PEP for what might be thought of as "mutable namedtuples
> with defaults, but not inheriting tuple's behavior" (a mouthful, but it
> sounded simpler when I first thought of it). It's heavily influenced by the
> attrs project. It uses PEP 526 type annotations to define fields. From the
> overview section:
>
> @dataclass
> class InventoryItem:
> name: str
> unit_price: float
> quantity_on_hand: int = 0
>
> def total_cost(self) -> float:
> return self.unit_price * self.quantity_on_hand
>
> Will automatically add these methods:
>
>   def __init__(self, name: str, unit_price: float, quantity_on_hand: int =
> 0) -> None:
>   self.name = name
>   self.unit_price = unit_price
>   self.quantity_on_hand = quantity_on_hand
>   def __repr__(self):
>   return f'InventoryItem(name={self.name!r},unit_price={self.unit_pri
> ce!r},quantity_on_hand={self.quantity_on_hand!r})'
>   def __eq__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) == (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __ne__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) != (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __lt__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) < (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __le__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) <= (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __gt__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) > (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __ge__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) >= (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>
> Data Classes saves you from writing and maintaining these functions.
>
> The PEP is largely complete, but could use some filling out in places.
> Comments welcome!
>
> Eric.
>
> P.S. I wrote this PEP when I was in my happy place.
>
> ___
> 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/gjcarneir
> o%40gmail.com
>



-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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] PEP 556: Threaded garbage collection

[Nick Coghlan]

On 8 September 2017 at 12:40, Nathaniel Smith  wrote:
> Would it make sense to also move signal handlers to run in this
> thread? Those are the other major source of nasty re-entrancy
> problems.

Python level signal handlers are already only run in the main thread,
so applications that want to ensure signals don't run at arbitrary
points in their code are already free to push all their application
logic into a subthread and have the main thread be purely a signal
handling thread.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] PEP 557: Data Classes

[Stéfane Fermigier]

Hi, first post here.

My two cents:

Here's a list of "prior arts" that I have collected over the years, besides
attrs, that address similar needs (and often, much more):

- https://github.com/bluedynamics/plumber
- https://github.com/ionelmc/python-fields
- https://github.com/frasertweedale/elk
- https://github.com/kuujo/yuppy

Regarding the name, 'dataclass', I agree that it can be a bit misleading
(my first idea of a "dataclass" would be a class with only data and no
behaviour, e.g. a 'struct', a 'record', a DTO, 'anemic' class, etc.).

Scala has 'case classes' with some similarities (
https://docs.scala-lang.org/tour/case-classes.html).

Regards,

  S.


On Fri, Sep 8, 2017 at 4:57 PM, Eric V. Smith  wrote:

> I've written a PEP for what might be thought of as "mutable namedtuples
> with defaults, but not inheriting tuple's behavior" (a mouthful, but it
> sounded simpler when I first thought of it). It's heavily influenced by the
> attrs project. It uses PEP 526 type annotations to define fields. From the
> overview section:
>
> @dataclass
> class InventoryItem:
> name: str
> unit_price: float
> quantity_on_hand: int = 0
>
> def total_cost(self) -> float:
> return self.unit_price * self.quantity_on_hand
>
> Will automatically add these methods:
>
>   def __init__(self, name: str, unit_price: float, quantity_on_hand: int =
> 0) -> None:
>   self.name = name
>   self.unit_price = unit_price
>   self.quantity_on_hand = quantity_on_hand
>   def __repr__(self):
>   return f'InventoryItem(name={self.name!r},unit_price={self.unit_pri
> ce!r},quantity_on_hand={self.quantity_on_hand!r})'
>   def __eq__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) == (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __ne__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) != (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __lt__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) < (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __le__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) <= (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __gt__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) > (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __ge__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) >= (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>
> Data Classes saves you from writing and maintaining these functions.
>
> The PEP is largely complete, but could use some filling out in places.
> Comments welcome!
>
> Eric.
>
> P.S. I wrote this PEP when I was in my happy place.
>
> ___
> 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/sfermigie
> r%2Blists%40gmail.com
>



-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
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] PEP 539 v3: A new C API for Thread-Local Storage in CPython

[Erik Bray]

On Fri, Sep 8, 2017 at 4:37 PM, Nick Coghlan  wrote:
> On 8 September 2017 at 00:30, Masayuki YAMAMOTO
>  wrote:
>> Hi folks,
>>
>> I submit PEP 539 third draft for the finish. Thank you for all the advice
>> and the help!
>
> Thank you Erik & Yamamoto-san for all of your work on this PEP!
>
> The updates look good, so I'm happy to say as BDFL-Delegate that this
> proposal is now accepted :)

Thanks Nick!  It's great to have this issue resolved in a
carefully-considered, well-documented manner.

Best,
Erik
___
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] PEP 554 v2 (new "interpreters" module)

[Antoine Pitrou]

On Fri, 8 Sep 2017 16:04:27 -0700
Eric Snow  wrote:
> 
> The module provides the following functions:
> 
> ``list()``::
> 
>Return a list of all existing interpreters.

It's called ``enumerate()`` in the threading module.  Not sure there's
a point in choosing a different name here.

> The module also provides the following classes:
> 
> ``Interpreter(id)``::

>run(code):
> 
>   Run the provided Python code in the interpreter, in the current
>   OS thread.  If the interpreter is already running then raise
>   RuntimeError in the interpreter that called ``run()``.
> 
>   The current interpreter (which called ``run()``) will block
> until the subinterpreter finishes running the requested code.  Any
>   uncaught exception in that code will bubble up to the current
>   interpreter.

Why does it block?  How is concurrency supposed to be achieved in that
model?  It would be more flexible if run(code) returned an object that
can later be waited on.  Something like... a Future :-)

And why guarantee that it executes in the "current OS thread"?
I would say you don't want to specify where it executes exactly, as it
opens the door for more sophisticated implementations (such as
automatic assignment of subinterpreters inside a pool of threads).

>get_fifo(name):
> 
>   Return the FIFO object with the given name that is associated
>   with this interpreter.  If no such FIFO exists then raise
>   KeyError.  The FIFO will be either a "FIFOReader" or a
>   "FIFOWriter", depending on which "add_*_fifo()" was called.
> 
>list_fifos():
> 
>   Return a list of all fifos associated with the interpreter.

If fifos are uniquely named, why not return a name->fifo mapping?

> ``FIFOReader(name)``::
> [...]

I don't think the method naming choice is very adequate here.  The API
model for the FIFO objects can either be a (threading or
multiprocessing) Queue or a multiprocessing Pipe.

- if a Queue, then it should have a get() / put() pair of methods
- if a Pipe, then it should have a recv() / send() pair of methods

Now, since Queues are multi-producer multi-consumer, while Pipes are
single-producer single-consumer (they aren't "synchronized"), the
better analogy seems to the multiprocessing Pipe here, so I would vote
for recv() / send().

But, in any case, definitely not a pop() / push() pair.


Has any thought been given to how FIFOs could integrate with async code
driven by an event loop (e.g. asyncio)?  I think the model of executing
several asyncio (or Tornado) applications each in their own
subinterpreter may prove quite interesting to reconcile multi-core
concurrency with ease of programming.  That would require the FIFOs to
be able to synchronize on something an event loop can wait on (probably
a file descriptor?).

Regards

Antoine.


___
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] PEP 539 v3: A new C API for Thread-Local Storage in CPython

[Masayuki YAMAMOTO]

2017-09-09 2:09 GMT+09:00 Nick Coghlan :

> [...]
> No, we genuinely want to consolidate that state into a single shared
> location. However, the struct definition can be adjusted as needed as
> part of the PEP 539 implementation (and we'll get Eric Snow to be one
> of the PR reviewers).
>
I see. I do merge the field of the runtime structure with the replacement
code as is.

Thanks,
Masayuki
___
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] PEP 554 v2 (new "interpreters" module)

[Antoine Pitrou]

On Sat, 9 Sep 2017 09:04:59 +0100
Paul Moore  wrote:

> On 9 September 2017 at 00:04, Eric Snow  wrote:
> >add_recv_fifo(name=None):
> >
> >   Create a new FIFO, associate the two ends with the involved
> >   interpreters, and return the side associated with the interpreter
> >   in which "add_recv_fifo()" was called.  A FIFOReader gets tied to
> >   this interpreter.  A FIFOWriter gets tied to the interpreter that
> >   called "add_recv_fifo()".
> >
> >   The FIFO's name is set to the provided value.  If no name is
> >   provided then a dynamically generated one is used.  If a FIFO
> >   with the given name is already associated with this interpreter
> >   (or with the one in which "add_recv_fifo()" was called) then raise
> >   KeyError.
> >
> >add_send_fifo(name=None):
> >
> >   Create a new FIFO, associate the two ends with the involved
> >   interpreters, and return the side associated with the interpreter
> >   in which "add_recv_fifo()" was called.  A FIFOWriter gets tied to
> >   this interpreter.  A FIFOReader gets tied to the interpreter that
> >   called "add_recv_fifo()".
> >
> >   The FIFO's name is set to the provided value.  If no name is
> >   provided then a dynamically generated one is used.  If a FIFO
> >   with the given name is already associated with this interpreter
> >   (or with the one in which "add_send_fifo()" was called) then raise
> >   KeyError.  
> 
> Personally, I *always* read these names backwards - from the POV of
> the caller. So when I see "add_send_fifo", I then expect to be able to
> send stuff on the returned FIFO (i.e., I get a writer back). But
> that's not how it works.

Hmm, it's even worse for me, as it's not obvious by the quoted excerpt
how those APIs are supposed to be used exactly.

How does the other interpreter get the FIFO "tied" to it?
Is it `get_current().get_fifo(name)`?  Something else?  How does it get
to learn the *name*?

Why are FIFOs unidirectional?  Does it really make them significantly
cheaper?  With bidirectional pipes, the whole recv/send confusion would
be avoided.

As a point of comparison, for default for `multiprocessing.Pipe()` is
to create a bidirectional pipe (*), yet I'm sure a multiprocessing Pipe
has more overhead than an in-process FIFO.

(*) https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Pipe

Regards

Antoine.


___
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] PEP 554 v2 (new "interpreters" module)

[Paul Moore]

On 9 September 2017 at 00:04, Eric Snow  wrote:
>add_recv_fifo(name=None):
>
>   Create a new FIFO, associate the two ends with the involved
>   interpreters, and return the side associated with the interpreter
>   in which "add_recv_fifo()" was called.  A FIFOReader gets tied to
>   this interpreter.  A FIFOWriter gets tied to the interpreter that
>   called "add_recv_fifo()".
>
>   The FIFO's name is set to the provided value.  If no name is
>   provided then a dynamically generated one is used.  If a FIFO
>   with the given name is already associated with this interpreter
>   (or with the one in which "add_recv_fifo()" was called) then raise
>   KeyError.
>
>add_send_fifo(name=None):
>
>   Create a new FIFO, associate the two ends with the involved
>   interpreters, and return the side associated with the interpreter
>   in which "add_recv_fifo()" was called.  A FIFOWriter gets tied to
>   this interpreter.  A FIFOReader gets tied to the interpreter that
>   called "add_recv_fifo()".
>
>   The FIFO's name is set to the provided value.  If no name is
>   provided then a dynamically generated one is used.  If a FIFO
>   with the given name is already associated with this interpreter
>   (or with the one in which "add_send_fifo()" was called) then raise
>   KeyError.

Personally, I *always* read these names backwards - from the POV of
the caller. So when I see "add_send_fifo", I then expect to be able to
send stuff on the returned FIFO (i.e., I get a writer back). But
that's not how it works.

I may be alone in this - I've had similar problems in the past with
how people name pipes, for example - but I thought I'd raise it while
there's still a possibility that it's not just me and the names can be
changed.

Paul
___
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