Re: [Python-Dev] PEP XXX: Compact ordered dict

[INADA Naoki]

On Tue, Jun 21, 2016 at 12:17 PM, Oleg Broytman  wrote:
> Hi!
>
> On Tue, Jun 21, 2016 at 11:14:39AM +0900, INADA Naoki 
>  wrote:
>> Here is my draft, but I haven't
>> posted it yet since
>> my English is much worse than C.
>> https://www.dropbox.com/s/s85n9b2309k03cq/pep-compact-dict.txt?dl=0
>
>It's good enough for a start (if a PEP is needed at all). If you push
> it to Github I'm sure they will come with pull requests.
>
> Oleg.

Thank you for reading my draft.

> (if a PEP is needed at all)

I don't think so. My PEP is not for changing Python Language,
just describe implementation detail.

Python 3.5 has new OrderedDict implemented in C without PEP.
My patch is relatively small than it.  And the idea has been well known.

-- 
INADA Naoki  
___
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 XXX: Compact ordered dict

[Oleg Broytman]

Hi!

On Tue, Jun 21, 2016 at 11:14:39AM +0900, INADA Naoki  
wrote:
> Here is my draft, but I haven't
> posted it yet since
> my English is much worse than C.
> https://www.dropbox.com/s/s85n9b2309k03cq/pep-compact-dict.txt?dl=0

   It's good enough for a start (if a PEP is needed at all). If you push
it to Github I'm sure they will come with pull requests.

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] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Stephen J. Turnbull]

Donald Stufft writes:

 > I guess one question would be, what does the secrets module do if
 > it’s on a Linux that is too old to have getrandom(0), off the top
 > of my head I can think of:
 > 
 > * Silently fall back to reading os.urandom and hope that it’s been
 >   seeded.
 > * Fall back to os.urandom and hope that it’s been seeded and add a
 >   SecurityWarning or something like it to mention that it’s
 >   falling back to os.urandom and it may be getting predictable
 >   random from /dev/urandom.
 > * Hard fail because it can’t guarantee secure cryptographic
 >   random.

I'm going to hide behind the Linux manpage (which actually suggests
saving the data in a file to speed initialization at boot) in
mentioning this:

* if random_initialized_timestamp_pre_boot():
  r = open("/dev/random", "rb")
  u = open("/dev/urandom", "wb")
  u.write(r.read(enough_bytes))
  set_random_initialized_timestamp()
  # in theory, secrets can now use os.urandom

___
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 487: Simpler customization of class creation

[Raymond Hettinger]

> On Jun 20, 2016, at 5:41 PM, Tim Delaney  wrote:
> 
> Although not a Jython developer, I've looked into the code a few times.
> 
> The major stumbling block as I understand it will be that Jython uses a 
> ConcurrentHashMap as the underlying structure for a dictionary. This would 
> need to change to a concurrent LinkedHashMap, but there's no such thing in 
> the standard library. The best option would appear to be 
> https://github.com/ben-manes/concurrentlinkedhashmap.
> 
> There are also plenty of other places that use maps and all of them would 
> need to be looked at. In a lot of cases they're things like IdentityHashMap 
> which may also need an ordered equivalent.

If you can, check with Jim Baker.  At the language summit a few years ago, he 
and I sketched out a solution that he thought was doable without much effort 
and without much of a performance hit.   IIRC, it involved using a 
ConcurrentHashMap augmented by an auxiliary 2-by-n-row array of indices (one 
for forward links and the other for backward links).  There was also need to 
add a reentrant lock around the mutating methods.


Raymond Hettinger

___
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 520: Preserving Class Attribute Definition Order (round 4)

[Eric Snow]

I've updated PEP 520 to reflect a clearer focus on the definition
order and less emphasis on OrderedDict.

-eric

===


PEP: 520
Title: Preserving Class Attribute Definition Order
Version: $Revision$
Last-Modified: $Date$
Author: Eric Snow 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 7-Jun-2016
Python-Version: 3.6
Post-History: 7-Jun-2016, 11-Jun-2016, 20-Jun-2016


Abstract


When a class is defined using a ``class`` statement, the class body is
executed within a namespace.  After the execution completes, that
namespace is copied into new ``dict`` and the original definition
namespace is discarded.  The new copy is stored away as the class's
namespace and is exposed as ``__dict__`` through a read-only proxy.

This PEP preserves the order in which the attributes in the definition
namespace were added to it, before that namespace is discarded.  This
means it reflects the definition order of the class body.  That order
will now be preserved in the ``__definition_order__`` attribute of the
class.  This allows introspection of the original definition order,
e.g. by class decorators.

Additionally, this PEP changes the default class definition namespace
to ``OrderedDict``.  The long-lived class namespace (``__dict__``) will
remain a ``dict``.


Motivation
==

Currently Python does not preserve the order in which attributes are
added to the class definition namespace. The namespace used during
execution of a class body defaults to ``dict``.  If the metaclass
defines ``__prepare__()`` then the result of calling it is used.  Thus,
before this PEP, to access your class definition namespace you must
use ``OrderedDict`` along with a metaclass. Then you must preserve the
definition order (from the ``OrderedDict``) yourself.  This has a
couple of problems.

First, it requires the use of a metaclass.  Metaclasses introduce an
extra level of complexity to code and in some cases (e.g. conflicts)
are a problem.  So reducing the need for them is worth doing when the
opportunity presents itself.  PEP 422 and PEP 487 discuss this at
length.  Given that we now have a C implementation of ``OrderedDict``
and that ``OrderedDict`` is the common use case for ``__prepare__()``,
we have such an opportunity by defaulting to ``OrderedDict``.

Second, only classes that opt in to using the ``OrderedDict``-based
metaclass will have access to the definition order. This is problematic
for cases where universal access to the definition order is important.
One of the original motivating use cases for this PEP is generic class
decorators that make use of the definition order.


Specification
=

Part 1:

* the order in which class attributes are defined is preserved in the
  new ``__definition_order__`` attribute on each class
* "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
* ``__definition_order__`` is a ``tuple`` (or ``None``)
* ``__definition_order__`` is a read-only attribute
* ``__definition_order__`` is always set:

  1. if ``__definition_order__`` is defined in the class body then it
 must be a ``tuple`` of identifiers or ``None``; any other value
 will result in ``TypeError``
  2. classes that do not have a class definition (e.g. builtins) have
 their ``__definition_order__`` set to ``None``
  3. classes for which `__prepare__()`` returned something other than
 ``OrderedDict`` (or a subclass) have their ``__definition_order__``
 set to ``None`` (except where #1 applies)

Part 2:

* the default class *definition* namespace is now ``OrderdDict``

The following code demonstrates roughly equivalent semantics for the
default behavior::

   class Meta(type):
   @classmethod
   def __prepare__(cls, *args, **kwargs):
   return OrderedDict()

   class Spam(metaclass=Meta):
   ham = None
   eggs = 5
   __definition_order__ = tuple(k for k in locals()
if not (k.startswith('__') and
k.endswith('__')))

Note that [pep487_] proposes a similar solution, albeit as part of a
broader proposal.

Why a tuple?


Use of a tuple reflects the fact that we are exposing the order in
which attributes on the class were *defined*.  Since the definition
is already complete by the time ``__definition_order__`` is set, the
content and order of the value won't be changing.  Thus we use a type
that communicates that state of immutability.

Why a read-only attribute?
--

As with the use of tuple, making ``__definition_order__`` a read-only
attribute communicates the fact that the information it represents is
complete.  Since it represents the state of a particular one-time event
(execution of the class definition body), allowing the value to be
replaced would reduce confidence that the attribute corresponds to the
original class body.

If a use case for a writable (or 

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

[INADA Naoki]

>>
>> Finally, it seems someone is working on making all dicts ordered. Does that
>> mean this will soon be obsolete?
>
> Nope.  Having an ordered definition namespace by default does not give
> us __definition_order__ for free.  Furthermore, the compact dict under
> consideration isn't strictly order-preserving (re-orders for
> deletion).
>

compact ordered dict I proposed is preserves insertion order even some
items are deleted.
http://bugs.python.org/issue27350

Should I post PEP for compact dict?  Here is my draft, but I haven't
posted it yet since
my English is much worse than C.
https://www.dropbox.com/s/s85n9b2309k03cq/pep-compact-dict.txt?dl=0
___
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] Review of PEP 520: Ordered Class Definition Namespace

[Eric Snow]

On Mon, Jun 20, 2016 at 10:32 AM, Guido van Rossum  wrote:
> - I don't like the exception for dunder names. I can see that __module__,
>  __name__ etc. that occur in every class are distractions, but since you're
> adding methods, you should also add methods with dunder names like
> __init__ or __getattr__. (Otherwise, what if someone really wanted to create
> a Django form with a field named __dunder__?)

Note that in that case they could set __definition_order__ manually in
their class body.  That said, I don't mind relaxing this if you think
the common-case clutter is worth it for the case where a dunder name
is relevant.  You have a keen sense for this sort of situation. :)

> - It's a shame we can't just make __dict__ (a proxy to) an OrderedDict, then
> we wouldn't need an extra attribute. Hm, maybe we could customize the proxy
> class so its keys(), values(), items() views return things in the order of
> __definition_order__?

I'm not sure it's worth it to mess with the proxy like that.  Plus, I
like how __definition_order__ makes it obvious what it is as well as
more discoverable.

> (In the tracker discussion this was considered a big
> deal, but given that a class __dict__ is already a readonly proxy I'm not
> sure I agree. Or is this about C level access? How much of that would
> break?)

I actually tried making the underlying class namespace (behind the
proxy at __dict__) an OrderedDict.  I ended up with a number of
problems because of the pervasive use of the concrete dict API
relative to the class dict.  That API does not play well with
subclasses.

>
> - I don't see why it needs to be a read-only attribute. There are very few
> of those -- in general we let users play around with things unless we have a
> hard reason to restrict assignment (e.g. the interpreter's internal state
> could be compromised). I don't see such a hard reason here.

I'm willing to change that.  I figured we would start off treating it
like we have other dunder attributes, some of which have become
writable while others remain read-only.  However, you are right that
there is no danger in making it writable.

>
> - All in all the motivation is fairly weak -- it seems to be mostly
> motivated on avoiding a custom metaclass for this purpose because combining
> metaclasses is a pain. I realize it's only a small patch in a small corner
> of the language, but I do worry about repercussions -- it's an API that's
> going to be used for new (and useful) purposes so we will never be able to
> get rid of it.

True.  It's certainly a very specific feature.  The point is that we
currently throw away the attribute order from class definitions.  You
can opt in to preserving the order using an appropriate metaclass.
However, everything that would make use of that information (e.g.
class decorators) would then have a prerequisite of that metaclass.
That means such a tool could only consume classes that were designed
to be used by the tool.  Then there's the whole problem of metaclass
conflicts (see PEP 487).

If, instead, we always preserved the definition order then these
problems (again, for an admittedly corner use case) go away.

FWIW, regarding repercussions, I do not expect any other potential
future feature will subsume the functionality of PEP 520.  The closest
thing would be if cls.__dict__ became ordered.  However, that would
intersect with __definition_order__ only at first.  Furthermore,
cls.__dict__ would only ever be able to make vague promises about any
relationship with the definiton order.  The point of
__definiton_order__ is to provide the one obvious place to get a
specific bit of information about a class.

>
> Note: I'm neither accepting nor rejecting the PEP; I'm merely inviting more
> contemplation.

Thanks. :)

-eric
___
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 520: Ordered Class Definition Namespace

[Eric Snow]

On Mon, Jun 20, 2016 at 9:49 AM, Guido van Rossum  wrote:
> I agree it's better to define the order as computed at runtime. I don't
> think there's much of a point to mandate that all builtin/extension types
> reveal their order too -- I doubt there will be many uses for that -- but I
> don't want to disallow it either. But we can allow types to define this, as
> long as it's in their documentation (so users can rely on it in those
> cases).

Agreed.

>
> As another point of review, I don't like the exception for dunder names. I
> can see that __module__, __name__ etc. are distractions, but since you're
> adding methods, you should also add methods with dunder names.

I still think that in practice the dunder names will be clutter that
folks have to ignore.  However, it's a relatively weak point given
that it's easy to ignore dunder names.  So I don't mind including
them.

>
> The overlap with PEP 487 makes me think that this feature is clearly
> desirable (I like the name you give it in PEP 520 better, and PEP 487 is too
> vague about its definition).

Agreed.

>
> Finally, it seems someone is working on making all dicts ordered. Does that
> mean this will soon be obsolete?

Nope.  Having an ordered definition namespace by default does not give
us __definition_order__ for free.  Furthermore, the compact dict under
consideration isn't strictly order-preserving (re-orders for
deletion).

-eric
___
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 520: Ordered Class Definition Namespace

[Eric Snow]

On Fri, Jun 17, 2016 at 7:32 PM, Nick Coghlan  wrote:
> The discussion in the PEP 487 thread made me realise that I'd like to
> see a discussion in PEP 520 regarding whether or not to define
> __definition_order__ for builtin types initialised via PyType_Ready or
> created via PyType_FromSpec in addition to defining it for types
> created via the class statement or types.new_class().
>
> For static types, PyType_Ready could potentially set it based on
> tp_members, tp_methods & tp_getset (see
> https://docs.python.org/3/c-api/typeobj.html )
> Similarly, PyType_FromSpec could potentially set it based on the
> contents of Py_tp_members, Py_tp_methods and Py_tp_getset slot
> definitions
>
> Having definition order support in both types.new_class() and builtin
> types would also make it clear why we can't rely purely on the
> compiler to provide the necessary ordering information - in both of
> those cases, the Python compiler isn't directly involved in the type
> creation process.

I'll mention this in the PEP, but I'd rather not make it a part of the proposal.

-eric
___
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 487: Simpler customization of class creation

[Tim Delaney]

On 21 June 2016 at 06:12, Guido van Rossum  wrote:

> OK, basically you're arguing that knowing the definition order of class
> attributes is often useful when (ab)using Python for things like schema or
> form definitions. There are a few ways to go about it:
>
> 1. A hack using a global creation counter
> 
> 2. Metaclass with __prepare__
> 
> 3. PEP 520 
> 4a. Make all dicts OrderedDicts in CPython
> 
> 4b. Ditto in the language standard
>
> If we can make the jump to (4b) soon enough I think we should skip PEP
> 520; if not, I am still hemming and hawing about whether PEP 520 has enough
> benefits over (2) to bother.
>
> Sorry Eric for making this so hard. The better is so often the enemy of
> the good. I am currently somewhere between -0 and +0 on PEP 520. I'm not
> sure if the work on (4a) is going to bear fruit in time for the 3.6
> feature freeze ; if
> it goes well I think we should have a separate conversation (maybe even a
> PEP?) about (4b). Maybe we should ask for feedback from the Jython
> developers? (PyPy already has this IIUC, and IronPython
>  seems moribund?)
>

Although not a Jython developer, I've looked into the code a few times.

The major stumbling block as I understand it will be that Jython uses a
ConcurrentHashMap as the underlying structure for a dictionary. This would
need to change to a concurrent LinkedHashMap, but there's no such thing in
the standard library. The best option would appear to be
https://github.com/ben-manes/concurrentlinkedhashmap.

There are also plenty of other places that use maps and all of them would
need to be looked at. In a lot of cases they're things like IdentityHashMap
which may also need an ordered equivalent.

There is a repo for Jython 3.5 development:
https://github.com/jython/jython3 but it doesn't seem to be very active -
only 11 commits in the last year (OTOH that's also in the last 3 months).

Tim Delaney
___
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] New security-sig mailling list

[Ethan Furman]

On 06/20/2016 03:02 PM, Chris Jerdonek wrote:


I would recommend clarifying the relationship of the SIG to the Python
Security Response Team ( https://www.python.org/news/security ), or at
least clarifying that the SIG is different from the PSRT (and that
security reports should not be sent to the SIG).


Attempted to do so.  Let me know if it can be clearer still.

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

Re: [Python-Dev] frame evaluation API PEP

[Dino Viehland via Python-Dev]

On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon 
> wrote:
MRAB's response made me think of a possible approach: the co_extra field could 
be the very last field of the PyCodeObject struct and only present if a certain 
flag is set in co_flags. This is similar to a trick used by X11 (I know, it's 
long ago :-)

But that doesn't resolve your memory worry, right? For a JIT you will have to 
access the memory regardless for execution count (unless Yury's patch to add 
caching goes in, in which case it will be provided by code objects already).

If you make the code object constructor another function pointer in the 
interpreter struct, you could solve this quite well IMO. An interpreter with a 
JIT installed would always create code objects with the co_extra field. But 
interpreters without a JIT would have have code objects without it. This would 
mean the people who aren't using a JIT at all don't pay for co_extra. The flag 
would still be needed so the JIT can tell when you pass it a code object that 
was created before the JIT was installed (or belonging to a different 
interpreter).

Would that work? Or is it important to be able to import a lot of code and then 
later import+install the JIT and have it benefit the code you already imported?

That’s a pretty interesting idea.  We actually load the JIT DLL before we 
execute any Python code so currently it wouldn’t have any issues with not 
having the full sized code objects created.  But it could also let JITs store 
all of the info they need right there instead of having to create yet another 
place to track code data.  And it fits in nicely with having the extra data 
being truly ephemeral that no one else should care about.  It doesn’t help with 
the issue of potentially multiple consumers of that field that has been brought 
up before but I’m not sure how concerned we should be about that scenario 
anyway.

I still want to check and see what the hash table overhead looks like but if 
that does end up looking bad I can definitely look at giving this a shot.


___
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] Problem

[Jonathan Goble]

General questions like this belong on python-list, not python-dev.

To answer your question, though, you need to run that command from the
Windows Command Prompt, not from the Python interpreter.
___
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] frame evaluation API PEP

[Guido van Rossum]

Couple uses of "it" here are ambiguous -- are you saying we don't need
co_extra after all, or that we can safely insist it's a dict, or...?

On Mon, Jun 20, 2016 at 1:20 PM, Dino Viehland via Python-Dev <
python-dev@python.org> wrote:

> Mark wrote:
> > > Dino and I thought of two potential alternatives, neither of which we
> > > have taken the time to implement and benchmark. One is to simply have
> > > a hash table of memory addresses to JIT data that is kept on the JIT
> > > side of things. Obviously it would be nice to avoid the overhead of a
> > > hash table lookup on every function call. This also doesn't help
> > > minimize memory when the code object gets GC'ed.
> >
> > Hash lookups aren't that slow. If you combine it with the custom flags
> > suggested by MRAB, then you would only suffer the lookup penalty when
> > actually entering the special interpreter.
> > You can use a weakref callback to ensure things get GC'd properly.
> >
> > Also, if there is a special extra field on code-object, then everyone
> will want
> > to use it. How do you handle clashes?
>
> This is exactly what I've started prototyping and have mostly coded up,
> I've
> just been getting randomized and haven't gotten back to it yet.
>
> It may have some impact in the short-term but my expectation is that as the
> JIT gets better that this will become less and less important.  Currently
> we're
> just JITing one method at a time and have no inlining support.  But once we
> can start putting guards in place and inlining across multiple function
> calls
> we will start reducing the transitions from JIT -> Function Call -> JIT
> and get
> rid of those hash table lookups entirely.  And if we can't succeed at
> inlining then
> I suspect the JIT won't end up offering the performance we'd hope for.
>
>
> ___
> 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/guido%40python.org
>



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

Re: [Python-Dev] Problem

[Oleg Broytman]

Hello.

   We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/news
group is the best place; there are Python developers who participate in it;
you may get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.

On Mon, Jun 20, 2016 at 05:55:38PM -0400, Sandranel  
wrote:
> Hi:
> 
> My daughter and  I are trying to update to 8.1.2,but every time we  try this
> happens

   As for your question: the command "python -m pip install" must be run
from OS command line, not from Python itself.

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] New security-sig mailling list

[Chris Jerdonek]

On Mon, Jun 20, 2016 at 12:24 PM, Ethan Furman  wrote:
>
> has been created:
>
>   https://mail.python.org/mailman/listinfo/security-sig
>
> The purpose of this list is to discuss security-related enhancements to 
> Python while having as little impact on backwards compatibility as possible.

I would recommend clarifying the relationship of the SIG to the Python
Security Response Team ( https://www.python.org/news/security ), or at
least clarifying that the SIG is different from the PSRT (and that
security reports should not be sent to the SIG).

--Chris


>
> Once a proposal is ready it will be presented to Python Dev.
>
> (This text is subject to change. ;)
>
> --
> ~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/chris.jerdonek%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

[Python-Dev] Problem

[Sandranel]

Hi:

 

My daughter and  I are trying to update to 8.1.2,but every time we  try this
happens

 

>From the API

 

 



 

To the Python window:

 



 

Please advise

___
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] frame evaluation API PEP

[Dino Viehland via Python-Dev]

Mark wrote:
> > Dino and I thought of two potential alternatives, neither of which we
> > have taken the time to implement and benchmark. One is to simply have
> > a hash table of memory addresses to JIT data that is kept on the JIT
> > side of things. Obviously it would be nice to avoid the overhead of a
> > hash table lookup on every function call. This also doesn't help
> > minimize memory when the code object gets GC'ed.
> 
> Hash lookups aren't that slow. If you combine it with the custom flags
> suggested by MRAB, then you would only suffer the lookup penalty when
> actually entering the special interpreter.
> You can use a weakref callback to ensure things get GC'd properly.
> 
> Also, if there is a special extra field on code-object, then everyone will 
> want
> to use it. How do you handle clashes?

This is exactly what I've started prototyping and have mostly coded up, I've
just been getting randomized and haven't gotten back to it yet.

It may have some impact in the short-term but my expectation is that as the
JIT gets better that this will become less and less important.  Currently we're
just JITing one method at a time and have no inlining support.  But once we 
can start putting guards in place and inlining across multiple function calls
we will start reducing the transitions from JIT -> Function Call -> JIT and get
rid of those hash table lookups entirely.  And if we can't succeed at inlining 
then
I suspect the JIT won't end up offering the performance we'd hope for.


___
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] frame evaluation API PEP

[Brett Cannon]

On Mon, 20 Jun 2016 at 13:43 Christian Heimes  wrote:

> On 2016-06-20 22:18, Guido van Rossum wrote:
> > On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon  > > wrote:
> >
> > MRAB's response made me think of a possible approach: the
> > co_extra field could be the very last field of the PyCodeObject
> > struct and only present if a certain flag is set in co_flags.
> > This is similar to a trick used by X11 (I know, it's long ago :-)
> >
> >
> > But that doesn't resolve your memory worry, right? For a JIT you
> > will have to access the memory regardless for execution count
> > (unless Yury's patch to add caching goes in, in which case it will
> > be provided by code objects already).
> >
> >
> > If you make the code object constructor another function pointer in the
> > interpreter struct, you could solve this quite well IMO. An interpreter
> > with a JIT installed would always create code objects with the co_extra
> > field. But interpreters without a JIT would have have code objects
> > without it. This would mean the people who aren't using a JIT at all
> > don't pay for co_extra. The flag would still be needed so the JIT can
> > tell when you pass it a code object that was created before the JIT was
> > installed (or belonging to a different interpreter).
> >
> > Would that work? Or is it important to be able to import a lot of code
> > and then later import+install the JIT and have it benefit the code you
> > already imported?
>
> Ha, I had the same idea. co_flags has some free bits. You could store
> extra flags there.
>
> Is the PyCodeObject's layout part of Python's stable ABI?


No: https://docs.python.org/3/c-api/code.html#c.PyCodeObject


> I'm asking
> because the PyCodeObject struct has a suboptimal layout. It's wasting a
> couple of bytes because it mixes int and ptr. If we move the int
> co_firstlineno member below the co_flags member, then the struct size
> shrinks by 64 bits on 64bit system -- the exact same size a PyObject
> *co_extras member.
>

:) We should probably do that reordering regardless of the result of 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] frame evaluation API PEP

[Christian Heimes]

On 2016-06-20 22:18, Guido van Rossum wrote:
> On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon  > wrote:
> 
> MRAB's response made me think of a possible approach: the
> co_extra field could be the very last field of the PyCodeObject
> struct and only present if a certain flag is set in co_flags.
> This is similar to a trick used by X11 (I know, it's long ago :-)
> 
> 
> But that doesn't resolve your memory worry, right? For a JIT you
> will have to access the memory regardless for execution count
> (unless Yury's patch to add caching goes in, in which case it will
> be provided by code objects already).
> 
> 
> If you make the code object constructor another function pointer in the
> interpreter struct, you could solve this quite well IMO. An interpreter
> with a JIT installed would always create code objects with the co_extra
> field. But interpreters without a JIT would have have code objects
> without it. This would mean the people who aren't using a JIT at all
> don't pay for co_extra. The flag would still be needed so the JIT can
> tell when you pass it a code object that was created before the JIT was
> installed (or belonging to a different interpreter).
> 
> Would that work? Or is it important to be able to import a lot of code
> and then later import+install the JIT and have it benefit the code you
> already imported?

Ha, I had the same idea. co_flags has some free bits. You could store
extra flags there.

Is the PyCodeObject's layout part of Python's stable ABI? I'm asking
because the PyCodeObject struct has a suboptimal layout. It's wasting a
couple of bytes becaues it mixes int and ptr. If we move the int
co_firstlineno member below the co_flags member, then the struct size
shrinks by 64 bits on 64bit system -- the exact same size a PyObject
*co_extras member.

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] frame evaluation API PEP

[Guido van Rossum]

On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon  wrote:

> MRAB's response made me think of a possible approach: the co_extra field
>> could be the very last field of the PyCodeObject struct and only present if
>> a certain flag is set in co_flags. This is similar to a trick used by X11
>> (I know, it's long ago :-)
>>
>
> But that doesn't resolve your memory worry, right? For a JIT you will have
> to access the memory regardless for execution count (unless Yury's patch to
> add caching goes in, in which case it will be provided by code objects
> already).
>

If you make the code object constructor another function pointer in the
interpreter struct, you could solve this quite well IMO. An interpreter
with a JIT installed would always create code objects with the co_extra
field. But interpreters without a JIT would have have code objects without
it. This would mean the people who aren't using a JIT at all don't pay for
co_extra. The flag would still be needed so the JIT can tell when you pass
it a code object that was created before the JIT was installed (or
belonging to a different interpreter).

Would that work? Or is it important to be able to import a lot of code and
then later import+install the JIT and have it benefit the code you already
imported?

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

Re: [Python-Dev] PEP 487: Simpler customization of class creation

[Guido van Rossum]

OK, basically you're arguing that knowing the definition order of class
attributes is often useful when (ab)using Python for things like schema or
form definitions. There are a few ways to go about it:

1. A hack using a global creation counter

2. Metaclass with __prepare__

3. PEP 520 
4a. Make all dicts OrderedDicts in CPython

4b. Ditto in the language standard

If we can make the jump to (4b) soon enough I think we should skip PEP 520;
if not, I am still hemming and hawing about whether PEP 520 has enough
benefits over (2) to bother.

Sorry Eric for making this so hard. The better is so often the enemy of the
good. I am currently somewhere between -0 and +0 on PEP 520. I'm not sure
if the work on (4a) is going to bear fruit in time for the 3.6 feature
freeze ; if it goes
well I think we should have a separate conversation (maybe even a PEP?)
about (4b). Maybe we should ask for feedback from the Jython developers?
(PyPy already has this IIUC, and IronPython
 seems moribund?)

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

Re: [Python-Dev] frame evaluation API PEP

[Brett Cannon]

On Sun, 19 Jun 2016 at 19:37 Guido van Rossum  wrote:

> On Sun, Jun 19, 2016 at 6:29 PM, Brett Cannon  wrote:
>
>>
>>
>> On Sat, 18 Jun 2016 at 21:49 Guido van Rossum  wrote:
>>
>>> Hi Brett,
>>>
>>> I've got a few questions about the specific design. Probably you know
>>> the answers, it would be nice to have them in the PEP.
>>>
>>
>> Once you're happy with my answers I'll update the PEP.
>>
>
> Soon!
>
>
>>
>>
>>>
>>> First, why not have a global hook? What does a hook per interpreter give
>>> you? Would even finer granularity buy anything?
>>>
>>
>> We initially considered a per-code object hook, but we figured it was
>> unnecessary to have that level of control, especially since people like
>> Numba have gotten away with not needing it for this long (although I
>> suspect that's because they are a decorator so they can just return an
>> object that overrides __call__()).
>>
>
> So they do it at the function object level?
>

Yes. They use a decorator, allowing them to completely control what
function object gets returned.


>
>
>> We didn't think that a global one was appropriate as different workloads
>> may call for different JITs/debuggers/etc. and there is no guarantee that
>> you are executing every interpreter with the same workload. Plus we figured
>> people might simply import their JIT of choice and as a side-effect set the
>> hook, and since imports are a per-interpreter thing that seemed to suggest
>> the granularity of interpreters.
>>
>
> I like import as the argument here.
>
>
>>
>> IOW it seemed to be more in line with sys.settrace() than some global
>> thing for the process.
>>
>>
>>>
>>> Next, I'm a bit (but no more than a bit) concerned about the extra 8
>>> bytes per code object, especially since for most people this is just waste
>>> (assuming most people won't be using Pyjion or Numba). Could it be a
>>> compile-time feature (requiring recompilation of CPython but not
>>> extensions)?
>>>
>>
>> Probably. It does water down potential usage thanks to needing a special
>> build. If the decision is "special build or not", I would simply pull out
>> this part of the proposal as I wouldn't want to add a flag that influences
>> what is or is not possible for an interpreter.
>>
>
> MRAB's response made me think of a possible approach: the co_extra field
> could be the very last field of the PyCodeObject struct and only present if
> a certain flag is set in co_flags. This is similar to a trick used by X11
> (I know, it's long ago :-).
>

But that doesn't resolve your memory worry, right? For a JIT you will have
to access the memory regardless for execution count (unless Yury's patch to
add caching goes in, in which case it will be provided by code objects
already).


>
>>
>>> Could you figure out some other way to store per-code-object data? It
>>> seems you considered this but decided that the co_extra field was simpler
>>> and faster; I'm basically pushing a little harder on this. Of course most
>>> of the PEP would disappear without this feature; the extra interpreter
>>> field is fine.
>>>
>>
>> Dino and I thought of two potential alternatives, neither of which we
>> have taken the time to implement and benchmark. One is to simply have a
>> hash table of memory addresses to JIT data that is kept on the JIT side of
>> things. Obviously it would be nice to avoid the overhead of a hash table
>> lookup on every function call. This also doesn't help minimize memory when
>> the code object gets GC'ed.
>>
>
> I guess the prospect of the extra hash lookup per call isn't great given
> that this is about perf...
>

It's not desirable, but it isn't the end of the world either. I think Dino
doesn't believe it will be that big of a deal to switch to a hash table.


>
>> The other potential solution we came up with was to use weakrefs. I have
>> not looked into the details, but we were thinking that if we registered the
>> JIT data object as a weakref on the code object, couldn't we iterate
>> through the weakrefs attached to the code object to look for the JIT data
>> object, and then get the reference that way? It would let us avoid a more
>> expensive hash table lookup if we assume most code objects won't have a
>> weakref on it (assuming weakrefs are stored in a list), and it gives us the
>> proper cleanup semantics we want by getting the weakref cleanup callback
>> execution to make sure we decref the JIT data object appropriately. But as
>> I said, I have not looked into the feasibility of this at all to know if
>> I'm remembering the weakref implementation details correctly.
>>
>
> That would be even slower than the hash table lookup, and unbounded. So
> let's not go there.
>

OK.

-Brett
___
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] frame evaluation API PEP

[Brett Cannon]

On Sun, 19 Jun 2016 at 21:01 Mark Shannon  wrote:

>
>
> On 19/06/16 18:29, Brett Cannon wrote:
> >
> >
> > On Sat, 18 Jun 2016 at 21:49 Guido van Rossum  > > wrote:
> >
> > Hi Brett,
> >
> > I've got a few questions about the specific design. Probably you
> > know the answers, it would be nice to have them in the PEP.
> >
> >
> > Once you're happy with my answers I'll update the PEP.
> >
> >
> > First, why not have a global hook? What does a hook per interpreter
> > give you? Would even finer granularity buy anything?
> >
> >
> > We initially considered a per-code object hook, but we figured it was
> > unnecessary to have that level of control, especially since people like
> > Numba have gotten away with not needing it for this long (although I
> > suspect that's because they are a decorator so they can just return an
> > object that overrides __call__()). We didn't think that a global one was
> > appropriate as different workloads may call for different
> > JITs/debuggers/etc. and there is no guarantee that you are executing
> > every interpreter with the same workload. Plus we figured people might
> > simply import their JIT of choice and as a side-effect set the hook, and
> > since imports are a per-interpreter thing that seemed to suggest the
> > granularity of interpreters.
> >
> > IOW it seemed to be more in line with sys.settrace() than some global
> > thing for the process.
> >
> >
> > Next, I'm a bit (but no more than a bit) concerned about the extra 8
> > bytes per code object, especially since for most people this is just
> > waste (assuming most people won't be using Pyjion or Numba). Could
> > it be a compile-time feature (requiring recompilation of CPython but
> > not extensions)?
> >
> >
> > Probably. It does water down potential usage thanks to needing a special
> > build. If the decision is "special build or not", I would simply pull
> > out this part of the proposal as I wouldn't want to add a flag that
> > influences what is or is not possible for an interpreter.
> >
> > Could you figure out some other way to store per-code-object data?
> > It seems you considered this but decided that the co_extra field was
> > simpler and faster; I'm basically pushing a little harder on this.
> > Of course most of the PEP would disappear without this feature; the
> > extra interpreter field is fine.
> >
> >
> > Dino and I thought of two potential alternatives, neither of which we
> > have taken the time to implement and benchmark. One is to simply have a
> > hash table of memory addresses to JIT data that is kept on the JIT side
> > of things. Obviously it would be nice to avoid the overhead of a hash
> > table lookup on every function call. This also doesn't help minimize
> > memory when the code object gets GC'ed.
>
> Hash lookups aren't that slow.


There's "slow" and there's "slower".


> If you combine it with the custom flags
> suggested by MRAB, then you would only suffer the lookup penalty when
> actually entering the special interpreter.
>

You actually will always need the lookup in the JIT case to increment the
execution count if you're not always immediately JIT-ing. That means MRAB's
flag won't necessarily be that useful in the JIT case (it could in the
debugging case, though, if you're really aiming for the fastest debugger
possible).


> You can use a weakref callback to ensure things get GC'd properly.
>

Yes, that was already the plan if we lost co_extra.


>
> Also, if there is a special extra field on code-object, then everyone
> will want to use it. How do you handle clashes?
>

As already explained in the PEP in
https://www.python.org/dev/peps/pep-0523/#expanding-pycodeobject, like
consenting adults. The expectation is that there will not be multiple users
of the object at the same time.

-Brett


>
> >
> > The other potential solution we came up with was to use weakrefs. I have
> > not looked into the details, but we were thinking that if we registered
> > the JIT data object as a weakref on the code object, couldn't we iterate
> > through the weakrefs attached to the code object to look for the JIT
> > data object, and then get the reference that way? It would let us avoid
> > a more expensive hash table lookup if we assume most code objects won't
> > have a weakref on it (assuming weakrefs are stored in a list), and it
> > gives us the proper cleanup semantics we want by getting the weakref
> > cleanup callback execution to make sure we decref the JIT data object
> > appropriately. But as I said, I have not looked into the feasibility of
> > this at all to know if I'm remembering the weakref implementation
> > details correctly.
> >
> >
> > Finally, there are some error messages from pep2html.py:
> > https://www.python.org/dev/peps/pep-0523/#copyright
> >
> >
> > All fixed in
> >
> 

[Python-Dev] New security-sig mailling list

[Ethan Furman]

has been created:

  https://mail.python.org/mailman/listinfo/security-sig

The purpose of this list is to discuss security-related enhancements to 
Python while having as little impact on backwards compatibility as possible.


Once a proposal is ready it will be presented to Python Dev.

(This text is subject to change. ;)

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

Re: [Python-Dev] PEP 487: Simpler customization of class creation

[Nikita Nemkin]

On Mon, Jun 20, 2016 at 9:48 PM, Guido van Rossum  wrote:
> On Thu, Jun 16, 2016 at 3:24 PM, Nikita Nemkin  wrote:
>>
>> I didin't know that PyPy has actually implemented packed ordered dicts!
>>
>> https://morepypy.blogspot.ru/2015/01/faster-more-memory-efficient-and-more.html
>> https://mail.python.org/pipermail/python-dev/2012-December/123028.html
>>
>> This old idea by Raymond Hettinger is vastly superior to
>> __definition_order__ duct tape (now that PyPy has validated it).
>> It also gives kwarg order for free, which is important in many
>> metaprogramming scenarios.
>> Not to mention memory usage reduction and dict operations speedup...
>
>
> That idea is only vastly superior if we want to force all other Python
> implementations to also have an order-preserving dict with the same
> semantics and API.

Right. Ordered by default is a very serious implementation constraint.
It's only superior in a sense that it completely subsumes/obsoletes
PEP 520.

> I'd like to hear more about your metaprogramming scenarios -- often such
> things end up being code the author is ashamed of. Perhaps they should stay
> in the shadows? Or could we do something to make it so you won't have to be
> ashamed of it?

What I meant is embedding declarative domain-specific languages
in Python. Examples of such languages include SQL table
definitions, binary data definitions (in-memory C structs or
wire protocol), GUI definitions (look up enaml for an interesting
example), etc. etc. DSLs are a well defined field and the point
of embedding into Python is to implement in Python and to
empower DSL with Python constructs for generation and logic.

Basic blocks for a declarative language are lists and "objects" -
groups of ordered, named fields.

Representing lists is easy and elegant, commas make a tuple
and [] makes a list.

It's when trying to represent "objects" the issues arise.
Literal dicts are "ugly" (for DSL purposes) and unordered.
Lists of 2-tuples are even uglier. Py3 gave us __prepare__ for
ordered class bodies, and this became a first valid option.
For example, SQL table:

class MyTable(SqlTable):
field1 = Type1(options...)
field2 = Type2()

Unfortunately, class declarations don't look good when nested,
and nesting is a common thing.

class MainWindow:
caption = "Window"
class HSplit:
label1 = Label(...)
text1 = Text(...)

You get the idea.
Another option for expressing "objects" are function calls with kwargs:

packet = Struct(type=uint8,
length=uint32,
body=Array(uint8, 'type'))

Looks reasonably clean, but more often than not requires kwargs
to be ordered. THIS is the scenario I was talking about.

Function attributes also have a role, but being
attached to function definitions, their scope is somewhat limited.

Of course, all of the above is largely theoretical, for two basic
reasons:
1) Python syntax/runtime is too rigid for a declarative DSL.
   (Specifically, _embedded_ DSL. The syntax alone can be re-used
   with ast.parse, but it's a different scenario.)
2) DSLs in general are grossly unpythonic, hiding loads of magic
   and unfamiliar semantics behind what looks like a normal Python.
   It's not something to be ashamed of, but the benefit
   rarely justifies the (maintenance) cost.

To be clear: I'm NOT advocating for ordered kwargs. Embedding
DSLs into Python is generally a bad idea.

PS. __prepare__ enables many DSL tricks. In fact, it's difficult to
imagine a use case that's not related to some attempt at DSL.
Keyword-only args also help: ordered part of the definition can go
into *args, while attributes/options are kw-only args.
___
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 487: Simpler customization of class creation

[Guido van Rossum]

On Thu, Jun 16, 2016 at 3:24 PM, Nikita Nemkin  wrote:

> On Fri, Jun 17, 2016 at 2:36 AM, Nick Coghlan  wrote:
> > On 16 June 2016 at 14:17, Martin Teichmann 
> wrote:
>
> > An implementation like PyPy, with an inherently ordered standard dict
> > implementation, can just rely on that rather than being obliged to
> > switch to their full collections.OrderedDict type.
>
> I didin't know that PyPy has actually implemented packed ordered dicts!
>
> https://morepypy.blogspot.ru/2015/01/faster-more-memory-efficient-and-more.html
> https://mail.python.org/pipermail/python-dev/2012-December/123028.html
>
> This old idea by Raymond Hettinger is vastly superior to
> __definition_order__ duct tape (now that PyPy has validated it).
> It also gives kwarg order for free, which is important in many
> metaprogramming scenarios.
> Not to mention memory usage reduction and dict operations speedup...
>

That idea is only vastly superior if we want to force all other Python
implementations to also have an order-preserving dict with the same
semantics and API.

I'd like to hear more about your metaprogramming scenarios -- often such
things end up being code the author is ashamed of. Perhaps they should stay
in the shadows? Or could we do something to make it so you won't have to be
ashamed of it?

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

[Python-Dev] Review of PEP 520: Ordered Class Definition Namespace

[Guido van Rossum]

PEP 520 review notes.

(From previous message; edited.)

- I agree it's better to define the order as computed at runtime.

- I don't think there's much of a point to mandate that all
builtin/extension types reveal their order too -- I doubt there will be
many uses for that -- but I don't want to disallow it either. We can allow
types to define this, as long as it's in their documentation (so users can
rely on it in those cases).

- I don't like the exception for dunder names. I can see that __module__,
__name__ etc. that occur in every class are distractions, but since you're
adding methods, you should also add methods with dunder names like __init__
or __getattr__. (Otherwise, what if someone really wanted to create a
Django form with a field named __dunder__?)

- The overlap with PEP 487 makes me think that this feature is clearly
desirable (I like the name you give it in PEP 520 better, and PEP 487 is
too vague about its definition).

- It seems someone is working on making all dicts ordered. Does that mean
this will soon be obsolete? It would be a shame if we ended up having to
give every class an extra attribute that is just a materialization of
C.__dict__.keys() with (some) dunder names filtered out.

(New)

- It's a shame we can't just make __dict__ (a proxy to) an OrderedDict,
then we wouldn't need an extra attribute. Hm, maybe we could customize the
proxy class so its keys(), values(), items() views return things in the
order of __definition_order__? (In the tracker discussion this was
considered a big deal, but given that a class __dict__ is already a
readonly proxy I'm not sure I agree. Or is this about C level access? How
much of that would break?)

- I don't see why it needs to be a read-only attribute. There are very few
of those -- in general we let users play around with things unless we have
a hard reason to restrict assignment (e.g. the interpreter's internal state
could be compromised). I don't see such a hard reason here.

- All in all the motivation is fairly weak -- it seems to be mostly
motivated on avoiding a custom metaclass for this purpose because combining
metaclasses is a pain. I realize it's only a small patch in a small corner
of the language, but I do worry about repercussions -- it's an API that's
going to be used for new (and useful) purposes so we will never be able to
get rid of it.

Note: I'm neither accepting nor rejecting the PEP; I'm merely inviting more
contemplation.

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

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

[Guido van Rossum]

I agree it's better to define the order as computed at runtime. I don't
think there's much of a point to mandate that all builtin/extension types
reveal their order too -- I doubt there will be many uses for that -- but I
don't want to disallow it either. But we can allow types to define this, as
long as it's in their documentation (so users can rely on it in those
cases).

As another point of review, I don't like the exception for dunder names. I
can see that __module__, __name__ etc. are distractions, but since you're
adding methods, you should also add methods with dunder names.

The overlap with PEP 487 makes me think that this feature is clearly
desirable (I like the name you give it in PEP 520 better, and PEP 487 is
too vague about its definition).

Finally, it seems someone is working on making all dicts ordered. Does that
mean this will soon be obsolete?

On Fri, Jun 17, 2016 at 6:32 PM, Nick Coghlan  wrote:

> On 7 June 2016 at 17:50, Eric Snow  wrote:
> > Why is __definition_order__ even necessary?
> > ---
> >
> > Since the definition order is not preserved in ``__dict__``, it would be
> > lost once class definition execution completes.  Classes *could*
> > explicitly set the attribute as the last thing in the body.  However,
> > then independent decorators could only make use of classes that had done
> > so.  Instead, ``__definition_order__`` preserves this one bit of info
> > from the class body so that it is universally available.
>
> The discussion in the PEP 487 thread made me realise that I'd like to
> see a discussion in PEP 520 regarding whether or not to define
> __definition_order__ for builtin types initialised via PyType_Ready or
> created via PyType_FromSpec in addition to defining it for types
> created via the class statement or types.new_class().
>
> For static types, PyType_Ready could potentially set it based on
> tp_members, tp_methods & tp_getset (see
> https://docs.python.org/3/c-api/typeobj.html )
> Similarly, PyType_FromSpec could potentially set it based on the
> contents of Py_tp_members, Py_tp_methods and Py_tp_getset slot
> definitions
>
> Having definition order support in both types.new_class() and builtin
> types would also make it clear why we can't rely purely on the
> compiler to provide the necessary ordering information - in both of
> those cases, the Python compiler isn't directly involved in the type
> creation process.
>
> 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/guido%40python.org
>



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

Re: [Python-Dev] security SIG?

[Ethan Furman]

On 06/19/2016 03:51 PM, Guido van Rossum wrote:


I think it's fine to have this SIG. I could see it going different ways
in terms of discussions and membership, but it's definitely worth a try.
I don't like clever names, and I very much doubt that it'll be mistaken
for an address to report sensitive issues, so I think it should just be
security-sig. (The sensitive-issues people are usually paranoid enough
to check before they post; the script kiddies reporting python.org
 "issues" probably will get a faster and more
appropriate response from the security-sig.)

So let's just do it.


Started the process of creating "security-sig".

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