Re: [Python-Dev] PEP520 and absence of __definition_order__

2016-09-10 Thread Russell Keith-Magee
On Sun, Sep 11, 2016 at 11:05 AM, Nick Coghlan  wrote:

> On 11 September 2016 at 07:26, Guido van Rossum  wrote:
> > On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan 
> wrote:
> >> On 11 September 2016 at 03:08, Guido van Rossum 
> wrote:
> >>> So I'm happy to continue thinking about this, but I expect this is not
> >>> such a big deal as you fear. Anyway, let's see if someone comes up
> >>> with a more convincing argument by beta 2!
> >>
> >> For CPython specifically, I don't have anything more convincing than
> >> Ethan's Enum example (where the way the metaclass works means most of
> >> the interesting attributes don't live directly in the class dict, they
> >> live in private data structures stored in the class dict, making
> >> "list(MyEnum.__dict__)" inherently uninteresting, regardless of
> >> whether it's ordered or not).
> >
> > But that would only matter if we also defined a helper utility that
> > used __definition_order__. I expect that the implementation of Enum
> > could be simplified somewhat in Python 3.6 since it can trust that the
> > namespace passed into __new__ is ordered (so it doesn't have to switch
> > it to an OrderedDict in __prepare__, perhaps).
> >
> > In any case the most likely way to use __definition_order__ in general
> > was always to filter its contents through some other condition (e.g.
> > "isn't a method and doesn't start with underscore") -- you can do the
> > same with keys(). Classes that want to provide a custom list of
> > "interesting" attributes can provide that using whatever class method
> > or attribute they want -- it's just easier to keep those attributes
> > ordered because the namespace is always ordered.
>
> For example,it's already possible to expose order information via
> __dir__, consumers of the information just have to bypass the implicit
> sorting applied by the dir() builtin:
>
>   >>> class Example:
>   ... def __dir__(self):
>   ... return "first second third fourth".split()
>   ...
>   >>> dir(Example())
>   ['first', 'fourth', 'second', 'third']
>   >>> Example().__dir__()
>   ['first', 'second', 'third', 'fourth']
>
> You've persuaded me that omitting __definition_order__ is the right
> thing to do for now, so the last thing I'm going to do is to
> explicitly double check with the creators of a few interesting
> alternate implementations (MicroPython, VOC for JVM environments,
> Batavia for JavaScript environments) to see if this may cause them
> problems in officially implementing 3.6 (we know PyPy will be OK,
> since they did it first).
>
> VOC & Batavia *should* be OK (worst case, they return
> collections.OrderedDict from __prepare__ and also use it for __dict__
> attributes), but I'm less certain about MicroPython (since I don't
> know enough about how its current dict implementation works to know
> whether or not they'll be able to make the same change PyPy and
> CPython did)
>

>From the perspective of VOC and Batavia: As Nick notes, there may be some
changes needed to use OrderDict (or a native analog) in a couple of places,
but other than that, it doesn’t strike me as a change that will pose any
significant difficulty.

Yours,
Russ Magee %-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

2016-09-10 Thread Nick Coghlan
On 11 September 2016 at 09:41, Nathaniel Smith  wrote:
> On Fri, Sep 9, 2016 at 11:39 AM, Barry Warsaw  wrote:
>> On Sep 09, 2016, at 01:08 PM, Elvis Pranskevichus wrote:
>>
>>>Are there any downsides to explicitly specifying that all dicts are ordered?
>>>People will inevitably start relying on this behaviour, and this will
>>>essentially become the *de-facto* spec, so alternative Python implementations
>>>will have to follow suit anyway.
>>
>> It *might* make sense to revisit this once 3.5 is no longer maintained at 
>> all,
>> but I think Guido's exactly right in his analysis.  If people start relying 
>> on
>> all dicts being ordered now, their code won't be compatible with both 3.5 and
>> 3.6, and I think it's important to emphasize this to developers.
>
> I feel like I'm missing something here... by this reasoning, we should
> *never* change the language spec when new features are added. E.g. if
> people use async/await in 3.5 then their code won't be compatible with
> 3.4, but async/await are still part of the language spec. And in any
> case, the distinction between "CPython feature" and "Python
> language-spec-guaranteed feature" is *extremely* arcane and
> inside-basebally -- it seems really unlikely that most users will even
> understand what this distinction means, never mind let it stop them
> from writing CPython-and-PyPy-specific code. Emphasizing that this is
> a new feature that only exists in 3.6+ of course makes sense, I just
> don't understand why that affects the language spec bit.

To conform with the updated language spec, implementations just need
to use collections.OrderedDict in 3 places:

- default return value of __prepare__
- underlying storage type for __dict__ attributes
- storage type for passing kwargs to functions

They don't *necessarily* have to change their builtin dict type to be
order-preserving, as we're not deprecating collections.OrderedDict,
and we're not adding the additional methods offered by OrderedDict to
the base type.

So for normal development, the guidance is still "use
collections.OrderedDict explicitly if you need to preserve insertion
order", as being more explicit gives compatibility with CPython < 3.6,
and with any alternate implementations that take the path of using
collections.OrderedDict selectively rather than changing the behaviour
of their dict builtin (which was the original plan for CPython).

> (OTOH it doesn't matter that much anyway... the language spec is
> definitely a useful thing, but it's largely aspirational in practice
> -- other implementations target CPython compatibility more than they
> target language spec compatibility.)

The distinction is that there are cases where we *do* convince library
and framework authors to change their code for cross-version and
cross-implementation compatibility - the popularity of explicit
context management being one of the most significant examples of that,
as it's far more necessary on implementations that don't use automatic
reference counting the way CPython does.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP520 and absence of __definition_order__

2016-09-10 Thread Nick Coghlan
On 11 September 2016 at 07:26, Guido van Rossum  wrote:
> On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan  wrote:
>> On 11 September 2016 at 03:08, Guido van Rossum  wrote:
>>> So I'm happy to continue thinking about this, but I expect this is not
>>> such a big deal as you fear. Anyway, let's see if someone comes up
>>> with a more convincing argument by beta 2!
>>
>> For CPython specifically, I don't have anything more convincing than
>> Ethan's Enum example (where the way the metaclass works means most of
>> the interesting attributes don't live directly in the class dict, they
>> live in private data structures stored in the class dict, making
>> "list(MyEnum.__dict__)" inherently uninteresting, regardless of
>> whether it's ordered or not).
>
> But that would only matter if we also defined a helper utility that
> used __definition_order__. I expect that the implementation of Enum
> could be simplified somewhat in Python 3.6 since it can trust that the
> namespace passed into __new__ is ordered (so it doesn't have to switch
> it to an OrderedDict in __prepare__, perhaps).
>
> In any case the most likely way to use __definition_order__ in general
> was always to filter its contents through some other condition (e.g.
> "isn't a method and doesn't start with underscore") -- you can do the
> same with keys(). Classes that want to provide a custom list of
> "interesting" attributes can provide that using whatever class method
> or attribute they want -- it's just easier to keep those attributes
> ordered because the namespace is always ordered.

For example,it's already possible to expose order information via
__dir__, consumers of the information just have to bypass the implicit
sorting applied by the dir() builtin:

  >>> class Example:
  ... def __dir__(self):
  ... return "first second third fourth".split()
  ...
  >>> dir(Example())
  ['first', 'fourth', 'second', 'third']
  >>> Example().__dir__()
  ['first', 'second', 'third', 'fourth']

You've persuaded me that omitting __definition_order__ is the right
thing to do for now, so the last thing I'm going to do is to
explicitly double check with the creators of a few interesting
alternate implementations (MicroPython, VOC for JVM environments,
Batavia for JavaScript environments) to see if this may cause them
problems in officially implementing 3.6 (we know PyPy will be OK,
since they did it first).

VOC & Batavia *should* be OK (worst case, they return
collections.OrderedDict from __prepare__ and also use it for __dict__
attributes), but I'm less certain about MicroPython (since I don't
know enough about how its current dict implementation works to know
whether or not they'll be able to make the same change PyPy and
CPython did)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Let's make the SSL module sane

2016-09-10 Thread Nick Coghlan
On 11 September 2016 at 05:20, Christian Heimes  wrote:
> On 2016-09-10 17:24, Nick Coghlan wrote:
>> On 11 September 2016 at 00:22, Christian Heimes  wrote:
>>> First I like to deprecated some old APIs and favor of SSLCotext. We have
>>> multiple ways to create a SSL socket or to configure libraries like
>>> urllib. The general idea is to make SSLContext the central object for
>>> TLS/SSL configuration. My patch deprecates ssl.wrap_socket()
>>
>> I'll bring over my question from the tracker issue to here: there's a
>> subset of ssl.wrap_socket() arguments which actually make sense as
>> arguments to ssl.get_default_context().wrap_socket().
>>
>> Accordingly, we can pick a subset of code (e.g. SSL/TLS clients) that
>> we bless with not needing to change, leaving only code using
>> deprecated parameters or creating server sockets that needs to be
>> updated.
>
> Do you consider ssl.wrap_socket() relevant for so many projects? The
> function hurts performance and is no longer best practice. The
> deprecation of ssl.wrap_socket() is a friendly nudge. I don't mind to
> keep it around for another four or six years.

I have no problem with ripping out and replacing the internals of
ssl.wrap_socket(), and doing whatever is needed to improve its
performance. What I'm mainly looking for is a decision tree in the
overall API design that minimises the amount of fresh information a
developer needs to supply, and that makes the purpose of their code
relatively self-evident to someone that is reading low(ish) level
Python SSL/TLS code for the first time.

For example, I think this would be a desirably simple design from a
usage perspective:

# Client sockets as default, settings may change in maintenance releases
my_context = ssl.get_default_context()
my_tls_socket = ssl.wrap_socket(my_uncovered_socket)

# Server sockets by request, settings may change in maintenance releases
my_context = ssl.get_default_server_context()
my_tls_socket = ssl.wrap_server_socket(my_uncovered_socket)

# More control with more responsibility, defaults only change in
feature releases
my_context = ssl.SSLContext()
my_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)

With that approach, an API user only has to make two forced decisions:

- am I securing a client connection or a server connection?
- do I want to implicitly pick up modernised defaults in maintenance releases?

And we can make the second one a non-decision in most cases by
presenting the higher level convenience API as the preferred approach.

There would be a third hidden decision implied by the convenience APIs
(using the default system certificate store rather than loading a
custom one), but most users wouldn't need to worry about that.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Installation Error

2016-09-10 Thread MRAB

On 2016-09-11 00:44, Trevon Bizzle wrote:

Good evening! I tried downloading Python yesterday and was met with some
success. I have been searching for solutions but can not seem to find
one. Each time I try to run python an error occurs saying;
python.exe - System Error
The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is
missing from your computer. Try reinstalling the program to fix this
problem.
My friend and I tried at our school and was met no success in obtaining
the program. I am attempting to run python on a CQ60-615DX Notebook. Any
help would be appreciated. Thanks!

You computer needs the Universal C Runtime. An up-to-date system should 
already

have it.

Read here:

Update for Universal C Runtime in Windows
https://support.microsoft.com/en-us/kb/2999226

By the way, this list is for the development *of* the Python language. 
The list you should really be using is python-l...@python.org.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Installation Error

2016-09-10 Thread Trevon Bizzle
Good evening! I tried downloading Python yesterday and was met with some
success. I have been searching for solutions but can not seem to find one.
Each time I try to run python an error occurs saying;
python.exe - System Error
The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is
missing from your computer. Try reinstalling the program to fix this
problem.
My friend and I tried at our school and was met no success in obtaining the
program. I am attempting to run python on a CQ60-615DX Notebook. Any help
would be appreciated. Thanks!

-- 
Emails and other correspondence to and from Paradise Valley School District 
are subject to public disclosure, upon request, according to Arizona Public 
Records Law (A.R.S. §39-121, et seq.) and corresponding State records 
retention requirements, unless the content is specifically exempt from 
disclosure by a state or federal law.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

2016-09-10 Thread Nathaniel Smith
On Fri, Sep 9, 2016 at 11:39 AM, Barry Warsaw  wrote:
> On Sep 09, 2016, at 01:08 PM, Elvis Pranskevichus wrote:
>
>>Are there any downsides to explicitly specifying that all dicts are ordered?
>>People will inevitably start relying on this behaviour, and this will
>>essentially become the *de-facto* spec, so alternative Python implementations
>>will have to follow suit anyway.
>
> It *might* make sense to revisit this once 3.5 is no longer maintained at all,
> but I think Guido's exactly right in his analysis.  If people start relying on
> all dicts being ordered now, their code won't be compatible with both 3.5 and
> 3.6, and I think it's important to emphasize this to developers.

I feel like I'm missing something here... by this reasoning, we should
*never* change the language spec when new features are added. E.g. if
people use async/await in 3.5 then their code won't be compatible with
3.4, but async/await are still part of the language spec. And in any
case, the distinction between "CPython feature" and "Python
language-spec-guaranteed feature" is *extremely* arcane and
inside-basebally -- it seems really unlikely that most users will even
understand what this distinction means, never mind let it stop them
from writing CPython-and-PyPy-specific code. Emphasizing that this is
a new feature that only exists in 3.6+ of course makes sense, I just
don't understand why that affects the language spec bit.

(OTOH it doesn't matter that much anyway... the language spec is
definitely a useful thing, but it's largely aspirational in practice
-- other implementations target CPython compatibility more than they
target language spec compatibility.)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP520 and absence of __definition_order__

2016-09-10 Thread Guido van Rossum
On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan  wrote:
> On 11 September 2016 at 03:08, Guido van Rossum  wrote:
>> So I'm happy to continue thinking about this, but I expect this is not
>> such a big deal as you fear. Anyway, let's see if someone comes up
>> with a more convincing argument by beta 2!
>
> For CPython specifically, I don't have anything more convincing than
> Ethan's Enum example (where the way the metaclass works means most of
> the interesting attributes don't live directly in the class dict, they
> live in private data structures stored in the class dict, making
> "list(MyEnum.__dict__)" inherently uninteresting, regardless of
> whether it's ordered or not).

But that would only matter if we also defined a helper utility that
used __definition_order__. I expect that the implementation of Enum
could be simplified somewhat in Python 3.6 since it can trust that the
namespace passed into __new__ is ordered (so it doesn't have to switch
it to an OrderedDict in __prepare__, perhaps).

In any case the most likely way to use __definition_order__ in general
was always to filter its contents through some other condition (e.g.
"isn't a method and doesn't start with underscore") -- you can do the
same with keys(). Classes that want to provide a custom list of
"interesting" attributes can provide that using whatever class method
or attribute they want -- it's just easier to keep those attributes
ordered because the namespace is always ordered.

> The proxy use cases I'm aware of (wrapt, weakref.proxy) tend to be
> used to wrap normal instances rather than class objects themselves, so
> they shouldn't be affected.
>
> With ordered-by-default class namespaces, both heap types and non-heap
> types should also mostly be populated in the "logical order" (i.e. the
> order names appear in the relevant C arrays), but that would formally
> be an implementation detail at this point, rather than something we
> commit to providing.
>
> The only other argument that occurs to me is one that didn't come up
> in the earlier PEP 520 discussions: how a not-quite-Python
> implementation (or a Python 3.5 compatible implementation that doesn't
> offer order-preserving behaviour the way PyPy does) can make sure that
> code that relies on ordered class namespaces *fails* in an informative
> way when run on that implementation.

Is that a real use case? It sounds like you're just constructing an
artificial example that would be less convenient without
__definition_order__.

> With __definition_order__, that's straightforward - the code that
> needs it will fail with AttributeError, and searching for the
> attribute named in the exception will lead affected users directly to
> PEP 520 and the Python 3.6 What's New guide.

But that code would have to be written to use __definition_order__. It
could just as easily be written to assert that sys.version_info() >=
(3, 6).

> With implicitly ordered class namespaces, you don't get an exception
> if the namespace isn't actually order preserving - you get attributes
> in an arbitrary order instead. Interpreters can't detect that the user
> specifically wanted order preserving behaviour, and library and
> application authors can't readily detect whether or not the runtime
> offers order preserving behaviour (since they may just get lucky on
> that particular run).

That sounds very philosophical. You still can't check whether *dict*
is order-preserving -- all you can do is checking whether a *class*
preserves its order. Since PEP 520 is accepted only for Python 3.6,
checking for the presence of __definition_order__ is no different than
checking the version.

> Even if we added a new flag to sys.implementation that indicated the
> use of order preserving class namespaces, there'd still be plenty of
> scope for subtle bugs where libraries and frameworks weren't checking
> that flag before relying on the new behaviour.

OK, I'm beginning to see the argument here. You want all code that
relies on the order to be explicitly declaring that it does so by
using a new API.

Unfortunately the mere presence of __definition_order__ doesn't really
help here -- since all dicts are order-preserving, there's still
nothing (apart from documentation) to stop apps from relying on the
ordering of the class __dict__ directly.

> Cheers,
> Nick.
>
> P.S. I'd actually love it if we could skip __definition_order__ -
> there really is a whole lot of runtime clutter on class objects, and
> we're adding __annotations__ as well. Unfortunately, I also think we
> made the right call the first time around in thinking it would still
> be necessary even if class namespaces became order preserving :)

Note that __annotations__ is only added when there are annotations, so
its presence could be used as a flag of sorts. (However you shouldn't
use it directly -- each class in the MRO has its own __annotations__,
and you should use typing.get_type_hints(cls) to coalesce all of
them.)

Re: [Python-Dev] Let's make the SSL module sane

2016-09-10 Thread Christian Heimes
On 2016-09-10 17:24, Nick Coghlan wrote:
> On 11 September 2016 at 00:22, Christian Heimes  wrote:
>> First I like to deprecated some old APIs and favor of SSLCotext. We have
>> multiple ways to create a SSL socket or to configure libraries like
>> urllib. The general idea is to make SSLContext the central object for
>> TLS/SSL configuration. My patch deprecates ssl.wrap_socket()
> 
> I'll bring over my question from the tracker issue to here: there's a
> subset of ssl.wrap_socket() arguments which actually make sense as
> arguments to ssl.get_default_context().wrap_socket().
> 
> Accordingly, we can pick a subset of code (e.g. SSL/TLS clients) that
> we bless with not needing to change, leaving only code using
> deprecated parameters or creating server sockets that needs to be
> updated.

Do you consider ssl.wrap_socket() relevant for so many projects? The
function hurts performance and is no longer best practice. The
deprecation of ssl.wrap_socket() is a friendly nudge. I don't mind to
keep it around for another four or six years.

There is one other use case not covered by SSLContext.wrap_socket() but
by SSLSocket.__init__(). The SSLSocket constructor takes a fileno
argument. But it's an undocumented feature and it's broken since at
least 3.3. https://bugs.python.org/issue27629


> As with past network security changes, a major factor we need to
> account for is that no matter how valuable a particular goal is from a
> broader industry perspective, people don't tend to react to API breaks
> by fixing their code - they react by not upgrading at all.

I totally agree and have been verify careful to keep backwards
compatibility. My third patch breaks just one scenario:
ssl.create_default_context(purpose=Purpose.SERVER_AUTH) no longer
supports server-side connections and CLIENT_AUTH no longer client-side
connections. It's the good kind of incompatibility because it reveals
API misuse. Application should never have used SERVER_AUTH context to
create server sockets.



Christian
___
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] PEP520 and absence of __definition_order__

2016-09-10 Thread Eric Snow
On Sep 10, 2016 10:11, "Guido van Rossum"  wrote:
>
> Thanks for bringing this up. I think it's definitely possible to argue
> either way. I think what happened before was that I approved
> __definition_order__ because I wasn't expecting dict to be ordered by
> default. Now that Inada Naoki's patch has landed things have changed.
>
> Here's my reason for agreeing with (or convincing?) Eric to drop
> __definition_order__, as I remember it from the (lively) discussion at
> the sprint.
>

FWIW, my position was to leave __definition_order__ in place.  However,
once it became *mostly* redundant, I didn't consider the remaining benefits
to be sufficient justification for the extra complexity in the code to the
point that it was worth debating.  So I didn't object very strenuously when
Benjamin suggested removing it.  Regardless, I'm still in favor of keeping
__definition_order__. :)

-eric (phone)
___
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] PEP520 and absence of __definition_order__

2016-09-10 Thread Eric Snow
On Sep 10, 2016 11:00, "Nick Coghlan"  wrote:
>
> On 11 September 2016 at 03:08, Guido van Rossum  wrote:
> > So I'm happy to continue thinking about this, but I expect this is not
> > such a big deal as you fear. Anyway, let's see if someone comes up
> > with a more convincing argument by beta 2!
,
> Nick.
>
> P.S. I'd actually love it if we could skip __definition_order__ -
> there really is a whole lot of runtime clutter on class objects, and
> we're adding __annotations__ as well. Unfortunately, I also think we
> made the right call the first time around in thinking it would still
> be necessary even if class namespaces became order preserving :)
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com


-eric (phone)
___
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] Let's make the SSL module sane

2016-09-10 Thread Christian Heimes
On 2016-09-10 18:24, Donald Stufft wrote:
> 
>> On Sep 10, 2016, at 10:22 AM, Christian Heimes  wrote:
>>
>> I don't load any certs because it is not possible to remove a cert or
>> X509 lookup once it is loaded. create_default_context() just have to
>> load the certs and set more secure ciper suites.
> 
> 
> This part is the most concerning to me, though I understand why it’s the 
> case. Perhaps we can do something a little tricky to allow both things to 
> happen? IOW do sort of a late binding of a call to loading the default 
> certificates if no other certificates has been loaded when the call to 
> SSLContext().wrap_socket() has been made.
> 
> So we’d do something like:
> 
> 
> class SSLContext:
> def __init__(self, …):
> self._loaded_certificates = False
> …  # Do Other Stuff
> 
> def load_default_certs(self, …):
> self._loaded_certificates = True
> …  # Do Other Stuff
> 
> def load_verify_locations(self, …):
> self._loaded_certificates = True
> …  # Do Other Stuff
> 
> def wrap_socket(self, …):
> if not self._loaded_certificates:
> self.load_default_certs()
> 
> …  # Do Other Stuff
> 
> 
> That way if someone does something like:
> 
> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
> ctx.load_verify_locations(cafile=“…”)
> ctx.wrap_socket(…)
> 
> Then they don’t get any default certificates added, HOWEVER if they do:
> 
> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
> ctx.wrap_socket(…)
> 
> Then they do.
> 
> The main draw back I can see with this is that you can’t wrap a socket and 
> then add certificates after the fact… but I don’t even know if that makes 
> sense to do?

It's a bit too clever and tricky for my taste. I prefer 'explicit is
better than implicit' for trust anchors. My main concern are secure
default settings. A SSLContext should be secure w/o further settings in
order to prevent developers to shoot themselves in the knee.

Missing root certs are not a direct security issue with CERT_REQUIRED.
The connection will simply fail. I'd rather improve the error message
than to auto-load certs.

Christian

___
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] PEP520 and absence of __definition_order__

2016-09-10 Thread Nick Coghlan
On 11 September 2016 at 03:08, Guido van Rossum  wrote:
> So I'm happy to continue thinking about this, but I expect this is not
> such a big deal as you fear. Anyway, let's see if someone comes up
> with a more convincing argument by beta 2!

For CPython specifically, I don't have anything more convincing than
Ethan's Enum example (where the way the metaclass works means most of
the interesting attributes don't live directly in the class dict, they
live in private data structures stored in the class dict, making
"list(MyEnum.__dict__)" inherently uninteresting, regardless of
whether it's ordered or not).

The proxy use cases I'm aware of (wrapt, weakref.proxy) tend to be
used to wrap normal instances rather than class objects themselves, so
they shouldn't be affected.

With ordered-by-default class namespaces, both heap types and non-heap
types should also mostly be populated in the "logical order" (i.e. the
order names appear in the relevant C arrays), but that would formally
be an implementation detail at this point, rather than something we
commit to providing.

The only other argument that occurs to me is one that didn't come up
in the earlier PEP 520 discussions: how a not-quite-Python
implementation (or a Python 3.5 compatible implementation that doesn't
offer order-preserving behaviour the way PyPy does) can make sure that
code that relies on ordered class namespaces *fails* in an informative
way when run on that implementation.

With __definition_order__, that's straightforward - the code that
needs it will fail with AttributeError, and searching for the
attribute named in the exception will lead affected users directly to
PEP 520 and the Python 3.6 What's New guide.

With implicitly ordered class namespaces, you don't get an exception
if the namespace isn't actually order preserving - you get attributes
in an arbitrary order instead. Interpreters can't detect that the user
specifically wanted order preserving behaviour, and library and
application authors can't readily detect whether or not the runtime
offers order preserving behaviour (since they may just get lucky on
that particular run).

Even if we added a new flag to sys.implementation that indicated the
use of order preserving class namespaces, there'd still be plenty of
scope for subtle bugs where libraries and frameworks weren't checking
that flag before relying on the new behaviour.

Cheers,
Nick.

P.S. I'd actually love it if we could skip __definition_order__ -
there really is a whole lot of runtime clutter on class objects, and
we're adding __annotations__ as well. Unfortunately, I also think we
made the right call the first time around in thinking it would still
be necessary even if class namespaces became order preserving :)

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP520 and absence of __definition_order__

2016-09-10 Thread Guido van Rossum
Thanks for bringing this up. I think it's definitely possible to argue
either way. I think what happened before was that I approved
__definition_order__ because I wasn't expecting dict to be ordered by
default. Now that Inada Naoki's patch has landed things have changed.

Here's my reason for agreeing with (or convincing?) Eric to drop
__definition_order__, as I remember it from the (lively) discussion at
the sprint.

- There are only a few use cases for definition order. Without trying
to be complete, the use cases I am aware of are all similar to the
django Forms interface
(https://docs.djangoproject.com/en/1.10/ref/forms/api/#module-django.forms)
where the order in which fields are defined determines the order in
which they are rendered. Possibly the traits or traitlets libraries
also have similar functionality; I know I added it to a database API I
wrote at Google as well. I have another idea for a use case where you
can define a named tuple with typed fields using PEP 526 syntax.

- I like sparsity of interfaces. A class already has dunder attributes
for bases, mro, docstring, name, qualified name, module, and probably
a few others that I've forgotten. Cruft inevitably accumulates, but I
still feel I have to fight it. If we can get the functionality needed
for those use cases without a new dunder attribute, so much the
better.

- The Forms trait[let]s use cases and named tuples can clearly be
dealt with by using list(cls.__dict__), since they all involve a
user-defined class.

- If we had had ordered dicts from the start, those use cases would
have been built upon that happily. What would Cython do? I don't know,
but  I imagine they'd come up with it -- they certainly ought to be
able with a way to construct the class __dict__ in the desired order.
Is there even a situation where Cython would need to support the
construction of forms, trait[let]s, or named tuples using Cython code
in a way that the order is discoverable afterwards? (I imagine that
Cython would love the named tuple idea, but they'd know the field
definition order at compile time, so why would they also need it at
runtime?)

So I'm happy to continue thinking about this, but I expect this is not
such a big deal as you fear. Anyway, let's see if someone comes up
with a more convincing argument by beta 2!

--Guido

On Sat, Sep 10, 2016 at 4:19 AM, Nick Coghlan  wrote:
> On 10 September 2016 at 19:27, Nick Coghlan  wrote:
>> On 10 September 2016 at 17:49, Ethan Furman  wrote:
>>> The "mostly" is what concerns me.  Much like having a custom __dir__ lets
>>> a class fine-tune what is of interest, a custom __definition_order__ allows
>>> a class to present a unified view of the class creation process.  This could
>>> be important to classes that employ __getattr__ (or __getattribute__) to
>>> provide virtual attributes, such as Enum or proxy classes.
>>
>> +1
>>
>> The reasoning for modifying the PEP post-acceptance is faulty -
>> __definition_order__ wasn't just there as a CPython implementation
>> detail, it was there as a way to allow class and metaclass developers
>> to hide their *own* irrelevant implementation details.
>>
>> Since __definition_order__ was already accepted, and the rationale for
>> removing it is incorrect, could we please have it back for beta 1?
>
> After posting this, I realised I should give a bit more detail on why
> I see PEP 520 without __definition_order__ as potentially problematic.
> Specifically, it relates to these two sections in the PEP about having
> __definition_order__ be writable and about whether or not to set it
> for classes that aren't created via the class syntax:
>
> * https://www.python.org/dev/peps/pep-0520/#why-not-a-read-only-attribute
> * https://www.python.org/dev/peps/pep-0520/#support-for-c-api-types
>
> From the first section: "Also, note that a writeable
> __definition_order__ allows dynamically created classes (e.g. by
> Cython) to still have __definition_order__ properly set. That could
> certainly be handled through specific class- creation tools, such as
> type() or the C-API, without the need to lose the semantics of a
> read-only attribute. However, with a writeable attribute it's a moot
> point. "
>
> From the second: "However, since __definition_order__ can be set at
> any time through normal attribute assignment, it does not need any
> special treatment in the C-API."
>
> Unlike the __definition_order__ tuple, making "list(cls.__dict__)" the
> official way of accessing the definition order exposes an
> implementation detail that's somewhat specific to the way Python class
> statements work, rather than being universal across all the different
> techniques that exist for putting together Python class objects.
>
> As Terry suggested, I've reopened and elevated the priority of
> http://bugs.python.org/issue24254, but only to deferred blocker -
> while I do think we need to reconsider the decision to remove
> 

Re: [Python-Dev] [Webmaster] A broken link!

2016-09-10 Thread Nick Coghlan
On 11 September 2016 at 01:27, Steve Holden  wrote:
> Hi Karen,
>
> Thanks for your note. I just checked the source of the document in question,
> and it appears that link has been changed to reference
> https://www.mercurial-scm.org/guide, so it appears that we may be publishing
> an out-of-date document there.
>
> I'm copying this reply to the python-dev list, and the release manager may
> or may not choose to update the published version.

There's a problem with the way we're publishing our docs, but it's
probably more that we're not emitting canonical URL tags that tell
search engines to drop the major version qualifier from the links they
present in search results: https://bugs.python.org/issue26355

This means that even folks using newer versions of Python may land on
older versions of the docs if that's what a search engine happens to
present for their particular query.

I haven't personally found the time to follow up on that idea with an
actual implementation, but it would presumably be a matter of
tinkering with the Sphinx theme and/or conf.py file (even for the no
longer supported versions of the docs).

Cheers,
Nick.

P.S. Although in this case, it may have just been a direct link to the
3.2 version of the 3.2 What's New - there isn't a lot we can do about
that, as when a branch goes unsupported, we usually stop updating the
docs as well (even when external links break)

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Let's make the SSL module sane

2016-09-10 Thread Donald Stufft

> On Sep 10, 2016, at 10:22 AM, Christian Heimes  wrote:
> 
> I don't load any certs because it is not possible to remove a cert or
> X509 lookup once it is loaded. create_default_context() just have to
> load the certs and set more secure ciper suites.


This part is the most concerning to me, though I understand why it’s the case. 
Perhaps we can do something a little tricky to allow both things to happen? IOW 
do sort of a late binding of a call to loading the default certificates if no 
other certificates has been loaded when the call to SSLContext().wrap_socket() 
has been made.

So we’d do something like:


class SSLContext:
def __init__(self, …):
self._loaded_certificates = False
…  # Do Other Stuff

def load_default_certs(self, …):
self._loaded_certificates = True
…  # Do Other Stuff

def load_verify_locations(self, …):
self._loaded_certificates = True
…  # Do Other Stuff

def wrap_socket(self, …):
if not self._loaded_certificates:
self.load_default_certs()

…  # Do Other Stuff


That way if someone does something like:

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.load_verify_locations(cafile=“…”)
ctx.wrap_socket(…)

Then they don’t get any default certificates added, HOWEVER if they do:

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.wrap_socket(…)

Then they do.

The main draw back I can see with this is that you can’t wrap a socket and then 
add certificates after the fact… but I don’t even know if that makes sense to 
do?

—
Donald Stufft



___
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] [Webmaster] A broken link!

2016-09-10 Thread Steve Holden
Hi Karen,

Thanks for your note. I just checked the source of the document in
question, and it appears that link has been changed to reference
https://www.mercurial-scm.org/guide, so it appears that we may be
publishing an out-of-date document there.

I'm copying this reply to the python-dev list, and the release manager may
or may not choose to update the published version.

regards
 Steve

Steve Holden

On Fri, Sep 9, 2016 at 3:37 PM, Karen Little <
karen.lit...@whoishostingthismail.com> wrote:

> Hi,
>
> Just wanted to let you know about a link that seems to be broken on this
> page https://docs.python.org/3.2/whatsnew/3.2.html.
>
> It is this link http://mercurial.selenic.com/guide/, but the page doesn’t
> seem to be active any more. I thought you might want to update.
>
> If you are looking for an alternative please check out
> http://wiht.link/Mercurial-intro, it may make a suitable replacement.
>
> Kind Regards,
> Karen
>
>
>
> Don't want emails from us anymore? Reply to this email with the word
> "UNSUBSCRIBE" in the subject line.
> WhoIsHostingThis, BM Box 3667, Old Gloucester Street London, WC1N 3XX,
> United Kingdom
> ___
> Webmaster mailing list
> webmas...@python.org
> https://mail.python.org/mailman/listinfo/webmaster
>
>
___
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] Let's make the SSL module sane

2016-09-10 Thread Nick Coghlan
On 11 September 2016 at 00:22, Christian Heimes  wrote:
> First I like to deprecated some old APIs and favor of SSLCotext. We have
> multiple ways to create a SSL socket or to configure libraries like
> urllib. The general idea is to make SSLContext the central object for
> TLS/SSL configuration. My patch deprecates ssl.wrap_socket()

I'll bring over my question from the tracker issue to here: there's a
subset of ssl.wrap_socket() arguments which actually make sense as
arguments to ssl.get_default_context().wrap_socket().

Accordingly, we can pick a subset of code (e.g. SSL/TLS clients) that
we bless with not needing to change, leaving only code using
deprecated parameters or creating server sockets that needs to be
updated.

As with past network security changes, a major factor we need to
account for is that no matter how valuable a particular goal is from a
broader industry perspective, people don't tend to react to API breaks
by fixing their code - they react by not upgrading at all.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Let's make the SSL module sane

2016-09-10 Thread Christian Heimes
Hi,

(CC TLS gurus)

For 3.6 I like to make the SSL more sane and more secure by default.
Yes, I'm a bit late but all my proposals are implemented, documented,
partly tested and  existing tests are passing. I'm going to write more
tests and documentation after beta1.


First I like to deprecated some old APIs and favor of SSLCotext. We have
multiple ways to create a SSL socket or to configure libraries like
urllib. The general idea is to make SSLContext the central object for
TLS/SSL configuration. My patch deprecates ssl.wrap_socket() and
SSLSocket constructor in favor of SSLContext.wrap_socket(). The patch
also deprecates certfile, keyfile an similar arguments in network
protocol libraries.

I also considered to make cert validation enabled by default for all
protocol in 3.6, Victor has rising some concerns. How about we change
the behavior in 3.7 and just add a warning to 3.6?

http://bugs.python.org/issue28022
https://github.com/tiran/cpython/commits/feature/feature/ssl_deprecation



Next up SSLContext default configuration. A bare SSLContext comes with
insecure default settings. I'd like to make SSLContext(PROTOCOL_SSLv23)
secure bu default. Changelog: The context is created with more secure
default values. The options OP_NO_COMPRESSION,
OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE,
OP_NO_SSLv2 (except for PROTOCOL_SSLv2), and OP_NO_SSLv3 (except for
PROTOCOL_SSLv3) are set by default. The initial cipher suite list
contains only HIGH ciphers, no NULL ciphers and MD5 ciphers (except for
PROTOCOL_SSLv2).

http://bugs.python.org/issue28043
https://github.com/tiran/cpython/commits/feature/ssl_sane_defaults



Finally (and this is the biggest) I like to change how the protocols
work. OpenSSL 1.1.0 has deprecated all version specific protocols. Soon
OpenSSL will only support auto-negotiation (formerly known as
PROTOCOL_SSLv23). My patch #26470 added PROTOCOL_TLS as alias for
PROTOCOL_SSLv23. If the last idea is accepted I will remove PROTOCOL_TLS
again. It hasn't been released yet. Instead I'm going to add
PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER (see
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_new.html
TLS_server_method(), TLS_client_method()). PROTOCOL_TLS_CLIENT is like
PROTOCOL_SSLv23 but only supports client-side sockets and
PROTOCOL_TLS_SERVER just server-side sockets. In my experience we can't
have a SSLContext with sensible and secure settings for client and
server at the same time. Hostname checking and cert validation is only
sensible for client-side sockets.

Starting in 3.8 (or 3.7?) there will be only PROTOCOL_TLS_CLIENT and
PROTOCOL_TLS_SERVER.

I haven't created a ticket yet, code is at
https://github.com/tiran/cpython/commits/feature/openssl_client_server



How will my proposals change TLS/SSL code?

Application must create a SSLContext object. Applications are
recommended to keep the context around to benefit from session reusage
and reduce overload of cert parsing.


Client side, ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT):

* works with TLSv1.0, TLSv1.1, TLSv1.2 and new protocols
* Options OP_NO_SSLv2, OP_NO_SSLv3, OP_NO_COMPRESSION are set
* Only HIGH cipher suites are enabled, MD5 and NULL are disabled
* all other ciphers are still enabled, MD5 for SSLv2
* cert_required = CERT_REQUIRED
* check_hostname = True
* ctx.wrap_socket() creates a client-side socket
* ctx.wrap_socket(server_side=True) will not work
* root certs are *not* loaded

I don't load any certs because it is not possible to remove a cert or
X509 lookup once it is loaded. create_default_context() just have to
load the certs and set more secure ciper suites.



Server side, ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_PROTOCOL):

* works with TLSv1.0, TLSv1.1, TLSv1.2 and new protocols
* Options OP_NO_SSLv2, OP_NO_SSLv3, OP_NO_COMPRESSION are set
* OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE are set
* Only HIGH cipher suites are enabled, MD5 and NULL are disabled
* all other ciphers are still enabled, MD5 for SSLv2
* cert_required = CERT_NONE (no client cert validation)
* check_hostname = False
* no root CA certs are loaded
* only ctx.wrap_socket(server_side=True) works


I hope this mail makes sense.
Christian
___
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] sys.path file feature

2016-09-10 Thread Steve Dower
The underscore is an appropriate rename here, but calling the file sys.path was 
too juicy :)

It's intended only for embedding on Windows and does not exist on Linux/Mac yet 
(more precisely, implementation is only in PC/getpathp.c). I chatted with some 
people about spreading it and there wasn't really enough interest yet - 
theoretical uses but not actual ones, whereas on Windows there are actual uses. 
If you have actual uses we can look more seriously at it, but right now it's 
more of a secret registry key that disables the registry.

As it is totally outside the language and very specific to a particular 
installation, support can easily be added at any time. Find my various 
write-ups on the embeddable distro for details on the use cases, but none of 
them affect regular Python developers.

Cheers,
Steve

Top-posted from my Windows Phone

-Original Message-
From: "Nick Coghlan" 
Sent: ‎9/‎10/‎2016 2:43
To: "Wolfgang" 
Cc: "Python Dev" 
Subject: Re: [Python-Dev] sys.path file feature

On 10 September 2016 at 18:37, Wolfgang  wrote:
> Hi,
>
> tracking the commit log I have noticed for Windows there was added a new
> feature which is very interesting and can also be useful for other
> platforms.
>
> If I read it right it supports adding a sys.path text file near the
> executable to specify the Python sys.path variable and overwriting the
> default behavior.
>
> https://hg.python.org/cpython/rev/03517dd54977

While I'm all for adding ways to simplify CPython sys.path
configuration, they shouldn't be added as implicit side effects of
other changes without at least some discussion of the chosen approach.

If there isn't time for that, and it's needed to solve a particular
problem, then the underscore-prefix naming convention indicating "this
is not a standardised and supported interface" works just as well for
config files as it does for module and attribute names.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP520 and absence of __definition_order__

2016-09-10 Thread Nick Coghlan
On 10 September 2016 at 19:27, Nick Coghlan  wrote:
> On 10 September 2016 at 17:49, Ethan Furman  wrote:
>> The "mostly" is what concerns me.  Much like having a custom __dir__ lets
>> a class fine-tune what is of interest, a custom __definition_order__ allows
>> a class to present a unified view of the class creation process.  This could
>> be important to classes that employ __getattr__ (or __getattribute__) to
>> provide virtual attributes, such as Enum or proxy classes.
>
> +1
>
> The reasoning for modifying the PEP post-acceptance is faulty -
> __definition_order__ wasn't just there as a CPython implementation
> detail, it was there as a way to allow class and metaclass developers
> to hide their *own* irrelevant implementation details.
>
> Since __definition_order__ was already accepted, and the rationale for
> removing it is incorrect, could we please have it back for beta 1?

After posting this, I realised I should give a bit more detail on why
I see PEP 520 without __definition_order__ as potentially problematic.
Specifically, it relates to these two sections in the PEP about having
__definition_order__ be writable and about whether or not to set it
for classes that aren't created via the class syntax:

* https://www.python.org/dev/peps/pep-0520/#why-not-a-read-only-attribute
* https://www.python.org/dev/peps/pep-0520/#support-for-c-api-types

>From the first section: "Also, note that a writeable
__definition_order__ allows dynamically created classes (e.g. by
Cython) to still have __definition_order__ properly set. That could
certainly be handled through specific class- creation tools, such as
type() or the C-API, without the need to lose the semantics of a
read-only attribute. However, with a writeable attribute it's a moot
point. "

>From the second: "However, since __definition_order__ can be set at
any time through normal attribute assignment, it does not need any
special treatment in the C-API."

Unlike the __definition_order__ tuple, making "list(cls.__dict__)" the
official way of accessing the definition order exposes an
implementation detail that's somewhat specific to the way Python class
statements work, rather than being universal across all the different
techniques that exist for putting together Python class objects.

As Terry suggested, I've reopened and elevated the priority of
http://bugs.python.org/issue24254, but only to deferred blocker -
while I do think we need to reconsider the decision to remove
__definition_order__ based on a proper update to the PEP that accounts
for all the points that came up in the original discussions, I also
don't see any major problem with leaving it out in beta 1, and then
restoring it in beta 2.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 467: last round (?)

2016-09-10 Thread Serhiy Storchaka

On 01.09.16 22:36, Ethan Furman wrote:

* Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators


Could you please add a mention of alternative: seqtools.chunks()? 
seqtools.chunks(bytes, 1) and seqtools.chunks(bytearray, 1) should be 
equivalent to bytes.iterbytes() and bytearray.iterbytes() (but this 
function is applicable to arbitrary sequences, including memoryview and 
array).


Is there a need of a PEP for new seqtools module (currently two classes 
are planned), or just providing sample implementation on the bugtracker 
would be enough?


___
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] PEP520 and absence of __definition_order__

2016-09-10 Thread Terry Reedy

On 9/10/2016 5:27 AM, Nick Coghlan wrote:

On 10 September 2016 at 17:49, Ethan Furman  wrote:

Per Victor's advice I'm posting this here.

PEP 520 has been accepted, but without the __definition_order__ attribute.
The accompanying comment:


"Note: Since compact dict has landed in 3.6, __definition_order__ has
been removed. cls.__dict__ now mostly accomplishes the same thing
instead."



The "mostly" is what concerns me.  Much like having a custom __dir__ lets
a class fine-tune what is of interest, a custom __definition_order__ allows
a class to present a unified view of the class creation process.  This could
be important to classes that employ __getattr__ (or __getattribute__) to
provide virtual attributes, such as Enum or proxy classes.


+1

The reasoning for modifying the PEP post-acceptance is faulty -
__definition_order__ wasn't just there as a CPython implementation
detail, it was there as a way to allow class and metaclass developers
to hide their *own* irrelevant implementation details.

Since __definition_order__ was already accepted, and the rationale for
removing it is incorrect, could we please have it back for beta 1?


Someone (Ethan?) should ask that this be a release blocker on some issue.

--
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] sys.path file feature

2016-09-10 Thread Nick Coghlan
On 10 September 2016 at 18:37, Wolfgang  wrote:
> Hi,
>
> tracking the commit log I have noticed for Windows there was added a new
> feature which is very interesting and can also be useful for other
> platforms.
>
> If I read it right it supports adding a sys.path text file near the
> executable to specify the Python sys.path variable and overwriting the
> default behavior.
>
> https://hg.python.org/cpython/rev/03517dd54977

While I'm all for adding ways to simplify CPython sys.path
configuration, they shouldn't be added as implicit side effects of
other changes without at least some discussion of the chosen approach.

If there isn't time for that, and it's needed to solve a particular
problem, then the underscore-prefix naming convention indicating "this
is not a standardised and supported interface" works just as well for
config files as it does for module and attribute names.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP520 and absence of __definition_order__

2016-09-10 Thread Nick Coghlan
On 10 September 2016 at 17:49, Ethan Furman  wrote:
> Per Victor's advice I'm posting this here.
>
> PEP 520 has been accepted, but without the __definition_order__ attribute.
> The accompanying comment:
>
>> "Note: Since compact dict has landed in 3.6, __definition_order__ has
>> been removed. cls.__dict__ now mostly accomplishes the same thing
>> instead."
>
>
> The "mostly" is what concerns me.  Much like having a custom __dir__ lets
> a class fine-tune what is of interest, a custom __definition_order__ allows
> a class to present a unified view of the class creation process.  This could
> be important to classes that employ __getattr__ (or __getattribute__) to
> provide virtual attributes, such as Enum or proxy classes.

+1

The reasoning for modifying the PEP post-acceptance is faulty -
__definition_order__ wasn't just there as a CPython implementation
detail, it was there as a way to allow class and metaclass developers
to hide their *own* irrelevant implementation details.

Since __definition_order__ was already accepted, and the rationale for
removing it is incorrect, could we please have it back for beta 1?

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] sys.path file feature

2016-09-10 Thread Wolfgang

Hi,

tracking the commit log I have noticed for Windows there was added a new 
feature which is very interesting and can also be useful for other 
platforms.


If I read it right it supports adding a sys.path text file near the 
executable to specify the Python sys.path variable and overwriting the 
default behavior.


https://hg.python.org/cpython/rev/03517dd54977


This change is only for Windows (if I read right). But I think it is 
thus valuable to add this in common as general rule. This also 
simplifies and unifies virtual environment creating and standalone 
redistribution.


Also I have one remaining question, is the "*.pth" file handling then
disabled by this feature?

If yes, can this be a problem in a virtual environment if a package uses
a pth file installed in the virtual environment site-packages directory?


Overall I think this is a great addition and the start to unify sys.path
handling. And a good feature for redistribution of a Python interpreter 
without an installation. (Embedding, virtual environments, fat virtual 
environments, ...)


Regards,

Wolfgang
___
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] PEP520 and absence of __definition_order__

2016-09-10 Thread Ethan Furman

Per Victor's advice I'm posting this here.

PEP 520 has been accepted, but without the __definition_order__ attribute.
The accompanying comment:


"Note: Since compact dict has landed in 3.6, __definition_order__ has
been removed. cls.__dict__ now mostly accomplishes the same thing
instead."


The "mostly" is what concerns me.  Much like having a custom __dir__ lets
a class fine-tune what is of interest, a custom __definition_order__ allows
a class to present a unified view of the class creation process.  This could
be important to classes that employ __getattr__ (or __getattribute__) to
provide virtual attributes, such as Enum or proxy classes.

With __definition_order__ Enum can display the actual creation order of enum
members and methods, while relying on Enum.__dict__.keys() presents a jumbled
mess with many attributes the user never wrote, the enum members either
appearing /after/ all the methods (even if actually written before), or
entirely absent.

For example,  this class:


class PassBy(Enum):

... value = 1
... reference = 2
... name = 3
... object = name
... def used_by_python(self):
... return self.name == 'name'
...

shows this:


PassBy.__dict__.keys()

dict_keys([
   '_generate_next_value_',
'__module__',
'used_by_python',
   '__doc__',
'_member_names_',
'_member_map_',
'_member_type_',
'_value2member_map_',
'reference',
'object',
'__new__',
   ])

Notice that two of the members are missing, and all are after the method.

If __definition_order__ existed it would be this:


PassBy.__definition_order__

['value', 'reference', 'name', 'object', 'used_by_python']

Which is a much more accurate picture of the user's class.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com