Re: [Python-Dev] subprocess not escaping "^" on Windows
On Mon, Jan 8, 2018 at 9:26 PM, Steve Dower wrote: > On 09Jan2018 0744, eryk sun wrote: >> >> It's common to discourage using `shell=True` because it's considered >> insecure. One of the reasons to use CMD in Windows is that it tries >> ShellExecuteEx if CreateProcess fails. ShellExecuteEx supports "App >> Paths" commands, file actions (open, edit, print), UAC elevation (via >> "runas" or if requested by the manifest), protocols (including >> "shell:"), and opening folders in Explorer. It isn't a scripting >> language, however, so it doesn't pose the same risk as using CMD. >> Calling ShellExecuteEx could be integrated in subprocess as a new >> Popen parameter, such as `winshell` or `shellex`. > > This can also be used directly as os.startfile, the only downside being that > you can't wait for the process to complete (but that's due to the underlying > API, which may not end up starting a process but rather sending a message to > an existing long-running one such as explorer.exe). I'd certainly recommend > it for actions like "open this file with its default editor" or "browse to > this web page with the default browser". Yes, I forgot to mention that os.startfile can work sometimes. But often one needs to pass command-line parameters. Also, os.startfile also can't set a different working directory, nShow SW_* window state, or flags such as SEE_MASK_NO_CONSOLE (prevent allocating a new console). Rather than extend os.startfile, it seems more useful in general to wrap ShellExecuteEx in _winapi and extend subprocess. Then os.startfile can be reimplemented in terms of subprocess.Popen, like os.popen. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best Python API for exposing posix_spawn
On 9 January 2018 at 17:07, Serhiy Storchaka wrote: > 09.01.18 05:31, Nick Coghlan пише: >> As with DirEntry, I don't see any obvious value in making the new >> objects iterable though - we should be able to just use named field >> access in both the C and Python APIs. > > Do you suggest to add a class corresponding to posix_spawn_file_actions_t > with methods corresponding to posix_spawn_file_* functions? Sorry, I should have said explicitly that I liked Greg's suggestion of modeling this as an iterable-of-objects at the Python layer - I was just agreeing with Brett that those should be objects with named attributes, rather than relying on tuples with a specific field order. That way a passed in list of actions would look something like one of the following: # Three distinct classes, "FileActions" namespace for disambiguation [os.FileActions.Close(0), os.FileActions.Open(1, '/tmp/mylog', os.O_WRONLY, 0o700), os.FileActions.Dup2(1, 2), ] # Single class, three distinct class constructor methods [os.FileAction.close(0), os.FileAction.open(1, '/tmp/mylog', os.O_WRONLY, 0o700), os.FileAction.dup2(1, 2), ] While my initial comment supported having 3 distinct classes, writing it out that way pushes me more towards having a single type where the constructor names match the relevant module function names. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best Python API for exposing posix_spawn
On Mon, 08 Jan 2018 09:11:38 + Pablo Galindo Salgado wrote: > Hi, > > I'm currently working on exposing posix_spawn in the posix module (and by > extension in the os module). You can find the initial implementation in > this PR: > > https://github.com/python/cpython/pull/5109 > > As pointed out by Gregory P. Smith, some changes are needed in the way the > file_actions arguments is passed from Python. For context, posix_spawn has > the following declaration: > > int posix_spawn(pid_t *pid, const char *path, > const posix_spawn_file_actions_t *file_actions, > const posix_spawnattr_t *attrp, > char *const argv[], char *const envp[]); > > Here, file_actions is an object that represents a list of file actions > (open, close or dup2) that is populated using helper functions on the C API. > > The question is: what is the best way to deal with this argument? How about a list of tuples like: [(os.SPAWN_OPEN, 4, 'README.txt', os.O_RDONLY, 0), (os.SPAWN_CLOSE, 5), (os.SPAWN_DUP2, 3, 6), ] I don't expect this API to be invoked directly by user code so it doesn't have to be extremely pretty. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best Python API for exposing posix_spawn
On 9 January 2018 at 20:01, Antoine Pitrou wrote: > On Mon, 08 Jan 2018 09:11:38 + > Pablo Galindo Salgado wrote: >> Hi, >> >> I'm currently working on exposing posix_spawn in the posix module (and by >> extension in the os module). You can find the initial implementation in >> this PR: >> >> https://github.com/python/cpython/pull/5109 >> >> As pointed out by Gregory P. Smith, some changes are needed in the way the >> file_actions arguments is passed from Python. For context, posix_spawn has >> the following declaration: >> >> int posix_spawn(pid_t *pid, const char *path, >> const posix_spawn_file_actions_t *file_actions, >> const posix_spawnattr_t *attrp, >> char *const argv[], char *const envp[]); >> >> Here, file_actions is an object that represents a list of file actions >> (open, close or dup2) that is populated using helper functions on the C API. >> >> The question is: what is the best way to deal with this argument? > > How about a list of tuples like: > [(os.SPAWN_OPEN, 4, 'README.txt', os.O_RDONLY, 0), > (os.SPAWN_CLOSE, 5), > (os.SPAWN_DUP2, 3, 6), > ] > > I don't expect this API to be invoked directly by user code so it > doesn't have to be extremely pretty. I'll note that one advantage of this approach is that it ties in well with how the C API is going to have to deal with it anyway: a switch statement dispatching on the first value, and then passing the remaining arguments to the corresponding posix_file_actions API. Wrapping it all up in a more Pythonic self-validating API would then be the responsibility of the subprocess module (in the standard library), or third party modules. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 v2
> On Jan 9, 2018, at 11:18 AM, Nathaniel Smith wrote: > >> On Thu, Jan 4, 2018 at 9:42 PM, Guido van Rossum wrote: >>> On Thu, Jan 4, 2018 at 7:58 PM, Nathaniel Smith wrote: >>> This does make me think that I should write up a short PEP for >>> extending PEP 567 to add context lookup, PEP 550 style: it can start >>> out in Status: deferred and then we can debate it properly before 3.8, >>> but at least having the roadmap written down now would make it easier >>> to catch these details. (And it might also help address Paul's >>> reasonable complaint about "unstated requirements".) >> >> Anything that will help us kill a 550-pound gorilla sounds good to me. :-) >> >> It might indeed be pretty short if we follow the lead of ChainMap (even >> using a different API than MutableMapping to mutate it). Maybe >> copy_context() would map to new_child()? Using ChainMap as a model we might >> even avoid the confusion between Lo[gi]calContext and ExecutionContext which >> was the nail in PEP 550's coffin. The LC associated with a generator in PEP >> 550 would be akin to a loose dict which can be pushed on top of a ChainMap >> using cm = cm.new_child(). (Always taking for granted that instead of >> an actual dict we'd use some specialized mutable object implementing the >> Mapping protocol and a custom mutation protocol so it can maintain >> ContextVar cache consistency.) > > The approach I took in PEP 568 is even simpler, I think. The PEP is a > few pages long because I wanted to be exhaustive to make sure we > weren't missing any details, but the tl;dr is: The ChainMap lives > entirely inside the threadstate, so there's no need to create a LC/EC > distinction -- users just see Contexts, or there's the one stack > introspection API, get_context_stack(), which returns a List[Context]. > Instead of messing with new_child, copy_context is just > Context(dict(chain_map)) -- i.e., it creates a flattened copy of the > current mapping. (If we used new_child, then we'd have to have a way > to return a ChainMap, reintroducing the LC/EC mess. This sounds reasonable. Although keep in mind that merging hamt is still an expensive operation, so flattening shouldn't always be performed (this is covered in 550). I also wouldn't call LC/EC a "mess". Your pep just names things differently, but otherwise is entirely built on concepts and ideas introduced in pep 550. Yury ___ Python-Dev mailing list [email protected] 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 pre v3
On Tue, Jan 9, 2018 at 11:02 AM, Nathaniel Smith wrote:
> On Mon, Jan 8, 2018 at 11:34 AM, Yury Selivanov
> wrote:
>> 1. Proposal: ContextVar has default set to None.
>>
>> From the typing point of view that would mean that if a context
>> variable is declared without an explicit default, its type would be
>> Optional. E.g. say we have a hypothetical web framework that allows
>> to access the current request object through a context variable:
>>
>> request_var: ContextVar[Optional[Request]] = \
>> ContextVar('current_request')
>>
>> When we need to get the current request object, we would write:
>>
>> request: Optional[Request] = request_var.get()
>>
>> And we'd also need to explicitly handle when 'request' is set to None.
>> Of course we could create request_var with its default set to some
>> "InvalidRequest" object, but that would complicate things. It would
>> be easier to just state that the framework always sets the current
>> request and it's a bug if it's not set.
>>
>> Therefore, in my opinion, it's better to keep the current behaviour:
>> if a context variable was created without a default value,
>> ContextVar.get() can raise a LookupError.
>
> All the different behaviors here can work, so I don't want to make a
> huge deal about this. But the current behavior is bugging me, and I
> don't think anyone has brought up the reason why, so here goes :-).
>
> Right now, the set of valid states for a ContextVar are: it can hold
> any Python object, or it can be undefined. However, the only way it
> can be in the "undefined" state is in a new Context where it has never
> had a value; once it leaves the undefined state, it can never return
> to it.
Is "undefined" a state when a context variable doesn't have a default
and isn't yet set? If so, why can't it be returned back to the
"undefined" state? That's why we have the 'reset' method:
c = ContextVar('c')
c.get() # LookupError
t = c.set(42)
c.get() # 42
c.reset(t)
c.get() # LookupError
I don't like how context variables are defined in Option 1 and Option
2. I view ContextVars as keys in some global context mapping--akin to
Python variables. Similar to how we have a NameError for variables,
we have a LookupError for context variables. When we write a variable
name, Python looks it up in locals and globals. When we call
ContextVar.get(), Python will look up that context variable in the
current Context. I don't think we should try to classify ContextVar
objects as containers or something capable of holding a value on their
own.
Even when you have a "del some_var" statement, you are only guaranteed
to remove the "some_var" name from the innermost scope. This is
similar to what ContextVar.unset() will do in PEP 568, by removing the
variable only from the head of the chain.
So the sole purpose of ContextVar.default is to make ContextVar.get()
convenient. Context objects don't know about ContextVar.default, and
ContextVars don't know about values they are mapped to in some Context
object.
In any case, at this point I think that the best option is to simply
drop the "default" parameter from the ContextVar constructor. This
would leave us with only one default in ContextVar.get() method:
c.get() # Will raise a LookupError if 'c' is not set
c.get('python') # Will return 'python' if 'c' is not set
I also now see how having two different 'default' values: one defined
when a ContextVar is created, and one can be passed to
ContextVar.get() is confusing.
But I'd be -1 on making all ContextVars have a None default
(effectively have a "ContextVar.get(default=None)" signature. This
would be a very loose semantics in my opinion.
Yury
___
Python-Dev mailing list
[email protected]
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 pre v3
2018-01-09 12:41 GMT+01:00 Yury Selivanov : > But I'd be -1 on making all ContextVars have a None default > (effectively have a "ContextVar.get(default=None)" signature. This > would be a very loose semantics in my opinion. Why do you think that it's a loose semantics? For me ContextVar/Context are similar to Python namespaces and thread local storage. To "declare" a variable in a Python namespace, you have to set it: "global x" doesn't create a variable, only "x = None". It's not possible to define a thread local variable without specifying a "default" value neither. Victor ___ Python-Dev mailing list [email protected] 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 pre v3
By default, threading.local raises an AttributeError (unless you subclass it.) Similar to that and to NameErrors, I think it's a good idea for ContextVars to raise a LookupError if a variable was not explicitly set. Yury On Tue, Jan 9, 2018 at 7:15 PM Victor Stinner wrote: > 2018-01-09 12:41 GMT+01:00 Yury Selivanov : > > But I'd be -1 on making all ContextVars have a None default > > (effectively have a "ContextVar.get(default=None)" signature. This > > would be a very loose semantics in my opinion. > > Why do you think that it's a loose semantics? For me > ContextVar/Context are similar to Python namespaces and thread local > storage. > > To "declare" a variable in a Python namespace, you have to set it: > "global x" doesn't create a variable, only "x = None". > > It's not possible to define a thread local variable without specifying > a "default" value neither. > > Victor > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASE] Python 3.7.0a4 is now available for testing
Python 3.7.0a4 is the last of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.7.0b1, is planned for 2018-01-29. You can find Python 3.7.0a4 and more information here: https://www.python.org/downloads/release/python-370a4/ -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 3.7.0a4 is now available for testing
Hi,
Python 3.7.0a4 includes the implementation of the PEP 538 (C locale
coercion) and PEP 540 (UTF-8 Mode). Please test this Python with
various locales, especially with the POSIX ("C") locale!
Note: The UTF-8 Mode has a known issue with the readline module, I see
how to fix it (add new encode/decode functions which ignore the UTF-8
mode and really use the current locale encoding), but I didn't have
time to fix it yet:
https://bugs.python.org/issue29240#msg308217
(I skipped the test to repair the CI, until I can fix the bug.)
Victor
2018-01-09 16:48 GMT+01:00 Ned Deily :
> Python 3.7.0a4 is the last of four planned alpha releases of Python 3.7,
> the next feature release of Python. During the alpha phase, Python 3.7
> remains under heavy development: additional features will be added
> and existing features may be modified or deleted. Please keep in mind
> that this is a preview release and its use is not recommended for
> production environments. The next preview release, 3.7.0b1, is planned
> for 2018-01-29. You can find Python 3.7.0a4 and more information here:
>
> https://www.python.org/downloads/release/python-370a4/
>
> --
> Ned Deily
> [email protected] -- []
>
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best Python API for exposing posix_spawn
On Tue, 9 Jan 2018 at 02:42 Nick Coghlan wrote: > On 9 January 2018 at 20:01, Antoine Pitrou wrote: > > On Mon, 08 Jan 2018 09:11:38 + > > Pablo Galindo Salgado wrote: > >> Hi, > >> > >> I'm currently working on exposing posix_spawn in the posix module (and > by > >> extension in the os module). You can find the initial implementation in > >> this PR: > >> > >> https://github.com/python/cpython/pull/5109 > >> > >> As pointed out by Gregory P. Smith, some changes are needed in the way > the > >> file_actions arguments is passed from Python. For context, posix_spawn > has > >> the following declaration: > >> > >> int posix_spawn(pid_t *pid, const char *path, > >> const posix_spawn_file_actions_t *file_actions, > >> const posix_spawnattr_t *attrp, > >> char *const argv[], char *const envp[]); > >> > >> Here, file_actions is an object that represents a list of file actions > >> (open, close or dup2) that is populated using helper functions on the C > API. > >> > >> The question is: what is the best way to deal with this argument? > > > > How about a list of tuples like: > > [(os.SPAWN_OPEN, 4, 'README.txt', os.O_RDONLY, 0), > > (os.SPAWN_CLOSE, 5), > > (os.SPAWN_DUP2, 3, 6), > > ] > > > > I don't expect this API to be invoked directly by user code so it > > doesn't have to be extremely pretty. > > I'll note that one advantage of this approach is that it ties in well > with how the C API is going to have to deal with it anyway: a switch > statement dispatching on the first value, and then passing the > remaining arguments to the corresponding posix_file_actions API. > Plus the posix module tends to stick reasonably close to the C API anyway since it's such a thin wrapper. > > Wrapping it all up in a more Pythonic self-validating API would then > be the responsibility of the subprocess module (in the standard > library), or third party modules. > +1 from me on Antoine's suggestion. Might as well keep it simple. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 3.7.0a4 is now available fortesting
FWIW, the ansi and mbcs encodings on Windows do exactly this (as does the oem
encoding with a minor twist). Feel free to reuse either alias if it makes
sense, or make sure a new one also works on Windows.
Top-posted from my Windows phone
From: Victor Stinner
Sent: Wednesday, January 10, 2018 3:37
To: Python Dev
Subject: Re: [Python-Dev] [RELEASE] Python 3.7.0a4 is now available fortesting
Hi,
Python 3.7.0a4 includes the implementation of the PEP 538 (C locale
coercion) and PEP 540 (UTF-8 Mode). Please test this Python with
various locales, especially with the POSIX ("C") locale!
Note: The UTF-8 Mode has a known issue with the readline module, I see
how to fix it (add new encode/decode functions which ignore the UTF-8
mode and really use the current locale encoding), but I didn't have
time to fix it yet:
https://bugs.python.org/issue29240#msg308217
(I skipped the test to repair the CI, until I can fix the bug.)
Victor
2018-01-09 16:48 GMT+01:00 Ned Deily :
> Python 3.7.0a4 is the last of four planned alpha releases of Python 3.7,
> the next feature release of Python. During the alpha phase, Python 3.7
> remains under heavy development: additional features will be added
> and existing features may be modified or deleted. Please keep in mind
> that this is a preview release and its use is not recommended for
> production environments. The next preview release, 3.7.0b1, is planned
> for 2018-01-29. You can find Python 3.7.0a4 and more information here:
>
> https://www.python.org/downloads/release/python-370a4/
>
> --
> Ned Deily
> [email protected] -- []
>
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] subprocess not escaping "^" on Windows
My feeling is that the number of uses for calling cmd /c is rather limited on Windows. Certainly calling out to use the CMD builtin is not to be encouraged I'd say. Between shutil and the os module you have most of the file handling commands. Admin tools might want to run special commands, but they are not builtins. In all the cases where you have a command line exe to run you can avoid calling into cmd and the associated quoting problems. I've found that in all my windows python apps I typically end up using CreateProcess and ShellExecute for the useful stuff. (I use ctypes to call them). Is it worth changing the quoting at all? I would say not. Barry ___ Python-Dev mailing list [email protected] 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 pre v3
There are too many words here for me to follow. I'll wait a few days and then hopefully there's a new proposal that you are all in agreement with, or there are two brief alternatives that I have to choose between. On Tue, Jan 9, 2018 at 7:41 AM, Yury Selivanov wrote: > By default, threading.local raises an AttributeError (unless you subclass > it.) Similar to that and to NameErrors, I think it's a good idea for > ContextVars to raise a LookupError if a variable was not explicitly set. > > Yury > > > On Tue, Jan 9, 2018 at 7:15 PM Victor Stinner > wrote: > >> 2018-01-09 12:41 GMT+01:00 Yury Selivanov : >> > But I'd be -1 on making all ContextVars have a None default >> > (effectively have a "ContextVar.get(default=None)" signature. This >> > would be a very loose semantics in my opinion. >> >> Why do you think that it's a loose semantics? For me >> ContextVar/Context are similar to Python namespaces and thread local >> storage. >> >> To "declare" a variable in a Python namespace, you have to set it: >> "global x" doesn't create a variable, only "x = None". >> >> It's not possible to define a thread local variable without specifying >> a "default" value neither. >> >> Victor >> > > ___ > Python-Dev mailing list > [email protected] > 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
Hi all, I feel like I should write some thoughts regarding the "context" discussion, related to the various PEPs. I like PEP 567 (+ 567 ?) better than PEP 550. However, besides providing cvar.set(), I'm not really sure about the gain compared to PEP 555 (which could easily have e.g. a dict-like interface to the context). I'm still not a big fan of "get"/"set" here, but the idea was indeed to provide those on top of a PEP 555 type thing too. "Tokens" in PEP 567, seems to resemble assignment context managers in PEP 555. However, they feel a bit messy to me, because they make it look like one could just set a variable and then revert the change at any point in time after that. PEP 555 is in fact a simplification of my previous sketch that had a .set(..) in it, but was somewhat different from PEP 550. The idea was to always explicitly define the scope of contextvar values. A context manager / with statement determined the scope of .set(..) operations inside the with statement: # Version A: cvar.set(1) with context_scope(): cvar.set(2) assert cvar.get() == 2 assert cvar.get() == 1 Then I added the ability to define scopes for different variables separately: # Version B cvar1.set(1) cvar2.set(2) with context_scope(cvar1): cvar1.set(11) cvar2.set(22) assert cvar1.get() == 1 assert cvar2.get() == 22 However, in practice, most libraries would wrap __enter__, set and __exit__ into another context manager. So maybe one might want to allow something like # Version C: assert cvar.get() == something with context_scope(cvar, 2): assert cvar.get() == 2 assert cvar.get() == something But this then led to combining "__enter__" and ".set(..)" into Assignment.__enter__ -- and "__exit__" into Assignment.__exit__ like this: # PEP 555 draft version: assert cvar.value == something with cvar.assign(1): assert cvar.value == 1 assert cvar.value == something Anyway, given the schedule, I'm not really sure about the best thing to do here. In principle, something like in versions A, B and C above could be done (I hope the proposal was roughly self-explanatory based on earlier discussions). However, at this point, I'd probably need a lot of help to make that happen for 3.7. -- Koos ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
Wasn't PEP 555 rejected by Guido? What's the point of this post? Yury On Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven wrote: > Hi all, > > I feel like I should write some thoughts regarding the "context" > discussion, related to the various PEPs. > > I like PEP 567 (+ 567 ?) better than PEP 550. However, besides providing > cvar.set(), I'm not really sure about the gain compared to PEP 555 (which > could easily have e.g. a dict-like interface to the context). I'm still not > a big fan of "get"/"set" here, but the idea was indeed to provide those on > top of a PEP 555 type thing too. > > "Tokens" in PEP 567, seems to resemble assignment context managers in PEP > 555. However, they feel a bit messy to me, because they make it look like > one could just set a variable and then revert the change at any point in > time after that. > > PEP 555 is in fact a simplification of my previous sketch that had a > .set(..) in it, but was somewhat different from PEP 550. The idea was to > always explicitly define the scope of contextvar values. A context manager > / with statement determined the scope of .set(..) operations inside the > with statement: > > # Version A: > cvar.set(1) > with context_scope(): > cvar.set(2) > > assert cvar.get() == 2 > > assert cvar.get() == 1 > > Then I added the ability to define scopes for different variables > separately: > > # Version B > cvar1.set(1) > cvar2.set(2) > with context_scope(cvar1): > cvar1.set(11) > cvar2.set(22) > > assert cvar1.get() == 1 > assert cvar2.get() == 22 > > > However, in practice, most libraries would wrap __enter__, set and > __exit__ into another context manager. So maybe one might want to allow > something like > > # Version C: > assert cvar.get() == something > with context_scope(cvar, 2): > assert cvar.get() == 2 > > assert cvar.get() == something > > > But this then led to combining "__enter__" and ".set(..)" into > Assignment.__enter__ -- and "__exit__" into Assignment.__exit__ like this: > > # PEP 555 draft version: > assert cvar.value == something > with cvar.assign(1): > assert cvar.value == 1 > > assert cvar.value == something > > > Anyway, given the schedule, I'm not really sure about the best thing to do > here. In principle, something like in versions A, B and C above could be > done (I hope the proposal was roughly self-explanatory based on earlier > discussions). However, at this point, I'd probably need a lot of help to > make that happen for 3.7. > > -- Koos > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
On Jan 10, 2018 07:17, "Yury Selivanov" wrote: Wasn't PEP 555 rejected by Guido? What's the point of this post? I sure hope there is a point. I don't think mentioning PEP 555 in the discussions should hurt. A typo in my post btw: should be "PEP 567 (+568 ?)" in the second paragraph of course. -- Koos (mobile) Yury On Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven wrote: > Hi all, > > I feel like I should write some thoughts regarding the "context" > discussion, related to the various PEPs. > > I like PEP 567 (+ 567 ?) better than PEP 550. However, besides providing > cvar.set(), I'm not really sure about the gain compared to PEP 555 (which > could easily have e.g. a dict-like interface to the context). I'm still not > a big fan of "get"/"set" here, but the idea was indeed to provide those on > top of a PEP 555 type thing too. > > "Tokens" in PEP 567, seems to resemble assignment context managers in PEP > 555. However, they feel a bit messy to me, because they make it look like > one could just set a variable and then revert the change at any point in > time after that. > > PEP 555 is in fact a simplification of my previous sketch that had a > .set(..) in it, but was somewhat different from PEP 550. The idea was to > always explicitly define the scope of contextvar values. A context manager > / with statement determined the scope of .set(..) operations inside the > with statement: > > # Version A: > cvar.set(1) > with context_scope(): > cvar.set(2) > > assert cvar.get() == 2 > > assert cvar.get() == 1 > > Then I added the ability to define scopes for different variables > separately: > > # Version B > cvar1.set(1) > cvar2.set(2) > with context_scope(cvar1): > cvar1.set(11) > cvar2.set(22) > > assert cvar1.get() == 1 > assert cvar2.get() == 22 > > > However, in practice, most libraries would wrap __enter__, set and > __exit__ into another context manager. So maybe one might want to allow > something like > > # Version C: > assert cvar.get() == something > with context_scope(cvar, 2): > assert cvar.get() == 2 > > assert cvar.get() == something > > > But this then led to combining "__enter__" and ".set(..)" into > Assignment.__enter__ -- and "__exit__" into Assignment.__exit__ like this: > > # PEP 555 draft version: > assert cvar.value == something > with cvar.assign(1): > assert cvar.value == 1 > > assert cvar.value == something > > > Anyway, given the schedule, I'm not really sure about the best thing to do > here. In principle, something like in versions A, B and C above could be > done (I hope the proposal was roughly self-explanatory based on earlier > discussions). However, at this point, I'd probably need a lot of help to > make that happen for 3.7. > > -- Koos > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > yselivanov.ml%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
