Re: [Python-Dev] PEP 539 (second round): A new C API for Thread-Local Storage in CPython

[Masayuki YAMAMOTO]

2017-08-31 19:40 GMT+09:00 Erik Bray :

> [...]
> the changes is nice.   I just have a few minor changes to suggest
> (typos and such) that I'll make in a pull request.
>
Steve Dower points out which avoids the use of bool in header declarations
[*]. I'd change PyThread_tss_is_created declaration's bool to replace with
int.

Erik, would you change the specification at present PEP PR? (I comment also
the PR)

Thanks,
Masayuki

[*]: https://github.com/python/cpython/pull/1362#pullrequestreview-59884901
___
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] HTTPS on bugs.python.org

[Victor Stinner]

Hi,

When I go to http://bugs.python.org/ Firefox warns me that the form on
the left to login (user, password) sends data in clear text (HTTP).

Ok, I switch manually to HTTPS: add "s" in "http://"; of the URL.

I log in.

I go to an issue using HTTPS like https://bugs.python.org/issue31250

I modify an issue using the form and click on [Submit Changes] (or
just press Enter): I'm back to HTTP. Truncated URL:

http://bugs.python.org/issue31250?@ok_message=msg%20301099%20created%...

Hum, again I switch manually to HTTPS by modifying the URL:

https://bugs.python.org/issue31250?@ok_message=msg%20301099%20created%...

I click on the "clear this message" link: oops, I'm back to the HTTP world...

http://bugs.python.org/issue31250

So, would it be possible to enforce HTTPS on the bug tracker?

The best would be to always generate HTTPS urls and *maybe* redirect
HTTP to HTTPS.

Sorry, I don't know what are the best practices. For example, should
we use HTTPS only cookies?

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] HTTPS on bugs.python.org

[INADA Naoki]

FYI, there is issue report for it.
http://psf.upfronthosting.co.za/roundup/meta/issue463
INADA Naoki  


On Fri, Sep 1, 2017 at 9:57 PM, Victor Stinner  wrote:
> Hi,
>
> When I go to http://bugs.python.org/ Firefox warns me that the form on
> the left to login (user, password) sends data in clear text (HTTP).
>
> Ok, I switch manually to HTTPS: add "s" in "http://"; of the URL.
>
> I log in.
>
> I go to an issue using HTTPS like https://bugs.python.org/issue31250
>
> I modify an issue using the form and click on [Submit Changes] (or
> just press Enter): I'm back to HTTP. Truncated URL:
>
> http://bugs.python.org/issue31250?@ok_message=msg%20301099%20created%...
>
> Hum, again I switch manually to HTTPS by modifying the URL:
>
> https://bugs.python.org/issue31250?@ok_message=msg%20301099%20created%...
>
> I click on the "clear this message" link: oops, I'm back to the HTTP world...
>
> http://bugs.python.org/issue31250
>
> So, would it be possible to enforce HTTPS on the bug tracker?
>
> The best would be to always generate HTTPS urls and *maybe* redirect
> HTTP to HTTPS.
>
> Sorry, I don't know what are the best practices. For example, should
> we use HTTPS only cookies?
>
> 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/songofacandy%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] HTTPS on bugs.python.org

[Antoine Pitrou]

On Fri, 1 Sep 2017 22:15:29 +0900
INADA Naoki  wrote:
> FYI, there is issue report for it.
> http://psf.upfronthosting.co.za/roundup/meta/issue463
> INADA Naoki  

That issue is about making the tracker HTTPS-only, but fixing
internal links to point to the HTTPS site would already go a long way,
even without switching off HTTP access.

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] HTTPS on bugs.python.org

[Antoine Pitrou]

And by the way the problem goes away if you use the "HTTPS Everywhere"
plugin for Firefox.

Regards

Antoine.


On Fri, 1 Sep 2017 15:29:58 +0200
Antoine Pitrou  wrote:
> On Fri, 1 Sep 2017 22:15:29 +0900
> INADA Naoki  wrote:
> > FYI, there is issue report for it.
> > http://psf.upfronthosting.co.za/roundup/meta/issue463
> > INADA Naoki
> 
> That issue is about making the tracker HTTPS-only, but fixing
> internal links to point to the HTTPS site would already go a long way,
> even without switching off HTTP access.
> 
> 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] HTTPS on bugs.python.org

[Mariatta Wijaya]

I also would like the links from bug tracker emails be in https instead of
http.



On Sep 1, 2017 6:31 AM, "Antoine Pitrou"  wrote:

> On Fri, 1 Sep 2017 22:15:29 +0900
> INADA Naoki  wrote:
> > FYI, there is issue report for it.
> > http://psf.upfronthosting.co.za/roundup/meta/issue463
> > INADA Naoki  
>
> That issue is about making the tracker HTTPS-only, but fixing
> internal links to point to the HTTPS site would already go a long way,
> even without switching off HTTP access.
>
> 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/
> mariatta.wijaya%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] HTTPS on bugs.python.org

[Wes Turner]

## HTTP STS
- Wikipedia: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
- Docs:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

- https://https.cio.gov/hsts/

## letsencrypt
"A free, automated, and open certificate authority."

- Wikipedia: https://en.wikipedia.org/wiki/Let%27s_Encrypt
- Homepage: https://letsencrypt.org/
- Src: https://github.com/letsencrypt
- Docs: https://letsencrypt.readthedocs.io/en/latest/
- Docs:
https://letsencrypt.readthedocs.io/en/latest/using.html#getting-certificates-and-choosing-plugins
- Docs:
https://letsencrypt.readthedocs.io/en/latest/using.html#third-party-plugins

### ACME Protocol
- Wikipedia:
https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment




On Fri, Sep 1, 2017 at 8:35 AM, Mariatta Wijaya 
wrote:

> I also would like the links from bug tracker emails be in https instead of
> http.
>
>
>
> On Sep 1, 2017 6:31 AM, "Antoine Pitrou"  wrote:
>
>> On Fri, 1 Sep 2017 22:15:29 +0900
>> INADA Naoki  wrote:
>> > FYI, there is issue report for it.
>> > http://psf.upfronthosting.co.za/roundup/meta/issue463
>> > INADA Naoki  
>>
>> That issue is about making the tracker HTTPS-only, but fixing
>> internal links to point to the HTTPS site would already go a long way,
>> even without switching off HTTP access.
>>
>> 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/mariatta.
>> wijaya%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/
> wes.turner%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] HTTPS on bugs.python.org

[Terry Reedy]

On 9/1/2017 9:36 AM, Antoine Pitrou wrote:


And by the way the problem goes away if you use the "HTTPS Everywhere"
plugin for Firefox.


Firefox has both 'extension' and 'plugin' add-ons.  "HTTPS Everywhere" 
is found under 'extensions'.  Works great.

On Fri, 1 Sep 2017 15:29:58 +0200
Antoine Pitrou  wrote:

On Fri, 1 Sep 2017 22:15:29 +0900
INADA Naoki  wrote:

FYI, there is issue report for it.
http://psf.upfronthosting.co.za/roundup/meta/issue463
INADA Naoki  


That issue is about making the tracker HTTPS-only, but fixing
internal links to point to the HTTPS site would already go a long way,
even without switching off HTTP access.


--
Terry Jan Reedy

___
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] HTTPS on bugs.python.org

[Wes Turner]

Here's e.g. Jupyter Notebook w/ letsencrypt in a Makefile:

https://github.com/jupyter/docker-stacks/blob/master/examples/make-deploy/letsencrypt.makefile

... https://github.com/jupyter/docker-stacks

On Fri, Sep 1, 2017 at 9:08 AM, Wes Turner  wrote:

>
> ## HTTP STS
> - Wikipedia: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
> - Docs: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/
> Strict-Transport-Security
>
> - https://https.cio.gov/hsts/
>
> ## letsencrypt
> "A free, automated, and open certificate authority."
>
> - Wikipedia: https://en.wikipedia.org/wiki/Let%27s_Encrypt
> - Homepage: https://letsencrypt.org/
> - Src: https://github.com/letsencrypt
> - Docs: https://letsencrypt.readthedocs.io/en/latest/
> - Docs: https://letsencrypt.readthedocs.io/en/latest/using.html#getting-
> certificates-and-choosing-plugins
> - Docs: https://letsencrypt.readthedocs.io/en/latest/
> using.html#third-party-plugins
>
> ### ACME Protocol
> - Wikipedia: https://en.wikipedia.org/wiki/Automated_
> Certificate_Management_Environment
>
>
>
>
> On Fri, Sep 1, 2017 at 8:35 AM, Mariatta Wijaya  > wrote:
>
>> I also would like the links from bug tracker emails be in https instead
>> of http.
>>
>>
>>
>> On Sep 1, 2017 6:31 AM, "Antoine Pitrou"  wrote:
>>
>>> On Fri, 1 Sep 2017 22:15:29 +0900
>>> INADA Naoki  wrote:
>>> > FYI, there is issue report for it.
>>> > http://psf.upfronthosting.co.za/roundup/meta/issue463
>>> > INADA Naoki  
>>>
>>> That issue is about making the tracker HTTPS-only, but fixing
>>> internal links to point to the HTTPS site would already go a long way,
>>> even without switching off HTTP access.
>>>
>>> Regards
>>>
>>> Antoine.
>>>
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: https://mail.python.org/mailma
>>> n/options/python-dev/mariatta.wijaya%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/wes.
>> turner%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] HTTPS on bugs.python.org

[Victor Stinner]

2017-09-01 15:36 GMT+02:00 Antoine Pitrou :
> And by the way the problem goes away if you use the "HTTPS Everywhere"
> plugin for Firefox.

I do have "HTTPS Everywhere" Firefox plugin version 2017.8.31 (so it
seems very recent), but it displayed as "obsolete" ("obsolète" in
french). I'm using Firefox 55 on Fedora 26. It seems like the plugin
has to be updated to use the new WebExtensions API.

https://www.eff.org/https-everywhere

https://github.com/EFForg/https-everywhere/issues/7389

"No. HTTPS Everywhere has already been migrated to WebExtensions.
We're unable to switch HTTPSE on Firefox over to WebExtensions until
Tor Browser rebases to FF 52 ESR, as I already stated: #7389
(comment)"

"Currently the main blocker to WebExtensions deployment on Firefox is
a secure signing mechanism for the self-hosted version. See #9958
(comment)"

In short, it doesn't work :-)

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] HTTPS on bugs.python.org

[Antoine Pitrou]

Le 01/09/2017 à 16:32, Victor Stinner a écrit :
> 
> In short, it doesn't work :-)

I'm using Firefox 55 on Ubuntu 16.04 and it works here.  You may be
misunderstading what happens :-)

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] HTTPS on bugs.python.org

[Victor Stinner]

2017-09-01 16:34 GMT+02:00 Antoine Pitrou :
> I'm using Firefox 55 on Ubuntu 16.04 and it works here.  You may be
> misunderstading what happens :-)

Maybe I misunderstood you when you wrote:

> And by the way the problem goes away if you use the "HTTPS Everywhere"
> plugin for Firefox.

Try for example this page:

https://bugs.python.org/issue31234?@ok_message=msg%20301118%20created

For me, the "clear this message" link is HTTP, not HTTPS:

http://bugs.python.org/issue31234

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] HTTPS on bugs.python.org

[Antoine Pitrou]

On Fri, 1 Sep 2017 17:03:59 +0200
Victor Stinner  wrote:
> 
> > And by the way the problem goes away if you use the "HTTPS Everywhere"
> > plugin for Firefox.  
> 
> Try for example this page:
> 
> https://bugs.python.org/issue31234?@ok_message=msg%20301118%20created
> 
> For me, the "clear this message" link is HTTP, not HTTPS:
> 
> http://bugs.python.org/issue31234

Sure, but if you click on this link, it will go to the HTTPS version
nevertheless.

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] HTTPS on bugs.python.org

[Oleg Broytman]

On Fri, Sep 01, 2017 at 05:27:59PM +0200, Antoine Pitrou  
wrote:
> On Fri, 1 Sep 2017 17:03:59 +0200
> Victor Stinner  wrote:
> > 
> > > And by the way the problem goes away if you use the "HTTPS Everywhere"
> > > plugin for Firefox.  
> > 
> > Try for example this page:
> > 
> > https://bugs.python.org/issue31234?@ok_message=msg%20301118%20created
> > 
> > For me, the "clear this message" link is HTTP, not HTTPS:
> > 
> > http://bugs.python.org/issue31234
> 
> Sure, but if you click on this link, it will go to the HTTPS version
> nevertheless.

   It doesn't for me. :-( FFox 55.0.1, HTTPS Everywhere 2017.8.15.

> Regards
> 
> Antoine.

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2017-08-25 - 2017-09-01)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6166 (+17)
  closed 36910 (+30)
  total  43076 (+47)

Open issues with patches: 2339 


Issues opened (35)
==

#30581: os.cpu_count() returns wrong number of processors on system wi
http://bugs.python.org/issue30581  reopened by haypo

#30776: regrtest: change -R/--huntrleaks rule to decide if a test leak
http://bugs.python.org/issue30776  reopened by pitrou

#31250: test_asyncio leaks dangling threads
http://bugs.python.org/issue31250  reopened by haypo

#31281: fileinput inplace does not work with pathlib.Path
http://bugs.python.org/issue31281  opened by zmwangx

#31282: C APIs called without GIL in PyOS_Readline
http://bugs.python.org/issue31282  opened by xiang.zhang

#31284: IDLE: Make GUI test teardown less fragile
http://bugs.python.org/issue31284  opened by csabella

#31285: a SystemError and an assertion failure in warnings.warn_explic
http://bugs.python.org/issue31285  opened by Oren Milman

#31288: IDLE tests: don't modify tkinter.messagebox.
http://bugs.python.org/issue31288  opened by terry.reedy

#31289: File paths in exception traceback resolve symlinks
http://bugs.python.org/issue31289  opened by Paul Pinterits

#31290: segfault on missing library symbol
http://bugs.python.org/issue31290  opened by immortalplants

#31292: `python setup.py check --restructuredtext` fails when a includ
http://bugs.python.org/issue31292  opened by flying sheep

#31293: crashes in multiply_float_timedelta() and in truedivide_timede
http://bugs.python.org/issue31293  opened by Oren Milman

#31294: ZeroMQSocketListener and ZeroMQSocketHandler examples in the L
http://bugs.python.org/issue31294  opened by pablogsal

#31296: support pty.fork and os.forkpty actions in posix subprocess mo
http://bugs.python.org/issue31296  opened by gregory.p.smith

#31297: Unpickleable ModuleImportError in unittest patch not backporte
http://bugs.python.org/issue31297  opened by Rachel Tobin

#31298: Error when calling numpy.astype
http://bugs.python.org/issue31298  opened by droth

#31299: Add "ignore_modules" option to TracebackException.format()
http://bugs.python.org/issue31299  opened by ncoghlan

#31301: Python 2.7 SIGSEGV
http://bugs.python.org/issue31301  opened by cody

#31302: smtplib on linux fails to log in correctly
http://bugs.python.org/issue31302  opened by murphdasurf

#31304: Update doc for starmap_async error_back kwarg
http://bugs.python.org/issue31304  opened by tamas

#31305: 'pydoc -w import' report "no Python documentation found for 'i
http://bugs.python.org/issue31305  opened by limuyuan

#31306: IDLE, configdialog, General tab: validate user entries
http://bugs.python.org/issue31306  opened by terry.reedy

#31307: ConfigParser.read silently fails if filenames argument is a by
http://bugs.python.org/issue31307  opened by vxgmichel

#31308: forkserver process isn't re-launched if it died
http://bugs.python.org/issue31308  opened by pitrou

#31310: semaphore tracker isn't protected against crashes
http://bugs.python.org/issue31310  opened by pitrou

#31311: a SystemError and a crash in PyCData_setstate() when __dict__ 
http://bugs.python.org/issue31311  opened by Oren Milman

#31313: Feature Add support of os.chflags() on Linux platform
http://bugs.python.org/issue31313  opened by socketpair

#31314: email throws exception with oversized header input
http://bugs.python.org/issue31314  opened by doko

#31315: assertion failure in imp.create_dynamic(), when spec.name is n
http://bugs.python.org/issue31315  opened by Oren Milman

#31319: Rename idlelib to just idle
http://bugs.python.org/issue31319  opened by rhettinger

#31320: test_ssl logs a traceback
http://bugs.python.org/issue31320  opened by haypo

#31321: traceback.clear_frames() doesn't clear *all* frames
http://bugs.python.org/issue31321  opened by haypo

#31323: test_ssl: reference cycle between ThreadedEchoServer and its C
http://bugs.python.org/issue31323  opened by haypo

#31324: support._match_test() used by test.bisect is very inefficient
http://bugs.python.org/issue31324  opened by haypo

#31325: req_rate is a namedtuple type rather than instance
http://bugs.python.org/issue31325  opened by gvx



Most recent 15 issues with no replies (15)
==

#31325: req_rate is a namedtuple type rather than instance
http://bugs.python.org/issue31325

#31323: test_ssl: reference cycle between ThreadedEchoServer and its C
http://bugs.python.org/issue31323

#31314: email throws exception with oversized header input
http://bugs.python.org/issue31314

#31310: semaphore tracker isn't protected against crashes
http://bugs.python.org/issue31310

#31308: forkserver process isn't re-launched if it died
http://bugs.python.org/issue31308

#31307: ConfigParser.read silently fails if filenames 

Re: [Python-Dev] HTTPS on bugs.python.org

[INADA Naoki]

You're right.  It should be bpo configuration issue.

https://hg.python.org/tracker/roundup/file/bugs.python.org/roundup/cgi/client.py#l303
https://hg.python.org/tracker/python-dev/file/tip/config.ini.template#l118

I can't real config file used for bpo.
But maybe, tracker.web is 'http://bugs.python.org/' instead of
'https://bugs.python.org/'
INADA Naoki  


On Fri, Sep 1, 2017 at 10:29 PM, Antoine Pitrou  wrote:
> On Fri, 1 Sep 2017 22:15:29 +0900
> INADA Naoki  wrote:
>> FYI, there is issue report for it.
>> http://psf.upfronthosting.co.za/roundup/meta/issue463
>> INADA Naoki  
>
> That issue is about making the tracker HTTPS-only, but fixing
> internal links to point to the HTTPS site would already go a long way,
> even without switching off HTTP access.
>
> 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/songofacandy%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] HTTPS on bugs.python.org

[Antoine Pitrou]

On Fri, 1 Sep 2017 17:31:00 +0200
Oleg Broytman  wrote:

> On Fri, Sep 01, 2017 at 05:27:59PM +0200, Antoine Pitrou 
>  wrote:
> > On Fri, 1 Sep 2017 17:03:59 +0200
> > Victor Stinner  wrote:  
> > >   
> > > > And by the way the problem goes away if you use the "HTTPS Everywhere"
> > > > plugin for Firefox.
> > > 
> > > Try for example this page:
> > > 
> > > https://bugs.python.org/issue31234?@ok_message=msg%20301118%20created
> > > 
> > > For me, the "clear this message" link is HTTP, not HTTPS:
> > > 
> > > http://bugs.python.org/issue31234  
> > 
> > Sure, but if you click on this link, it will go to the HTTPS version
> > nevertheless.  
> 
>It doesn't for me. :-( FFox 55.0.1, HTTPS Everywhere 2017.8.15.

That's surprising.  It's definitely part of the standard rules (enabled
by default):
https://www.eff.org/https-everywhere/atlas/domains/python.org.html

Perhaps you tweaked your configuration?

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] HTTPS on bugs.python.org

[Victor Stinner]

2017-09-01 19:06 GMT+02:00 Antoine Pitrou :
> That's surprising.  It's definitely part of the standard rules (enabled
> by default):
> https://www.eff.org/https-everywhere/atlas/domains/python.org.html

Maybe the plugin is also broken, as my setup. Maybe it's related to
the recent "multiprocess" major change of Firefox?

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] HTTPS on bugs.python.org

[Oleg Broytman]

On Fri, Sep 01, 2017 at 07:06:57PM +0200, Antoine Pitrou  
wrote:
> On Fri, 1 Sep 2017 17:31:00 +0200
> Oleg Broytman  wrote:
> 
> > On Fri, Sep 01, 2017 at 05:27:59PM +0200, Antoine Pitrou 
> >  wrote:
> > > On Fri, 1 Sep 2017 17:03:59 +0200
> > > Victor Stinner  wrote:  
> > > >   
> > > > > And by the way the problem goes away if you use the "HTTPS Everywhere"
> > > > > plugin for Firefox.
> > > > 
> > > > Try for example this page:
> > > > 
> > > > https://bugs.python.org/issue31234?@ok_message=msg%20301118%20created
> > > > 
> > > > For me, the "clear this message" link is HTTP, not HTTPS:
> > > > 
> > > > http://bugs.python.org/issue31234  
> > > 
> > > Sure, but if you click on this link, it will go to the HTTPS version
> > > nevertheless.  
> > 
> >It doesn't for me. :-( FFox 55.0.1, HTTPS Everywhere 2017.8.15.
> 
> That's surprising.  It's definitely part of the standard rules (enabled
> by default):
> https://www.eff.org/https-everywhere/atlas/domains/python.org.html
> 
> Perhaps you tweaked your configuration?

   Not for HTTPS Everywhere.

> Regards
> 
> Antoine.

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] HTTPS on bugs.python.org

[Terry Reedy]

On 9/1/2017 11:31 AM, Oleg Broytman wrote:

On Fri, Sep 01, 2017 at 05:27:59PM +0200, Antoine Pitrou  
wrote:

On Fri, 1 Sep 2017 17:03:59 +0200
Victor Stinner  wrote:



And by the way the problem goes away if you use the "HTTPS Everywhere"
plugin for Firefox.


Try for example this page:

https://bugs.python.org/issue31234?@ok_message=msg%20301118%20created

For me, the "clear this message" link is HTTP, not HTTPS:

http://bugs.python.org/issue31234


Sure, but if you click on this link, it will go to the HTTPS version
nevertheless.


It doesn't for me. :-( FFox 55.0.1, HTTPS Everywhere 2017.8.15.


Is fetches https: for me: 55.0.3, 2017.8.31, updated yesterday.


Regards

Antoine.


Oleg.




--
Terry Jan Reedy

___
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] HTTPS on bugs.python.org

[Oleg Broytman]

On Fri, Sep 01, 2017 at 02:55:40PM -0400, Terry Reedy  wrote:
> On 9/1/2017 11:31 AM, Oleg Broytman wrote:
> >On Fri, Sep 01, 2017 at 05:27:59PM +0200, Antoine Pitrou 
> > wrote:
> >>On Fri, 1 Sep 2017 17:03:59 +0200
> >>Victor Stinner  wrote:
> >>>
> And by the way the problem goes away if you use the "HTTPS Everywhere"
> plugin for Firefox.
> >>>
> >>>Try for example this page:
> >>>
> >>>https://bugs.python.org/issue31234?@ok_message=msg%20301118%20created
> >>>
> >>>For me, the "clear this message" link is HTTP, not HTTPS:
> >>>
> >>>http://bugs.python.org/issue31234
> >>
> >>Sure, but if you click on this link, it will go to the HTTPS version
> >>nevertheless.
> >
> >It doesn't for me. :-( FFox 55.0.1, HTTPS Everywhere 2017.8.15.
> 
> Is fetches https: for me: 55.0.3, 2017.8.31, updated yesterday.

   I upgraded Fox and the extension. http://bugs.python.org now is
redirected to https://
   Thanks!

> >>Regards
> >>
> >>Antoine.
> >
> >Oleg.
> -- 
> Terry Jan Reedy

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] Inplace operations for PyLong objects

[Chris Barker]

On Thu, Aug 31, 2017 at 5:12 PM, Antoine Pitrou  wrote:

> I'm skeptical there are some programs out there that are limited by the
> speed of PyLong inplace additions.
>

indeed, but that could be said about any number of operations.

My question is -- how can the interpreter know if it can alter what is
supposed to be an immutable in-place? If it's used only internally to a
function, the it would be safe, but how to know that?

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Inplace operations for PyLong objects

[Jelle Zijlstra]

2017-09-01 13:05 GMT-07:00 Chris Barker :

> On Thu, Aug 31, 2017 at 5:12 PM, Antoine Pitrou 
> wrote:
>
>> I'm skeptical there are some programs out there that are limited by the
>> speed of PyLong inplace additions.
>>
>
> indeed, but that could be said about any number of operations.
>
> My question is -- how can the interpreter know if it can alter what is
> supposed to be an immutable in-place? If it's used only internally to a
> function, the it would be safe, but how to know that?
>
I believe Catalin's implementation checks if the object's refcount is 1. If
that is the case, it is safe to mutate it.

>
> -CHB
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> 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/
> jelle.zijlstra%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] Inplace operations for PyLong objects

[Joe Jevnik via Python-Dev]

Is it true that checking for refcount == 1 is enough? What if a user wrote:

args = (compute_integer(), 5)
# give away args to someone
int.__iadd__(*args)

here `args[0]` still has refcount=1 because only `args` owns this integer.

On Fri, Sep 1, 2017 at 4:19 PM, Jelle Zijlstra 
wrote:

>
>
> 2017-09-01 13:05 GMT-07:00 Chris Barker :
>
>> On Thu, Aug 31, 2017 at 5:12 PM, Antoine Pitrou 
>> wrote:
>>
>>> I'm skeptical there are some programs out there that are limited by the
>>> speed of PyLong inplace additions.
>>>
>>
>> indeed, but that could be said about any number of operations.
>>
>> My question is -- how can the interpreter know if it can alter what is
>> supposed to be an immutable in-place? If it's used only internally to a
>> function, the it would be safe, but how to know that?
>>
> I believe Catalin's implementation checks if the object's refcount is 1.
> If that is the case, it is safe to mutate it.
>
>>
>> -CHB
>>
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R(206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115   (206) 526-6317   main reception
>>
>> chris.bar...@noaa.gov
>>
>> ___
>> 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/jelle.
>> zijlstra%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/
> joe%40quantopian.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] Inplace operations for PyLong objects

[Manciu, Catalin Gabriel]

> My question is -- how can the interpreter know if it can alter what is 
> supposed to be an immutable in-place? If it's used only internally to a 
> function, the it would be safe, but how to know that?

> -CHB

You can just check the reference count of your object, it's a member of the
PyObject structure which every CPython object contains: ob_refcnt. This will
indicate if your object is referenced by other Python variables or by Python
containers such as lists, tuples, dicts, sets etc.
___
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] Inplace operations for PyLong objects

[Chris Angelico]

On Sat, Sep 2, 2017 at 6:35 AM, Joe Jevnik via Python-Dev
 wrote:
> Is it true that checking for refcount == 1 is enough? What if a user wrote:
>
> args = (compute_integer(), 5)
> # give away args to someone
> int.__iadd__(*args)
>
> here `args[0]` still has refcount=1 because only `args` owns this integer.

This particular example is safe, because the arguments get passed
individually - so 'args' has one reference, plus there's one more for
the actual function call (what would be 'self' if it were implemented
in Python). There may be other examples that are more dangerous, but
my suspicion is that the nature of += with anything other than a
simple name will defeat the optimization, since the owning collection
will retain a reference until __iadd__ returns.

ChrisA
___
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 550 V5

[Yury Selivanov]

Hi,

Below is the fifth iteration of the PEP.  The summary of changes is
in the "Version History" section, but I'll list them here too:

* Coroutines have no logical context by default (a revert to the V3
 semantics).  Read about the motivation in the
 `Coroutines not leaking context changes by default`_ section.

 The `High-Level Specification`_ section was also updated
 (specifically Generators and Coroutines subsections).

* All APIs have been placed to the ``contextvars`` module, and
 the factory functions were changed to class constructors
 (``ContextVar``, ``ExecutionContext``, and ``LogicalContext``).
 Thanks to Nick for the idea.

* ``ContextVar.lookup()`` got renamed back to ``ContextVar.get()``
 and gained the ``topmost`` and ``default`` keyword arguments.
 Added ``ContextVar.delete()``.

* Fixed ``ContextVar.get()`` cache bug (thanks Nathaniel!).

* New `Rejected Ideas`_,
 `Should "yield from" leak context changes?`_,
 `Alternative Designs for ContextVar API`_,
 `Setting and restoring context variables`_, and
 `Context manager as the interface for modifications`_ sections.

Thanks!


PEP: 550
Title: Execution Context
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov ,
Elvis Pranskevichus 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Aug-2017
Python-Version: 3.7
Post-History: 11-Aug-2017, 15-Aug-2017, 18-Aug-2017, 25-Aug-2017,
  01-Sep-2017


Abstract


This PEP adds a new generic mechanism of ensuring consistent access
to non-local state in the context of out-of-order execution, such
as in Python generators and coroutines.

Thread-local storage, such as ``threading.local()``, is inadequate for
programs that execute concurrently in the same OS thread.  This PEP
proposes a solution to this problem.


Rationale
=

Prior to the advent of asynchronous programming in Python, programs
used OS threads to achieve concurrency.  The need for thread-specific
state was solved by ``threading.local()`` and its C-API equivalent,
``PyThreadState_GetDict()``.

A few examples of where Thread-local storage (TLS) is commonly
relied upon:

* Context managers like decimal contexts, ``numpy.errstate``,
  and ``warnings.catch_warnings``.

* Request-related data, such as security tokens and request
  data in web applications, language context for ``gettext`` etc.

* Profiling, tracing, and logging in large code bases.

Unfortunately, TLS does not work well for programs which execute
concurrently in a single thread.  A Python generator is the simplest
example of a concurrent program.  Consider the following::

def fractions(precision, x, y):
with decimal.localcontext() as ctx:
ctx.prec = precision
yield Decimal(x) / Decimal(y)
yield Decimal(x) / Decimal(y ** 2)

g1 = fractions(precision=2, x=1, y=3)
g2 = fractions(precision=6, x=2, y=3)

items = list(zip(g1, g2))

The intuitively expected value of ``items`` is::

[(Decimal('0.33'), Decimal('0.67')),
 (Decimal('0.11'), Decimal('0.22'))]

Rather surprisingly, the actual result is::

[(Decimal('0.33'), Decimal('0.67')),
 (Decimal('0.11'), Decimal('0.22'))]

This is because implicit Decimal context is stored as a thread-local,
so concurrent iteration of the ``fractions()`` generator would
corrupt the state.  For Decimal, specifically, the only current
workaround is to use explicit context method calls for all arithmetic
operations [28]_.  Arguably, this defeats the usefulness of overloaded
operators and makes even simple formulas hard to read and write.

Coroutines are another class of Python code where TLS unreliability
is a significant issue.

The inadequacy of TLS in asynchronous code has lead to the
proliferation of ad-hoc solutions, which are limited in scope and
do not support all required use cases.

The current status quo is that any library (including the standard
library), which relies on TLS, is likely to be broken when used in
asynchronous code or with generators (see [3]_ as an example issue.)

Some languages, that support coroutines or generators, recommend
passing the context manually as an argument to every function, see
[1]_ for an example.  This approach, however, has limited use for
Python, where there is a large ecosystem that was built to work with
a TLS-like context.  Furthermore, libraries like ``decimal`` or
``numpy`` rely on context implicitly in overloaded operator
implementations.

The .NET runtime, which has support for async/await, has a generic
solution for this problem, called ``ExecutionContext`` (see [2]_).


Goals
=

The goal of this PEP is to provide a more reliable
``threading.local()`` alternative, which:

* provides the mechanism and the API to fix non-local state issues
  with coroutines and generators;

* implements TLS-like semantics for synchronous code, so that
  users like ``decimal`` and ``numpy`` can switch to the new
  mechanism with minimal risk of brea

Re: [Python-Dev] Inplace operations for PyLong objects

[Greg Ewing]

Chris Angelico wrote:

This particular example is safe, because the arguments get passed
individually - so 'args' has one reference, plus there's one more for
the actual function call


However, that's also true when you use the += operator,
so if the optimisation is to trigger at all in any useful
case, the refcount threshold needs to be set higher than
1.

Some experiments I did suggest that if you set it high
enough for x += y to trigger it, then it will also be
triggered in Joe's case.

BTW, isn't there already a similar optimisation somewhere
for concatenating strings? Does it still exist? How does
it avoid this issue?

--
Greg
___
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] Inplace operations for PyLong objects

[Joe Jevnik via Python-Dev]

The string concat optimization happens in the interpreter dispatch for
INPLACE_ADD

On Fri, Sep 1, 2017 at 9:10 PM, Greg Ewing 
wrote:

> Chris Angelico wrote:
>
>> This particular example is safe, because the arguments get passed
>> individually - so 'args' has one reference, plus there's one more for
>> the actual function call
>>
>
> However, that's also true when you use the += operator,
> so if the optimisation is to trigger at all in any useful
> case, the refcount threshold needs to be set higher than
> 1.
>
> Some experiments I did suggest that if you set it high
> enough for x += y to trigger it, then it will also be
> triggered in Joe's case.
>
> BTW, isn't there already a similar optimisation somewhere
> for concatenating strings? Does it still exist? How does
> it avoid this issue?
>
> --
> Greg
>
> ___
> 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/joe%
> 40quantopian.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 550 V5

[Eric Snow]

Nice working staying on top of this!  Keeping up with discussion is
arguably much harder than actually writing the PEP. :)  I have some
comments in-line below.

-eric


On Fri, Sep 1, 2017 at 5:02 PM, Yury Selivanov  wrote:
> [snip]
>
> Abstract
> 
>
> [snip]
>
> Rationale
> =
>
> [snip]
>
> Goals
> =
>

I still think that the Abstract, Rationale, and Goals sections should
be clear that a major component of this proposal is lookup via chained
contexts.  Without such clarity it may not be apparent that chained
lookup is not strictly necessary to achieve the stated goals (i.e. an
async-compatible TLS replacement).  This matters because the chaining
introduces extra non-trivial complexity.

> The goal of this PEP is to provide a more reliable
> ``threading.local()`` alternative, which:
>
> [snip]
>
> * implements TLS-like semantics for synchronous code, so that
>   users like ``decimal`` and ``numpy`` can switch to the new
>   mechanism with minimal risk of breaking backwards compatibility;
>
> [snip]
>
> Replication of threading.local() interface
> --
>
> Choosing the ``threading.local()``-like interface for context
> variables was considered and rejected for the following reasons:
>
> * A survery of the standard library and Django has shown that the
>   vast majority of ``threading.local()`` uses involve a single
>   attribute, which indicates that the namespace approach is not
>   as helpful in the field.
>
> * Using ``__getattr__()`` instead of ``.get()`` for value lookup
>   does not provide any way to specify the depth of the lookup
>   (i.e. search only the top logical context).
>
> * Single-value ``ContextVar`` is easier to reason about in terms
>   of visibility.  Suppose ``ContextVar()`` is a namespace,
>   and the consider the following::
>
> ns = contextvars.ContextVar('ns')
>
> def gen():
> ns.a = 2
> yield
> assert ns.b == 'bar' # ??
>
> def main():
> ns.a = 1
> ns.b = 'foo'
> g = gen()
> next(g)
> # should not see the ns.a modification in gen()
> assert ns.a == 1
> # but should gen() see the ns.b modification made here?
> ns.b = 'bar'
> yield
>
>   The above example demonstrates that reasoning about the visibility
>   of different attributes of the same context var is not trivial.
>
> * Single-value ``ContextVar`` allows straightforward implementation
>   of the lookup cache;
>
> * Single-value ``ContextVar`` interface allows the C-API to be
>   simple and essentially the same as the Python API.
>
> See also the mailing list discussion: [26]_, [27]_.
>
> [snip]

On the one hand the first three sections imply that the PEP is
intended as a replacement for the current TLS mechanism;
threading.local.  On the other hand, the PEP (and related discussion)
clearly says that the feature works differently than threading.local
and hence is not a (drop-in) replacement.  I'd prefer it to be a
drop-in replacement but recognize I'm on the losing side of that
argument. :P  Regardless, having a consistent message in the PEP would
help folks looking to switch over.

Speaking of which, I have plans for the near-to-middle future that
involve making use of the PEP 550 functionality in a way that is quite
similar to decimal.  However, it sounds like the implementation of
such (namespace) contexts under PEP 550 is much more complex than it
is with threading.local (where subclassing made it easy).  It would be
helpful to have some direction in the PEP on how to port to PEP 550
from threading.local.  It would be even better if the PEP included the
addition of a contextlib.Context or contextvars.Context class (or
NamespaceContext or ContextNamespace or ...). :)  However, I recognize
that may be out of scope for this PEP.
___
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 550 V5

[Guido van Rossum]

On Fri, Sep 1, 2017 at 8:29 PM, Eric Snow 
wrote:

> Nice working staying on top of this!  Keeping up with discussion is
> arguably much harder than actually writing the PEP. :)  I have some
> comments in-line below.
>
> -eric
>
>
> On Fri, Sep 1, 2017 at 5:02 PM, Yury Selivanov 
> wrote:
> > [snip]
> >
> > Abstract
> > 
> >
> > [snip]
> >
> > Rationale
> > =
> >
> > [snip]
> >
> > Goals
> > =
> >
>
> I still think that the Abstract, Rationale, and Goals sections should
> be clear that a major component of this proposal is lookup via chained
> contexts.  Without such clarity it may not be apparent that chained
> lookup is not strictly necessary to achieve the stated goals (i.e. an
> async-compatible TLS replacement).  This matters because the chaining
> introduces extra non-trivial complexity.
>

In defense of the PEP, the Goals section clearly states it aims to provide
an alternative, not a plug-in API equivalent.

There's also been some discussion (I hope it wasn't off-list) on how to
implement threading.local on top of this proposal.

That said, I agree it would be nice if the chained lookup was mentioned in
the abstract too, because it's a pretty essential part of the proposal (it
determines the semantics of ContextVar). (OTOH the HAMT implementation is
less essential, there's another way to do the chained lookup.)


> > [snip]
>
> On the one hand the first three sections imply that the PEP is
> intended as a replacement for the current TLS mechanism;
> threading.local.  On the other hand, the PEP (and related discussion)
> clearly says that the feature works differently than threading.local
> and hence is not a (drop-in) replacement.  I'd prefer it to be a
> drop-in replacement but recognize I'm on the losing side of that
> argument. :P  Regardless, having a consistent message in the PEP would
> help folks looking to switch over.
>
> Speaking of which, I have plans for the near-to-middle future that
> involve making use of the PEP 550 functionality in a way that is quite
> similar to decimal.  However, it sounds like the implementation of
> such (namespace) contexts under PEP 550 is much more complex than it
> is with threading.local (where subclassing made it easy).  It would be
> helpful to have some direction in the PEP on how to port to PEP 550
> from threading.local.  It would be even better if the PEP included the
> addition of a contextlib.Context or contextvars.Context class (or
> NamespaceContext or ContextNamespace or ...). :)  However, I recognize
> that may be out of scope for this PEP.
>

If you look at what decimal does, it only ever stores a single value in its
threading.local instance -- __decimal_context__. (And part of the reason is
that the C version has to work with a different API for TLS, which really
does only store a single value per key.)

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