Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL>=2.5.3

[Christian Heimes]

On 2018-01-16 22:47, Steve Dower wrote:
> I think you mean out-of-band updates, and by “you” I'm going to pretend
> you mean PyCA ;)

Err, yes :)

___
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 567 v3

[Antoine Pitrou]

On Tue, 16 Jan 2018 17:18:06 -0800
Nathaniel Smith  wrote:
> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov  
> wrote:
> >
> > I think it would be a very fragile thing In practice: if you have even
> > one variable in the context that isn't pickleable, your code that uses
> > a ProcessPool would stop working.  I would defer Context pickleability
> > to 3.8+.  
> 
> There's also a more fundamental problem: you need some way to match up
> the ContextVar objects across the two processes, and right now they
> don't have an attached __module__ or __qualname__.

They have a name, though.  So perhaps the name could serve as a unique
identifier?  Instead of being serialized as a bunch of ContextVars, the
Context would then be serialized as a {name: value} dict.

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

[Python-Dev] Positional-only parameters in Python

[Victor Stinner]

Hi,

In Februrary 2017, I proposed on python-ideas to change the Python
syntax to allow to declare positional-only parameters in Python:

https://mail.python.org/pipermail/python-ideas/2017-February/044879.html
https://mail.python.org/pipermail/python-ideas/2017-March/044956.html

There are already supported at the C level, but not at the Python level.

Our BDFL approved the idea:

https://mail.python.org/pipermail/python-ideas/2017-March/044959.html

But I didn't find time to implement it. Does someone want to work on
an implementation of the idea?

March 2, 2017 7:16 PM, "Brett Cannon"  wrote:
> It seems all the core devs who have commented on this are in the positive
> (Victor, Yury, Ethan, Yury, Guido, Terry, and Steven; MAL didn't explicitly
> vote). So to me that suggests there's enough support to warrant writing a
> PEP. Are you up for writing it, Victor, or is someone else going to write
> it?

It seems like a PEP is needed.

Victor
___
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 567 v3

[Yury Selivanov]

On Wed, Jan 17, 2018 at 6:03 AM, Antoine Pitrou  wrote:
> On Tue, 16 Jan 2018 17:18:06 -0800
> Nathaniel Smith  wrote:
>> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov  
>> wrote:
>> >
>> > I think it would be a very fragile thing In practice: if you have even
>> > one variable in the context that isn't pickleable, your code that uses
>> > a ProcessPool would stop working.  I would defer Context pickleability
>> > to 3.8+.
>>
>> There's also a more fundamental problem: you need some way to match up
>> the ContextVar objects across the two processes, and right now they
>> don't have an attached __module__ or __qualname__.
>
> They have a name, though.  So perhaps the name could serve as a unique
> identifier?  Instead of being serialized as a bunch of ContextVars, the
> Context would then be serialized as a {name: value} dict.

One of the points of the ContextVar design is to avoid having unique
identifiers requirement. Names can clash which leads to data being
lost. If you prohibit them from clashing, then if libraries A and B
happen to use the same context variable name—you can't use them both
in your projects.  And without enforcing name uniqueness, your
approach to serialize context as a dict with string keys won't work.

I like Nathaniel's idea to explicitly enable ContextVars pickling
support on a per-var basis.  Unfortunately we don't have time to
seriously consider and debate (and implement!) this idea in time
before the 3.7 freeze.

In the meanwhile, given that Context objects are fully introspectable,
users can implement their own ad-hoc solutions for serializers or
cross-process execution.

Yury
___
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] Positional-only parameters in Python

[Mario Corchero]

Hi Victor,

I'd like to work on it if you accept "a random person" to work on it
(saying it in case the mail was directed to core developers).

Regards,
Mario

On 17 January 2018 at 14:34, Victor Stinner 
wrote:

> Hi,
>
> In Februrary 2017, I proposed on python-ideas to change the Python
> syntax to allow to declare positional-only parameters in Python:
>
> https://mail.python.org/pipermail/python-ideas/2017-February/044879.html
> https://mail.python.org/pipermail/python-ideas/2017-March/044956.html
>
> There are already supported at the C level, but not at the Python level.
>
> Our BDFL approved the idea:
>
> https://mail.python.org/pipermail/python-ideas/2017-March/044959.html
>
> But I didn't find time to implement it. Does someone want to work on
> an implementation of the idea?
>
> March 2, 2017 7:16 PM, "Brett Cannon"  wrote:
> > It seems all the core devs who have commented on this are in the positive
> > (Victor, Yury, Ethan, Yury, Guido, Terry, and Steven; MAL didn't
> explicitly
> > vote). So to me that suggests there's enough support to warrant writing a
> > PEP. Are you up for writing it, Victor, or is someone else going to write
> > it?
>
> It seems like a PEP is needed.
>
> Victor
> ___
> 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/
> mariocj89%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] python exe installer is broken

[Joshua Yeow]

Dear Python Developers
I hope to be able to use the latest version Python on my Windows 7 PC soon.
The installer is very buggy and as I have discovered that the new exe
installer since version 3.5.0 introduces more and more bugs that are yet to
be resolved. Python erases all it's files, except the installer and
state.rsm within the Package Cache folder, if I change the installation
directory and or select "Install for all users" when undergoing the custom
installation. After upgrading to version 3.6.4, Python erased all it's
files, except the installer and state.rsm within the Package Cache folder,
because I have Python in a directory other than
"..\AppData\Local\Programs\Python\Python36". The Python 3.6.4 installer
won't install pip, and pip.exe won't be present in the Package Cache
folder, even if it is selected in the custom installation and modifying the
installation to do so will cause Python to erases all it's files,
except the installer and state.rsm within the Package Cache folder. Trying
to install pip from a pip.exe of a previous version to 3.6.4, such as
3.6.3, will be unsuccessful. Repairing Python 3.6.4 will instead install
Python into "..\AppData\Local\Programs\Python\Python36" with all optional
features except for pip. My only option is to keep the default directory
and install Python from 3.6.3 or below. Ever since the first version of the
new exe installer, installing to a directory other than
"..\AppData\Local\Programs\Python\Python36" has proven impossible. The old
msi installer had none of the issues so I hope you developers actually try
out the exe installer and see the problems for yourselves.
___
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] Positional-only parameters in Python

[Serhiy Storchaka]

17.01.18 16:34, Victor Stinner пише:

In Februrary 2017, I proposed on python-ideas to change the Python
syntax to allow to declare positional-only parameters in Python:

https://mail.python.org/pipermail/python-ideas/2017-February/044879.html
https://mail.python.org/pipermail/python-ideas/2017-March/044956.html

There are already supported at the C level, but not at the Python level.

Our BDFL approved the idea:

https://mail.python.org/pipermail/python-ideas/2017-March/044959.html

But I didn't find time to implement it. Does someone want to work on
an implementation of the idea?


The main problem -- designing a syntax that does not look ugly. I think 
there are too small time is left before features freezing for 
experimenting with it. It would be better to make such changes at the 
early stage of development.


___
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] Positional-only parameters in Python

[Ethan Furman]

On 01/17/2018 08:14 AM, Serhiy Storchaka wrote:

17.01.18 16:34, Victor Stinner пише:

In Februrary 2017, I proposed on python-ideas to change the Python
syntax to allow to declare positional-only parameters in Python:

https://mail.python.org/pipermail/python-ideas/2017-February/044879.html
https://mail.python.org/pipermail/python-ideas/2017-March/044956.html


The main problem -- designing a syntax that does not look ugly. I

> think there are too small time is left before features freezing for
> experimenting with it. It would be better to make such changes at the
> early stage of development.

The syntax question is already solved:

   def some_func(a, b, /, this, that, *, the_other):
   # some stuff

Everything before the slash is positional-only, between the slash and star is positional-or-keyword, and after the star 
is keyword-only.  This is what is in our generated help(), and there is a nice symmetry between '/' and '*' being 
opposites, and positional/keyword being opposites.  And slash is certainly no uglier than star.  ;)


--
~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/archive%40mail-archive.com

Re: [Python-Dev] Positional-only parameters in Python

[Oleg Broytman]

On Wed, Jan 17, 2018 at 08:29:16AM -0800, Ethan Furman  
wrote:
>def some_func(a, b, /, this, that, *, the_other):
># some stuff
> 
> Everything before the slash is positional-only, between the slash and star
> is positional-or-keyword, and after the star is keyword-only.

   Is there syntax to combine

def some_func(a, b, /, *, the_other):

   ??? May be

def some_func(a, b, /*, the_other):

   ???

> And slash is
> certainly no uglier than star.  ;)

   I tend to agree. Both are absolutely but equally ugly. :-(

> --
> ~Ethan~

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] Positional-only parameters in Python

[Barry Warsaw]

On Jan 17, 2018, at 08:14, Serhiy Storchaka  wrote:
> 
> The main problem -- designing a syntax that does not look ugly. I think there 
> are too small time is left before features freezing for experimenting with 
> it. It would be better to make such changes at the early stage of development.

A PEP is definitely needed.  Can someone get a PEP written, approved, with the 
feature implemented in 12 days?  As much as I like the idea, I think it’s 
unlikely.  But hey, you never know so if someone is really motivated, go for 
it!  The effort won’t be wasted in any case, since 3.8’s right around the 
corner .

-Barry



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] Positional-only parameters in Python

[Guido van Rossum]

Let's aim for 3.8 here. We're already cramming in a lot of stuff for the
feature freeze.

On Wed, Jan 17, 2018 at 8:52 AM, Barry Warsaw  wrote:

> On Jan 17, 2018, at 08:14, Serhiy Storchaka  wrote:
> >
> > The main problem -- designing a syntax that does not look ugly. I think
> there are too small time is left before features freezing for experimenting
> with it. It would be better to make such changes at the early stage of
> development.
>
> A PEP is definitely needed.  Can someone get a PEP written, approved, with
> the feature implemented in 12 days?  As much as I like the idea, I think
> it’s unlikely.  But hey, you never know so if someone is really motivated,
> go for it!  The effort won’t be wasted in any case, since 3.8’s right
> around the corner .
>
> -Barry
>
>
> ___
> 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] Positional-only parameters in Python

[Sanyam Khurana]

Hi,

On Wed, Jan 17, 2018 at 8:04 PM, Victor Stinner
 wrote:
> Hi,
>
> In Februrary 2017, I proposed on python-ideas to change the Python
> syntax to allow to declare positional-only parameters in Python:
>
> https://mail.python.org/pipermail/python-ideas/2017-February/044879.html
> https://mail.python.org/pipermail/python-ideas/2017-March/044956.html
>
> There are already supported at the C level, but not at the Python level.
>
> Our BDFL approved the idea:
>
> https://mail.python.org/pipermail/python-ideas/2017-March/044959.html
>
> But I didn't find time to implement it. Does someone want to work on
> an implementation of the idea?
>
> March 2, 2017 7:16 PM, "Brett Cannon"  wrote:
>> It seems all the core devs who have commented on this are in the positive
>> (Victor, Yury, Ethan, Yury, Guido, Terry, and Steven; MAL didn't explicitly
>> vote). So to me that suggests there's enough support to warrant writing a
>> PEP. Are you up for writing it, Victor, or is someone else going to write
>> it?
>
> It seems like a PEP is needed.

I followed the threads mentioned above, which led me to PEP 457:
https://www.python.org/dev/peps/pep-0457/

I didn't find a clear indication if it was still to be modified,
approved or rejected. Can anyone help?

Also, on a second note, I can help with writing a PEP (would prefer
co-authoring with someone ), but this would be my first time and
I would really appreciate guidance of core-developers.


-- 
Mozilla Rep
http://www.SanyamKhurana.com
Github: CuriousLearner
___
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 567 v3

[Guido van Rossum]

Perhaps you can update the PEP with a summary of the rejected ideas from
this thread?

On Jan 17, 2018 7:23 AM, "Yury Selivanov"  wrote:

> On Wed, Jan 17, 2018 at 6:03 AM, Antoine Pitrou 
> wrote:
> > On Tue, 16 Jan 2018 17:18:06 -0800
> > Nathaniel Smith  wrote:
> >> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov <
> yselivanov...@gmail.com> wrote:
> >> >
> >> > I think it would be a very fragile thing In practice: if you have even
> >> > one variable in the context that isn't pickleable, your code that uses
> >> > a ProcessPool would stop working.  I would defer Context pickleability
> >> > to 3.8+.
> >>
> >> There's also a more fundamental problem: you need some way to match up
> >> the ContextVar objects across the two processes, and right now they
> >> don't have an attached __module__ or __qualname__.
> >
> > They have a name, though.  So perhaps the name could serve as a unique
> > identifier?  Instead of being serialized as a bunch of ContextVars, the
> > Context would then be serialized as a {name: value} dict.
>
> One of the points of the ContextVar design is to avoid having unique
> identifiers requirement. Names can clash which leads to data being
> lost. If you prohibit them from clashing, then if libraries A and B
> happen to use the same context variable name—you can't use them both
> in your projects.  And without enforcing name uniqueness, your
> approach to serialize context as a dict with string keys won't work.
>
> I like Nathaniel's idea to explicitly enable ContextVars pickling
> support on a per-var basis.  Unfortunately we don't have time to
> seriously consider and debate (and implement!) this idea in time
> before the 3.7 freeze.
>
> In the meanwhile, given that Context objects are fully introspectable,
> users can implement their own ad-hoc solutions for serializers or
> cross-process execution.
>
> Yury
> ___
> 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
>
___
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] python exe installer is broken

[Brett Cannon]

This seems like a bug report and is best reported on bugs.python.org.

On Wed, 17 Jan 2018 at 08:05 Joshua Yeow  wrote:

> Dear Python Developers
> I hope to be able to use the latest version Python on my Windows 7 PC
> soon. The installer is very buggy and as I have discovered that the new exe
> installer since version 3.5.0 introduces more and more bugs that are yet to
> be resolved. Python erases all it's files, except the installer and
> state.rsm within the Package Cache folder, if I change the installation
> directory and or select "Install for all users" when undergoing the custom
> installation. After upgrading to version 3.6.4, Python erased all it's
> files, except the installer and state.rsm within the Package Cache folder,
> because I have Python in a directory other than
> "..\AppData\Local\Programs\Python\Python36". The Python 3.6.4 installer
> won't install pip, and pip.exe won't be present in the Package Cache
> folder, even if it is selected in the custom installation and modifying the
> installation to do so will cause Python to erases all it's files,
> except the installer and state.rsm within the Package Cache folder. Trying
> to install pip from a pip.exe of a previous version to 3.6.4, such as
> 3.6.3, will be unsuccessful. Repairing Python 3.6.4 will instead install
> Python into "..\AppData\Local\Programs\Python\Python36" with all optional
> features except for pip. My only option is to keep the default directory
> and install Python from 3.6.3 or below. Ever since the first version of the
> new exe installer, installing to a directory other than
> "..\AppData\Local\Programs\Python\Python36" has proven impossible. The old
> msi installer had none of the issues so I hope you developers actually try
> out the exe installer and see the problems for yourselves.
> ___
> 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/brett%40python.org
>
___
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] python exe installer is broken

[Steve Dower]

And please include all the Python log files from your %TEMP% directory.

On 18Jan2018 0802, Brett Cannon wrote:
This seems like a bug report and is best reported on bugs.python.org 
.


On Wed, 17 Jan 2018 at 08:05 Joshua Yeow > wrote:


Dear Python Developers
I hope to be able to use the latest version Python on my Windows 7
PC soon. The installer is very buggy and as I have discovered that
the new exe installer since version 3.5.0 introduces more and more
bugs that are yet to be resolved. Python erases all it's files,
except the installer and state.rsm within the Package Cache folder,
if I change the installation directory and or select "Install for
all users" when undergoing the custom installation. After upgrading
to version 3.6.4, Python erased all it's files, except the installer
and state.rsm within the Package Cache folder, because I have Python
in a directory other than
"..\AppData\Local\Programs\Python\Python36". The Python 3.6.4
installer won't install pip, and pip.exe won't be present in the
Package Cache folder, even if it is selected in the custom
installation and modifying the installation to do so will cause
Python to erases all it's files, except the installer and
state.rsm within the Package Cache folder. Trying to install pip
from a pip.exe of a previous version to 3.6.4, such as 3.6.3, will
be unsuccessful. Repairing Python 3.6.4 will instead install Python
into "..\AppData\Local\Programs\Python\Python36" with all optional
features except for pip. My only option is to keep the default
directory and install Python from 3.6.3 or below. Ever since the
first version of the new exe installer, installing to a directory
other than "..\AppData\Local\Programs\Python\Python36" has proven
impossible. The old msi installer had none of the issues so I hope
you developers actually try out the exe installer and see the
problems for yourselves.


___
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 567 v3

[Victor Stinner]

FYI In the PEP 540, I didn't try to elaborate on each design change, but I
wrote a very short version history at the end:
https://www.python.org/dev/peps/pep-0540/#version-history

Maybe something like that would help for the PEP 567?

Victor

Le 17 janv. 2018 8:26 PM, "Guido van Rossum"  a
écrit :

> Perhaps you can update the PEP with a summary of the rejected ideas from
> this thread?
>
> On Jan 17, 2018 7:23 AM, "Yury Selivanov"  wrote:
>
>> On Wed, Jan 17, 2018 at 6:03 AM, Antoine Pitrou 
>> wrote:
>> > On Tue, 16 Jan 2018 17:18:06 -0800
>> > Nathaniel Smith  wrote:
>> >> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov <
>> yselivanov...@gmail.com> wrote:
>> >> >
>> >> > I think it would be a very fragile thing In practice: if you have
>> even
>> >> > one variable in the context that isn't pickleable, your code that
>> uses
>> >> > a ProcessPool would stop working.  I would defer Context
>> pickleability
>> >> > to 3.8+.
>> >>
>> >> There's also a more fundamental problem: you need some way to match up
>> >> the ContextVar objects across the two processes, and right now they
>> >> don't have an attached __module__ or __qualname__.
>> >
>> > They have a name, though.  So perhaps the name could serve as a unique
>> > identifier?  Instead of being serialized as a bunch of ContextVars, the
>> > Context would then be serialized as a {name: value} dict.
>>
>> One of the points of the ContextVar design is to avoid having unique
>> identifiers requirement. Names can clash which leads to data being
>> lost. If you prohibit them from clashing, then if libraries A and B
>> happen to use the same context variable name—you can't use them both
>> in your projects.  And without enforcing name uniqueness, your
>> approach to serialize context as a dict with string keys won't work.
>>
>> I like Nathaniel's idea to explicitly enable ContextVars pickling
>> support on a per-var basis.  Unfortunately we don't have time to
>> seriously consider and debate (and implement!) this idea in time
>> before the 3.7 freeze.
>>
>> In the meanwhile, given that Context objects are fully introspectable,
>> users can implement their own ad-hoc solutions for serializers or
>> cross-process execution.
>>
>> Yury
>> ___
>> 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
>>
>
> ___
> 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 567 v3

[Yury Selivanov]

On Wed, Jan 17, 2018 at 2:24 PM, Guido van Rossum  wrote:
> Perhaps you can update the PEP with a summary of the rejected ideas from
> this thread?

The Rejected Ideas section of the PEP is now updated with the below:

Token.reset() instead of ContextVar.reset()
---

Nathaniel Smith suggested to implement the ``ContextVar.reset()``
method directly on the ``Token`` class, so instead of::

token = var.set(value)
# ...
var.reset(token)

we would write::

token = var.set(value)
# ...
token.reset()

Having ``Token.reset()`` would make it impossible for a user to
attempt to reset a variable with a token object created by another
variable.

This proposal was rejected for the reason of ``ContextVar.reset()``
being clearer to the human reader of the code which variable is
being reset.


Make Context objects picklable
--

Proposed by Antoine Pitrou, this could enable transparent
cross-process use of ``Context`` objects, so the
`Offloading execution to other threads`_ example would work with
a ``ProcessPoolExecutor`` too.

Enabling this is problematic because of the following reasons:

1. ``ContextVar`` objects do not have ``__module__`` and
   ``__qualname__`` attributes, making straightforward pickling
   of ``Context`` objects impossible.  This is solvable by modifying
   the API to either auto detect the module where a context variable
   is defined, or by adding a new keyword-only "module" parameter
   to ``ContextVar`` constructor.

2. Not all context variables refer to picklable objects.  Making a
   ``ContextVar`` picklable must be an opt-in.

Given the time frame of the Python 3.7 release schedule it was decided
to defer this proposal to Python 3.8.


Yury
___
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] Positional-only parameters in Python

[Nick Coghlan]

On 18 January 2018 at 03:16, Sanyam Khurana  wrote:
> On Wed, Jan 17, 2018 at 8:04 PM, Victor Stinner
>  wrote:
>> It seems like a PEP is needed.
>
> I followed the threads mentioned above, which led me to PEP 457:
> https://www.python.org/dev/peps/pep-0457/
>
> I didn't find a clear indication if it was still to be modified,
> approved or rejected. Can anyone help?

Effectively deferred, since Guido decided we didn't need a PEP for the
__text_signature__ syntax in the inspect module:

>>> import inspect
>>> inspect.signature(ord)

>>> ord.__text_signature__
'($module, c, /)'

(The motivation was to give Argument Clinic a way to communicate C
level signatures up to Python code)

A PEP for Python level positional-only argument syntax would be able
to rely on Signature.__repr__ and __text_signature__ as precedent for
using "/" to indicate that the preceding parameters are
positional-only, though.

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 567 v3

[Yury Selivanov]

On Wed, Jan 17, 2018 at 8:53 PM, Yury Selivanov  wrote:
> On Wed, Jan 17, 2018 at 2:24 PM, Guido van Rossum  
> wrote:
>> Perhaps you can update the PEP with a summary of the rejected ideas from
>> this thread?
>
> The Rejected Ideas section of the PEP is now updated with the below:

I've added two more subsections to Rejected Ideas:


Make Context a MutableMapping
-

Making the ``Context`` class implement the ``abc.MutableMapping``
interface would mean that it is possible to set and unset variables
using ``Context[var] = value`` and ``del Context[var]`` operations.

This proposal was deferred to Python 3.8+ because of the following:

1. If in Python 3.8 it is decided that generators should support
   context variables (see :pep:`550` and :pep:`568`), then ``Context``
   would be transformed into a chain-map of context variables mappings
   (as every generator would have its own mapping).  That would make
   mutation operations like ``Context.__delitem__`` confusing, as
   they would operate only on the topmost mapping of the chain.

2. Having a single way of mutating the context
   (``ContextVar.set()`` and ``ContextVar.reset()`` methods) makes
   the API more straightforward.

   For example, it would be non-obvious why the below code fragment
   does not work as expected::

 var = ContextVar('var')

 ctx = copy_context()
 ctx[var] = 'value'
 print(ctx[var])  # Prints 'value'

 print(var.get())  # Raises a LookupError

   While the following code would work::

 ctx = copy_context()

 def func():
 ctx[var] = 'value'

 # Contrary to the previous example, this would work
 # because 'func()' is running within 'ctx'.
 print(ctx[var])
 print(var.get())

 ctx.run(func)


Have initial values for ContextVars
---

Nathaniel Smith proposed to have a required ``initial_value``
keyword-only argument for the ``ContextVar`` constructor.

The main argument against this proposal is that for some types
there is simply no sensible "initial value" except ``None``.
E.g. consider a web framework that stores the current HTTP
request object in a context variable.  With the current semantics
it is possible to create a context variable without a default value::

# Framework:
current_request: ContextVar[Request] = \
ContextVar('current_request')


# Later, while handling an HTTP request:
request: Request = current_request.get()

# Work with the 'request' object:
return request.method

Note that in the above example there is no need to check if
``request`` is ``None``.  It is simply expected that the framework
always sets the ``current_request`` variable, or it is a bug (in
which case ``current_request.get()`` would raise a ``LookupError``).

If, however, we had a required initial value, we would have
to guard against ``None`` values explicitly::

# Framework:
current_request: ContextVar[Optional[Request]] = \
ContextVar('current_request', initial_value=None)


# Later, while handling an HTTP request:
request: Optional[Request] = current_request.get()

# Check if the current request object was set:
if request is None:
raise RuntimeError

# Work with the 'request' object:
return request.method

Moreover, we can loosely compare context variables to regular
Python variables and to ``threading.local()`` objects.  Both
of them raise errors on failed lookups (``NameError`` and
``AttributeError`` respectively).

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