Mailman 3 January 2018 - Python-Dev

python exe installer is broken
by Joshua Yeow Jan. 18, 2018

Jan. 18, 2018

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.

3 2

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL>=2.5.3
by Christian Heimes Jan. 17, 2018

Jan. 17, 2018

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 :)

1 0

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >=2.5.3
by Christian Heimes Jan. 16, 2018

Jan. 16, 2018

On 2018-01-16 08:08, Steve Dower wrote: > From my perspective, we can’t keep an OpenSSL-like API and use Windows > platform libraries (we *could* do a requests-like API easily enough, but > even urllib3 is painfully low-level). > > > > We have to continue shipping our own copy of OpenSSL on Windows. Nothing > to negotiate here except whether OpenSSL releases should trigger a > Python release, and I think that decision can stay with the RM. 3.7 will no longer use static linking. We can offer out-of-bounds updates of the OpenSSL DLLs. And by "we", I'm talking about you. :) Christian

2 1

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3
by Wes Turner Jan. 16, 2018

Jan. 16, 2018

On Tuesday, January 16, 2018, Steve Dower <steve.dower(a)python.org> wrote: > From my perspective, we can’t keep an OpenSSL-like API and use Windows > platform libraries (we *could* do a requests-like API easily enough, but > even urllib3 is painfully low-level). > > Support for Windows SChannel and Apple SecureTransport is part of the TLS module. IDK how far along that work is (whether it'll be ready for 3.7 beta 1)? Or where those volunteering to help with the TLS module can send PRs? https://github.com/python/peps/blob/master/pep-0543.rst https://www.python.org/dev/peps/pep-0543/ http://markmail.org/search/?q=list%3Aorg.python+PEP+543+TLS https://www.python.org/dev/peps/pep-0543/#interfaces > > > We have to continue shipping our own copy of OpenSSL on Windows. Nothing > to negotiate here except whether OpenSSL releases should trigger a Python > release, and I think that decision can stay with the RM. > > > > Good luck solving macOS :o) > > > > Cheers, > > Steve > > > > Top-posted from my Windows phone > > > > *From: *Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> > *Sent: *Tuesday, January 16, 2018 17:45 > *To: *Matt Billenstein <matt(a)vazor.com> > *Cc: *Christian Heimes <christian(a)python.org>; python-dev(a)python.org > *Subject: *Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / > LibreSSL >=2.5.3 > > > > Matt Billenstein writes: > > > > > In my mind it becomes easier to bundle deps in a binary installer > > > across the board (Linux, OSX, Windows) rather than rely on whatever > > > version the operating system provides. > > > > Thing is, as Christian points out, TLS is a rapidly moving target. > > Every Mac OS or iOS update seems to link to a dozen CVEs for TLS > > support. We can go there if we have to, but it's often hard to go > > back when vendor support catches up to something reasonable. I think > > this is something for Ned and Christian and Steve to negotiate, since > > they're the ones who are most aware of the tradeoffs and bear the > > costs. > > > > > > > > _______________________________________________ > > Python-Dev mailing list > > Python-Dev(a)python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > steve.dower%40python.org > > >

3 3

Re: [Python-Dev] Best Python API for exposing posix_spawn
by Pablo Galindo Salgado Jan. 16, 2018

Jan. 16, 2018

I think I really like Antoine's suggestion so I'm going to finish implementing it that way. I think this keeps the API simple, does not bring in the os module new dependencies, keeps the C implementation clean and is consistent with the rest of the posix module. I will post an update when is ready. Thank you everyone for sharing your view and advice!

1 1

Thoughts on "contexts". PEPs 550, 555, 567, 568
by Koos Zevenhoven Jan. 14, 2018

Jan. 14, 2018

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

3 7

Deprecate PEP 370 Per user site-packages directory?
by Christian Heimes Jan. 14, 2018

Jan. 14, 2018

Hi, PEP 370 [1] was my first PEP that got accepted. I created it exactly one decade and two days ago for Python 2.6 and 3.0. Back then we didn't have virtual environment support in Python. Ian Bicking had just started to create the virtualenv project a couple of months earlier. Fast forward 10 years... Nowadays Python has venv in the standard library. The user-specific site-packages directory is no longer that useful. I would even say it's causing more trouble than it's worth. For example it's common for system script to use "#!/usr/bin/python3" shebang without -s or -I option. I propose to deprecate the feature and remove it in Python 4.0. Regards, Christian [1] https://www.python.org/dev/peps/pep-0370/

13 21

Why wont duplicate methods be flagged as error (syntax or anything suitable error)
by joannah nanjekye Jan. 14, 2018

Jan. 14, 2018

Hello, Apparently when you implement two methods with the same name: def sub(x, y): print(x -y) def sub(x, y): print(x -y) Even with type hints. def sub(x: int, y:int) -> int: return x - y def sub(x: float, y:float) -> float: return 8 If you are from another background, you will expect the syntax with type hints to act as though method overloading but instead last implementation is always called. If this is the required behavior,then just flag any duplicate method implementations as syntax errors. Is this sort of method name duplication important in any cases? Not aimed at criticism, just to understand. -- Joannah Nanjekye +256776468213 F : Nanjekye Captain Joannah S : joannah.nanjekye T : @Captain_Joannah SO : joannah *"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis*

4 3

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?
by Bruno Maximilian Voß Jan. 13, 2018

Jan. 13, 2018

Hi all, I'm a user who decided to read the mailing list and respond to argue against and maybe stop things I don't think will help users as much as you think.I think deprecating user site-packages is such a change. That venvs exist doesn't mean most or even many people use them, even though I'm sure you and everyone you know does. I couldn't find usage statistics on short notice, do you have any? As far as I understand it site-packages is the default location for all packages that are installed and as long as the packages that are installed aren't causing a conflict, there is no problem. I've never had a problem in six years of using python. So I'd really like a more detailed break down of the troubles the existence of site packages causes and of the up- and downsides removing it would bring, before anything is decided. Another point I'd like to raise is that even though it's a good idea to isolate programs with venvs for stability, development and sometimes maybe security, idk, the idea of having a shared pool of packages has benefits too, namely code reuse and their availability, for example when you're offline. Also I don't really know why you would think it's necessary to force every user into venvs. The applications and users that do need their environments are free to use one after all. Regards, Max

1 0

PEP 567 pre v3
by Yury Selivanov Jan. 12, 2018

Jan. 12, 2018

Hi, Thanks to everybody participating in the PEP 567 discussion! I want to summarize a few topics to make sure that we are all on the same page (and maybe provoke more discussion). 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. 2. Context.__contains__, Context.__getitem__ and ContexVar.default So if we keep the current PEP 567 behaviour w.r.t. defaults, ContextVar.get() might return a different value from Context.get(): v = ContextVar('v', default=42) ctx = contextvars.copy_context() ctx.get(v) # returns None v.get() # returns 42 v in ctx # returns False I think this discrepancy is OK. Context is a mapping-like object and it reflects the contents of the underlying _ContextData mapping object. ContextVar.default is meant to be used only by ContextVar.get(). Context objects should not use it. Maybe we can rename ContextVar.get() to ContextVar.lookup()? This would help to avoid potential confusion between Context.get() and ContextVar.get(). 3. Proposal: Context.get() and __getitem__() should always return up to date values. The issue with the current PEP 567 design is that PyThreadState points to a _ContextData object, and not to the current Context. The following code illustrates how this manifests in Python code: v = ContextVar('v') def foo(): v.set(42) print(v.get(), ctx.get(v, 'missing')) ctx = Context() ctx.run(foo) The above code will print "42 missing", because 'ctx' points to an outdated _ContextData. This is easily fixable if we make PyThreadState to point to the current Context object (instead of it pointing to a _ContextData). This change will also make "contextvars.copy_context()" easier to understand--it will actually return a copy of the current context that the thread state points to. Adding a private Context._in_use attribute would allow us to make sure that Context.run() cannot be simultaneously called in two OS threads. As Nathaniel points out, this will also simplify cache implementation in ContextVar.get(). So let's do this. 4. Add Context.copy(). I was actually going to suggest this addition myself. With the current PEP 567 design, Context.copy() can be implemented with "ctx.run(contextvars.copy_context)", but this is very cumbersome. An example of when a copy() method could be useful is capturing the current context and executing a few functions with it using ThreadPoolExecutor.map(). Copying the Context object will ensure that every mapped function executes in its own context copy (i.e. isolated). So I'm +1 for this one. 5. PEP language. I agree that PEP is vague about some details and is incorrect in some places (like calling Context objects immutable, which is not really true, because .run() can modify them). I'll fix the language in v3 once I'm back home. Yury

8 21