Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog
A welcome article. One correction should be made, I believe: the area of code point space used for the smuggling of bytes under PEP-383 is not a "Unicode Private Use Area", but a portion of the trailing surrogate range. This is a code violation, which I imagine is why "surrogateescape" is an error handler, not a codec. http://www.unicode.org/faq/private_use.html I believe the private use area was considered and rejected for PEP-383. In an implementation of the type unicode based on UTF-16 (Jython), lone surrogates preclude a naive use of the platform string library. This is on my mind at the moment as I'm working several bugs in Jython's unicode type, and can see why it has been too difficult. Jeff On 10/09/2014 08:17, Nick Coghlan wrote: Since it may come in handy when discussing "Why was Python 3 necessary?" with folks, I wanted to point out that my article on the transition to multilingual programming has now been reposted on the Red Hat developer blog: http://developerblog.redhat.com/2014/09/09/transition-to-multilingual-programming-python/ I wouldn't normally bring the Red Hat brand into an upstream discussion like that, but this myth that Python 3 is killing the language, and that Python 2 could have continued as a viable development platform indefinitely "if only Guido and the core development team hadn't decided to go ahead and create Python 3", is just plain wrong, and it really needs to die. I'm hoping that borrowing a bit of Red Hat's enterprise credibility will finally get people to understand that we really do have some idea what we're doing, which is why most of our redistributors and many of our key users are helping to push the migration forward, while we also continue to support existing Python 2 users :) Cheers, Nick. ___ 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] Proposed schedule for 3.4.2
On Mon, 8 Sep 2014 10:44:51 -0700 Alex Gaynor wrote: > *Shifts uncomfortably* it looks like presently there's not a good way to > change anything about the SSL configuration for urllib.request.urlopen. It > does not take a `context` argument, as the http.client API does: > https://docs.python.org/3/library/urllib.request.html#module-urllib.request > and instead takes the cafile, capath, cadefault args. The reason it doesn't take a context argument is that SSL contexts are hard to understand and configure for the average urlopen() user (why should people know about ssl module specifics to open an HTTPS URL?). http.client is more low-level and therefore more amenable to such powerful knobs. 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] Proposed schedule for 3.4.2
On Tue, 9 Sep 2014 08:20:52 +1000
Nick Coghlan wrote:
> On 9 Sep 2014 04:00, "Barry Warsaw" wrote:
> > >
> > >This would need to be updated first, once it *did* take such an argument,
> > >this would be accomplished by:
> > >
> > >context = ssl.create_default_context()
> > >context.verify_mode = CERT_OPTIONACERT_NONE
> > >context.verify_hostname = False
> > >urllib.request.urlopen("
> https://something-i-apparently-dont-care-much-about";,
> > >context=context)
> >
> > There's probably an ugly hack possibility that uses unittest.mock.patch.
> ;)
>
> We could actually make it an "official" hack:
>
> import urllib.request
> urllib.request.urlopen = urllib.request._unverified_urlopen
-1. Instead of disabling cert verification for *one* urlopen() call
site, you're doing it for *every* urlopen call site in the program - or,
even worse, for every urlopen that's imported after the monkey-patching
(which makes the final effect potentially dependent on module import
order, and import style). It may affect third-party libraries that have
their own REST calls, or whatever.
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] Multilingual programming article on the Red Hat Developer blog
Jeff Allen writes: > A welcome article. One correction should be made, I believe: the area of > code point space used for the smuggling of bytes under PEP-383 is not a > "Unicode Private Use Area", but a portion of the trailing surrogate > range. Nice catch. Note that the surrogate range was originally part of the Private Use Area, but it was carved out with the adoption of UTF-16 in about 1993. In practice, I doubt that there are any current implementations claiming compatibility with Unicode 1.0 (IIRC, UTF-16 was made mandatory in Unicode 1.1). > This is a code violation, which I imagine is why > "surrogateescape" is an error handler, not a codec. Yes. > I believe the private use area was considered and rejected for PEP-383. > In an implementation of the type unicode based on UTF-16 (Jython), lone > surrogates preclude a naive use of the platform string library. This is > on my mind at the moment as I'm working several bugs in Jython's unicode > type, and can see why it has been too difficult. I've always thought that the "right" way to handle the private use area for "platforms" like Python and Emacs, which may need to use it for their own purposes (such as "undecodable bytes") but want to respect its use by applications, is to create an auxiliary table mapping the private use area to objects describing the characters represented by the private use code points. These objects would have attributes such as external representation for text I/O, glyph (for GUI display), repr (for TTY display), various Unicode properties, etc. ___ 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] Multilingual programming article on the Red Hat Developer blog
On 12/09/2014 04:28, Stephen J. Turnbull wrote: Jeff Allen writes: > A welcome article. One correction should be made, I believe: the area of > code point space used for the smuggling of bytes under PEP-383 is not a > "Unicode Private Use Area", but a portion of the trailing surrogate > range. Nice catch. Note that the surrogate range was originally part of the Private Use Area, but it was carved out with the adoption of UTF-16 in about 1993. In practice, I doubt that there are any current implementations claiming compatibility with Unicode 1.0 (IIRC, UTF-16 was made mandatory in Unicode 1.1). That's a helpful bit of history that explains the uncharacteristic inaccuracy. Most I can do to keep the current position clear in my head. I've always thought that the "right" way to handle the private use area for "platforms" like Python and Emacs, which may need to use it for their own purposes (such as "undecodable bytes") but want to respect its use by applications, is to create an auxiliary table mapping the private use area to objects describing the characters represented by the private use code points. These objects would have attributes such as external representation for text I/O, glyph (for GUI display), repr (for TTY display), various Unicode properties, etc. Simply having a block "for private use" seems to create an unmanaged space for conflict, reminiscent of the "other 128 characters" in bilingual programming. I wondered if the way to respect use by applications might be to make it private to a particular sub-class of str, idly however. Jeff Allen ___ 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
