date:20170911

On Mon, Sep 11, 2017 at 8:21 PM, Barry Warsaw  wrote:

> On Sep 11, 2017, at 19:16, Guido van Rossum  wrote:
> >
> > Or we could just have two arguments, eq= and order=, and
> some rule so that you only need to specify one or the other but not both.
> (E.g. order=True implies eq=True.) That seems better than needing new
> constants just for this flag.
>
> You’d have to disallow the combination `order=True, eq=False` then,
> right?  Or would you ignore eq for any value of order=True?  Seems like a
> clumsier API than a single tri-value parameter.  Do the module constants
> bother you that much?

Yes they do. You may have to import them, or you have to prefix them with
the module name -- whereas keyword args and True/False require neither.

We could disallow order=True, eq=True. Or we could have the default being
to generate __eq__, __ne__ and __hash__, and a flag to prevent these (since
equality by object identity is probably less popular than equality by
elementwise comparison).

Perhaps:

order: bool = False
eq: bool = True

and disallowing order=True, eq=False.

-- 
--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 557: Data Classes

On Sep 11, 2017, at 19:16, Guido van Rossum  wrote:
> 
> Or we could just have two arguments, eq= and order=, and some 
> rule so that you only need to specify one or the other but not both. (E.g. 
> order=True implies eq=True.) That seems better than needing new constants 
> just for this flag.

You’d have to disallow the combination `order=True, eq=False` then, right?  Or 
would you ignore eq for any value of order=True?  Seems like a clumsier API 
than a single tri-value parameter.  Do the module constants bother you that 
much?

-Barry

signature.asc
Description: Message signed with OpenPGP
___
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] Aaron Hall, Introduction and pull-request bump

2017-09-11 Thread Aaron Hall via Python-Dev

Hi there,
I have had the privilege of getting to know some core developers at PyCon in 
Portland, and I've met some others through my volunteering at PyGotham and the 
NYC Python meetup group (resisting urge to name-drop). 
In spite of not joining the mailing list until about a week ago at Brett 
Cannon's suggestion, I have managed to submit 3 bug-report fixes, with 1 closed 
by pull-request, 1 nearly closed with the pull-request accepted, and 1 with the 
pull request not yet accepted (looks like there's a conflict in misc/NEWS now, 
not sure how to use Github to resolve it either). That last pull request is 
here: bpo-26103 resolve Data descriptor contradiction by aaronchall · Pull 
Request #1959 · python/cpython - probably good if


|  |  | 
bpo-26103 resolve Data descriptor contr...
 |


I also had a "MutableNamedTuple" implementation I put on 
codereview.stackexchange.com 
(https://codereview.stackexchange.com/q/173045/23451) and Ashwini Chaudhury 
gave me some excellent pointers, and inspired by the recent discussion on "Data 
Classes" I now have a half-baked implementation that leverages __slots__ with a 
Mapping, for example (from a unittest, hence the indentation):
    class MNTDemo(MutableNamedTuple):
    "Demo"
    __slots__ = {
    'arg0': arg(),
    'arg1': arg(typing.List),
    'kwarg': arg(default=0), # must be positional if passed *args
    'args': arg(stars=Stars.ARGS),
    # everything after *args must be keyword argument
    'kwarg1': arg(list, []), 
    'kwarg2': None,
    'kwargs': arg(typing.Any, stars=Stars.KWARGS) 
    }
    mnt = MNTDemo(1, 2, 3, 'stararg1',
              kwarg1=1, kwarg2=2, kwarg3=3)
Maybe there's a nicer way to do it, but arg is a function returning a 
namedtuple (attrs: type, default, stars) with some defaults. It allows the 
__init__ to have required positional arguments and required named arguments, 
pretty much as flexible as a regular function signature, but communicated via 
__slots__. And thanks to the slots, they're every bit as performant as a 
namedtuple, I presume (I gave the __slots__ talk at PyCon).
Anyways, to wrap up my introduction, I'm a moderator on StackOverflow 
(https://stackoverflow.com/users/541136/aaron-hall?tab=profile) and nearly 
about to catch Raymond in reputation points, mostly due to Python, I'm 
currently teaching Python at NYU (Introduction to Programming), and I'm an 
all-around Python evangelist (as much as I know how to be.) I owe a lot to the 
Python community, especially the meetup community in NYC, but also virtual 
community (Ned Batchelder in IRC comes to mind). 
Thank you for everything, I'm looking for my chance to give back!
Cheers, 
Aaron Hall___
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 549: Instance Properties (aka: module properties)

On Mon, Sep 11, 2017 at 6:04 PM, Larry Hastings  wrote:

>
>
> On 09/11/2017 08:44 AM, Guido van Rossum wrote:
>
> I worry that in the end @property isn't general enough and the major use
> cases end up still having to use __class__ assignment, and then we'd have a
> fairly useless feature that we cant withdraw, ever.
>
>
> What can I say--I don't have that worry ;-)
>
> As previously mentioned in this thread, I counted up uses of property,
> __getattr__, and __getattribute__ in 3.7/Lib.  I grepped for the following
> strings, ignored pydoc_data/topics.py, and got these totals:
>
> "@property" 375 hits
> "def __getattr__" 28 hits
> "def __getattribute__(" 2 hits
>
> @property seems pretty popular.
>

I saw that the first time but it doesn't address my worry. (I don't feel
like explaining the worry again though, I feel I've done all I can.)


>
> Why is there no mechanism to add new descriptors that can work in this
>> context?
>>
>> I've updated the prototype to add one.  I added it as
>> "collections.abc.InstanceDescriptor"; that's a base class you can
>> inherit from, and then your descriptor will work in a module.  Bikeshedding
>> the name is fine.
>>
>
> I don't understand the question, or the answer. (And finding the prototype
> is taking longer than writing this email.)
>
>
> Ronald was basically asking: what about user classes?  The first revision
> of the prototype didn't provide a way to write your own instance
> descriptors.  The only thing that could be a instance descriptor was
> property.  So, I updated the prototype and added 
> collections.abc.InstanceDescriptor,
> a base class user classes can inherit from that lets them be instance
> descriptors.
>

I still don't follow. How does one use InstanceDescriptor? Is this still
about modules, or is it a generalization of properties for non-module
instances? (If it is specific to modules, why doesn't it have "module" in
its name? Or if it's not, why is it in this discussion?)


> The prototype is linked to from the PEP; for your convenience here's a
> link:
>
> https://github.com/larryhastings/cpython/tree/module-properties
>
> I found that link in the PEP, but it's just a branch of a fork of cpython.
It would be easier to review the prototype as a PR to upstream cpython.

-- 
--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 557: Data Classes

Or we could just have two arguments, eq= and order=, and some
rule so that you only need to specify one or the other but not both. (E.g.
order=True implies eq=True.) That seems better than needing new constants
just for this flag.

On Mon, Sep 11, 2017 at 6:49 PM, Barry Warsaw  wrote:

> On Sep 11, 2017, at 18:36, Eric V. Smith  wrote:
> > So if we don't do enums, I think the choices are ints, strs, or maybe
> True/False/None. Do you have a preference here?
> >
> > If int or str, I assume we'd want module-level constants.
> >
> > I like the name compare=, and 3 values makes sense: None, Equality,
> Ordered.
>
> +1 for the name, the 3 values, and making them module constants.  After
> that, I don’t think it really matters what their implementation is.  User
> code will look the same either way.  One minor nice effect of using an enum
> is that the dataclass function can use `is` instead of `==` to compare
> keyword argument values.
>
> -Barry
>
>
> ___
> 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] breakpoint() and $PYTHONBREAKPOINT

2017-09-11 Thread Nathaniel Smith

On Mon, Sep 11, 2017 at 6:45 PM, Barry Warsaw  wrote:
> On Sep 11, 2017, at 18:15, Nathaniel Smith  wrote:
>
>> Compared to checking it on each call to sys.breakpointhook(), I guess
>> the two user-visible differences in behavior would be:
>>
>> - whether mutating os.environ["PYTHONBREAKPOINT"] inside the process
>> affects future calls. I would find it quite surprising if it did;
>
> Maybe, but the effect would be essentially the same as setting 
> sys.breakpointhook during the execution of your program.
>
>> - whether the import happens immediately at startup, or is delayed
>> until the first call to breakpoint().
>
> I definitely think it should be delayed until first use.  You might never hit 
> the breakpoint() in which case you wouldn’t want to pay any penalty for even 
> checking the environment variable.  And once you *do* hit the breakpoint(), 
> you aren’t caring about performance then anyway.
>
> Both points could be addressed by caching the import after the first lookup, 
> but even there I don’t think it’s worth it.  I’d invoke KISS and just look it 
> up anew each time.  That way there’s no global/static state to worry about, 
> and the feature is as flexible as it can be.
>
>> If it's imported once at
>> startup, then this adds overhead to programs that set PYTHONBREAKPOINT
>> but don't use it, and if the envvar is set to some nonsense then you
>> get an error immediately instead of at the first call to breakpoint().
>
> That’s one case I can see being useful; report an error immediately upon 
> startup rather that when you hit breakpoint().  But even there, I’m not sure. 
>  What if you’ve got some kind of dynamic debugger discovery thing going on, 
> such that the callable isn’t available until its first use?

I don't think that's a big deal? Just do the discovery logic from
inside the callable itself, instead of using some kind of magical
attribute lookup hook.

>> These both seem like fairly minor differences to me, but maybe saving
>> that 30 ms or whatever of startup time is an important enough
>> optimization to justify the special case?
>
> I’m probably too steeped in the implementation, but it feels to me like not 
> just loading the envar callable on demand makes reasoning about and using 
> this more complicated.  I think for most uses though, it won’t really matter.

I don't mind breaking from convention if you have a good reason, I
just like it for PEPs to actually write down that reasoning :-)

-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

[Python-Dev] Python vulnerabilities

2017-09-11 Thread Stephen Michell

I am new to this list. 

Skip suggested that I join. 

I convene ISO/IEC/JTC1SC22/WG23 Programming Languages Working Group. We produce 
a suite of international technical reports that document vulnerabilities in 
programming that can lead to serious safety and security breaches. 

We published TR 24772 "Guidance to avoiding programming language 
vulnerabilities through language selection and use" in 2010 and again in 2013. 
Edition one was a language independent look at such vulnerabilities. Edition 
two added new vulnerabilities plus language specific annexes for Ada, C, 
Python, PHP, Ruby, and Spark. 

For this round, we have split the document into parts and are publishing the 
language specific parts separately. We have added a few new vulnerabilities, 
mostly associated with concurrency and object orientation for this iteration. 

We target the team lead that guides and writes coding standards for an 
organization, as opposed to the general programmer. 

We plan to ballot and publish in 2018 TR 24772-1, the language independent 
Part, as well as -2 Ada, -3 C, -4 Python and -8 Fortran. 

Our Python Part needs completion to address the new vulnerabilities documented. 
We want to do justice to all languages that we work with. We need experts to 
help us complete the document, and then to review it. I have had initial 
conversations with one expert. We hope for a bit more if possible. I

If interested, please contact me as listed below. 

Our document list is at www.open-std.org/JTC1/sc22/wg23. 

Thank you. 

Stephen Michell
Maurya Software
stephen dot michell at maurya dot on dot ca
Phone: 1-613-299-9047___
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 549: Instance Properties (aka: module properties)

2017-09-11 Thread Ethan Furman


On 09/06/2017 08:26 AM, Guido van Rossum wrote:


So we've seen a real use case for __class__ assignment: deprecating things on 
access. That use case could also be solved
if modules natively supported defining __getattr__ (with the same "only used if 
attribute not found otherwise" semantics
as it has on classes), but it couldn't be solved using @property (or at least 
it would be quite hacky).

Is there a real use case for @property? Otherwise, if we're going to mess with 
module's getattro, it makes more sense to
add __getattr__, which would have made Nathaniel's use case somewhat simpler. 
(Except for the __dir__ thing -- what else
might we need?)


Doesn't assigning a module's __class__ make it so we can already write properties, descriptors, __getattr__, etc. ?  Are 
these other things so common that we need /more/ syntax for them?


--
~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 557: Data Classes

On Sep 11, 2017, at 18:36, Eric V. Smith  wrote:
> So if we don't do enums, I think the choices are ints, strs, or maybe 
> True/False/None. Do you have a preference here?
> 
> If int or str, I assume we'd want module-level constants.
> 
> I like the name compare=, and 3 values makes sense: None, Equality, Ordered.

+1 for the name, the 3 values, and making them module constants.  After that, I 
don’t think it really matters what their implementation is.  User code will 
look the same either way.  One minor nice effect of using an enum is that the 
dataclass function can use `is` instead of `==` to compare keyword argument 
values.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] breakpoint() and $PYTHONBREAKPOINT

On Sep 11, 2017, at 18:15, Nathaniel Smith  wrote:

> Compared to checking it on each call to sys.breakpointhook(), I guess
> the two user-visible differences in behavior would be:
> 
> - whether mutating os.environ["PYTHONBREAKPOINT"] inside the process
> affects future calls. I would find it quite surprising if it did;

Maybe, but the effect would be essentially the same as setting 
sys.breakpointhook during the execution of your program.

> - whether the import happens immediately at startup, or is delayed
> until the first call to breakpoint().

I definitely think it should be delayed until first use.  You might never hit 
the breakpoint() in which case you wouldn’t want to pay any penalty for even 
checking the environment variable.  And once you *do* hit the breakpoint(), you 
aren’t caring about performance then anyway.

Both points could be addressed by caching the import after the first lookup, 
but even there I don’t think it’s worth it.  I’d invoke KISS and just look it 
up anew each time.  That way there’s no global/static state to worry about, and 
the feature is as flexible as it can be.

> If it's imported once at
> startup, then this adds overhead to programs that set PYTHONBREAKPOINT
> but don't use it, and if the envvar is set to some nonsense then you
> get an error immediately instead of at the first call to breakpoint().

That’s one case I can see being useful; report an error immediately upon 
startup rather that when you hit breakpoint().  But even there, I’m not sure.  
What if you’ve got some kind of dynamic debugger discovery thing going on, such 
that the callable isn’t available until its first use?

> These both seem like fairly minor differences to me, but maybe saving
> that 30 ms or whatever of startup time is an important enough
> optimization to justify the special case?

I’m probably too steeped in the implementation, but it feels to me like not 
just loading the envar callable on demand makes reasoning about and using this 
more complicated.  I think for most uses though, it won’t really matter.

Cheers,
-Barry

signature.asc
Description: Message signed with OpenPGP
___
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 557: Data Classes


On 9/11/2017 6:28 PM, Guido van Rossum wrote:
Oddly I don't like the enum (flag names get too long that way), but I do 
agree with everything else Barry said (it should be a trivalue flag and 
please don't name it cmp).


So if we don't do enums, I think the choices are ints, strs, or maybe 
True/False/None. Do you have a preference here?


If int or str, I assume we'd want module-level constants.

I like the name compare=, and 3 values makes sense: None, Equality, Ordered.

Eric.



On Mon, Sep 11, 2017 at 3:16 PM, Ethan Furman > wrote:


On 09/11/2017 03:00 PM, Barry Warsaw wrote:

On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:


I've sometimes wished that attrs let me control whether it
generated equality methods (eq/ne/hash) separately from
ordering methods (lt/gt/...). Maybe the cmp= argument should
take an enum with options none/equality-only/full?


I have had use cases where I needed equality comparisons but not
ordered comparisons, so I’m in favor of the option to split
them.  (atm, I can’t bring up a specific case, but it’s not
uncommon.)

Given that you only want to support the three states that
Nathaniel describes, I think an enum makes the most sense, and
it certainly would read well.  I.e. there’s no sense in
supporting the ordered comparisons and not equality, so that’s
not a state that needs to be represented.

I’d make one other suggestion here: please let’s not call the
keyword `cmp`.  That’s reminiscent of Python 2’s `cmp` built-in,
which of course doesn’t exist in Python 3.  Using `cmp` is just
an unnecessarily obfuscating abbreviation.  I’d suggest just
`compare` with an enum like so:

enum Compare(enum.Enum):
      none = 1
      unordered = 2
      ordered = 3


I like the enum idea (suprise! ;) but I would suggest "equal" or
"equivalent" instead of "unordered"; better to say what they are
rather than what they are not.

--
~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/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/eric%2Ba-python-dev%40trueblade.com



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

Re: [Python-Dev] PEP 557: Data Classes


On 9/11/2017 12:34 PM, Nathaniel Smith wrote:

On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith  wrote:

On 9/10/17 11:08 PM, Nathaniel Smith wrote:

Why do you even have a hash= argument on individual fields? For the
whole class, I can imagine you might want to explicitly mark a whole
class as unhashable, but it seems like the only thing you can do with
the field-level hash= argument is to create a class where the __hash__
and __eq__ take different fields into account, and why would you ever
want that?



The use case is that you have a cache, or something similar, that doesn't
affect the object identity.


But wouldn't this just be field(cmp=False), no need to fiddle with hash=?


Ah, true. You're right, I can't see any good use for setting hash on a 
field that isn't already controlled by cmp. I think field level hash can go.



Though honestly I can see a reasonable argument for removing the
class-level hash= option too. And even if you keep it you might want to
error on some truly nonsensical options like defining __hash__ without
__eq__. (Also watch out that Python's usual rule about defining __eq__
blocking the inheritance of __hash__ does not kick in if __eq__ is added
after the class is created.)


At the class level, I think it makes more sense. But I'll write up some 
motivating examples.

I've sometimes wished that attrs let me control whether it generated
equality methods (eq/ne/hash) separately from ordering methods
(lt/gt/...). Maybe the cmp= argument should take an enum with options
none/equality-only/full?



Yeah, I've thought about this, too. But I don't have any use case in mind,
and if it hasn't come up with attrs, then I'm reluctant to break new ground
here.


https://github.com/python-attrs/attrs/issues/170

 From that thread, it feels like part of the problem is that it's
awkward to encode this using only boolean arguments, but they're sort
of stuck with that for backcompat with how they originally defined
cmp=, hence my suggestion to consider making it an enum from the start
:-).


I'll respond to other emails about this, probably tomorrow.

Eric.


The "why not attrs" section kind of reads like "because it's too popular
and useful"?



I'll add some words to that section, probably focused on typing
compatibility. My general feeling is that attrs has some great design
decisions, but goes a little too far (e.g., conversions, validations). As
with most things we add, I'm trying to be as minimalist as possible, while
still being widely useful and allowing 3rd party extensions and future
features.


If the question is "given that we're going to add something to the
stdlib, why shouldn't that thing be attrs?" then I guess it's
sufficient to say "because the attrs developers didn't want it". But I
think the PEP should also address the question "why are we adding
something to the stdlib, instead of just recommending people install
attrs".

-n
___
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/eric%2Ba-python-dev%40trueblade.com



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

Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT

2017-09-11 Thread Nathaniel Smith

On Mon, Sep 11, 2017 at 5:27 PM, Barry Warsaw  wrote:
> On Sep 10, 2017, at 13:46, Nathaniel Smith  wrote:
>>
>> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw  wrote:
>>> For PEP 553, I think it’s a good idea to support the environment variable 
>>> $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get 
>>> some feedback.
>>>
>>> Should $PYTHONBREAKPOINT be consulted in breakpoint() or in 
>>> sys.breakpointhook()?
>>
>> Wouldn't the usual pattern be to check $PYTHONBREAKPOINT once at
>> startup, and if it's set use it to initialize sys.breakpointhook()?
>> Compare to, say, $PYTHONPATH.
>
> Perhaps, but what would be the visible effects of that?  I.e. what would that 
> buy you?

Why is this case special enough to break the rules?

Compared to checking it on each call to sys.breakpointhook(), I guess
the two user-visible differences in behavior would be:

- whether mutating os.environ["PYTHONBREAKPOINT"] inside the process
affects future calls. I would find it quite surprising if it did;
generally when we mutate envvars like os.environ["PYTHONPATH"] it's a
way to set things up for future child processes and doesn't affect our
process.

- whether the import happens immediately at startup, or is delayed
until the first call to breakpoint(). If it's imported once at
startup, then this adds overhead to programs that set PYTHONBREAKPOINT
but don't use it, and if the envvar is set to some nonsense then you
get an error immediately instead of at the first call to breakpoint().
These both seem like fairly minor differences to me, but maybe saving
that 30 ms or whatever of startup time is an important enough
optimization to justify the special case?

-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] PEP 549: Instance Properties (aka: module properties)

2017-09-11 Thread Larry Hastings




On 09/11/2017 08:44 AM, Guido van Rossum wrote:
I worry that in the end @property isn't general enough and the major 
use cases end up still having to use __class__ assignment, and then 
we'd have a fairly useless feature that we cant withdraw, ever.


What can I say--I don't have that worry ;-)

As previously mentioned in this thread, I counted up uses of property, 
__getattr__, and __getattribute__ in 3.7/Lib.  I grepped for the 
following strings, ignored pydoc_data/topics.py, and got these totals:


   "@property" 375 hits
   "def __getattr__" 28 hits
   "def __getattribute__(" 2 hits

@property seems pretty popular.



Why is there no mechanism to add new descriptors that can work in
this context?

I've updated the prototype to add one.  I added it as
"collections.abc.InstanceDescriptor"; that's a base class you can
inherit from, and then your descriptor will work in a module. 
Bikeshedding the name is fine.


I don't understand the question, or the answer. (And finding the 
prototype is taking longer than writing this email.)


Ronald was basically asking: what about user classes?  The first 
revision of the prototype didn't provide a way to write your own 
instance descriptors.  The only thing that could be a instance 
descriptor was property.  So, I updated the prototype and added 
collections.abc.InstanceDescriptor, a base class user classes can 
inherit from that lets them be instance descriptors.


The prototype is linked to from the PEP; for your convenience here's a link:

   https://github.com/larryhastings/cpython/tree/module-properties


//arry/
___
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] breakpoint() and $PYTHONBREAKPOINT

On Sep 10, 2017, at 13:46, Nathaniel Smith  wrote:
> 
> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw  wrote:
>> For PEP 553, I think it’s a good idea to support the environment variable 
>> $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get 
>> some feedback.
>> 
>> Should $PYTHONBREAKPOINT be consulted in breakpoint() or in 
>> sys.breakpointhook()?
> 
> Wouldn't the usual pattern be to check $PYTHONBREAKPOINT once at
> startup, and if it's set use it to initialize sys.breakpointhook()?
> Compare to, say, $PYTHONPATH.

Perhaps, but what would be the visible effects of that?  I.e. what would that 
buy you?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] breakpoint() and $PYTHONBREAKPOINT

On Sep 10, 2017, at 12:16, Guido van Rossum  wrote:
> 
> I think programmatic overrides should be able to decide for themselves if 
> they want to honor PYTHONBREAKPOINT or not, since I can imagine use cases 
> that go both ways. So it should be checked in sys.breakpointhook().

Thanks Guido, I’ll implement it this way in my PR and update the PEP.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 557: Data Classes



On 2017-09-11 17:00, Barry Warsaw wrote:


I’ve used ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib.


Well, "the Pythons" were irreverent, were they not?  ;)

-Mike

___
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 557: Data Classes

On Sep 11, 2017, at 16:51, Mike Miller  wrote:
> 
> On 2017-09-11 05:26, Eric V. Smith wrote:
>> On 9/10/17 10:27 PM, Raymond Hettinger wrote:
> 
> I've typically used these type of objects as records.  When in an irreverent 
> mood I've called them bags.

I’ve used ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 557: Data Classes



On 2017-09-11 05:26, Eric V. Smith wrote:

On 9/10/17 10:27 PM, Raymond Hettinger wrote:


I've typically used these type of objects as records.  When in an irreverent 
mood I've called them bags.  The short name is helpful as they get used all over 
the place.  I'll add Nick's "declarative" as it describes the problem well from 
another angle:


- record
- bag
- declarative

Anyone like these?  I find them more intuitive than the existing name.

Also, considering their uses, it might make sense to put them in the collections 
module.


-Mike
___
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 557: Data Classes




On 2017-09-10 18:20, Eric V. Smith wrote:

I'll think about adding some more language to the PEP about it.


Agreed, was only looking for mention or example that a specific type was not 
required.  Perhaps even dusting off the word "annotation" to describe them.


___
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 557: Data Classes




On 2017-09-10 23:38, Michel Desmoulin wrote:

I'm going to put some words in explaining why I don't want to use base
classes (I don't think it buys you anything). Do you have a reason for
preferring base classes?


Not preferring, but having it as an alternative. Mainly for 2 reasons:

1 - data classes allow one to type in classes very quickly, let's
harvest the benefit from that.

Typing a decorator in a shell is much less comfortable than using
inheritance. Same thing about IDE: all current ones have snippet with
auto-switch to the class parents on tab.

All in all, if you are doing exploratory programming, and thus
disposable code, which data classes are fantastic for, inheritance will
keep you in the flow.

2 - it will help sell the data classes

I train a lot of people to Python each year. I never have to explain
classes to people with any kind of programming background. I _always_
have to explain decorators.

People are not used to it, and even kind fear it for quite some time.

Inheritance however, is familiar, and will not only push people to use
data classes more, but also will let them do less mistakes: they know
the danger of parent ordering, but not the ones of decorators ordering.


I also feel inheritance is more intuitive (and easily entered), but missed the 
reason it wasn't chosen.  ;)


-Mike

___
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 557: Data Classes

On Sep 11, 2017, at 15:16, Ethan Furman  wrote:
>> 
>> enum Compare(enum.Enum):
>> none = 1
>> unordered = 2
>> ordered = 3
> 
> I like the enum idea (suprise! ;) but I would suggest "equal" or "equivalent" 
> instead of "unordered"; better to say what they are rather than what they are 
> not.

The language reference calls them “equality” comparisons, so maybe that’s the 
term we should use.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 557: Data Classes

Oddly I don't like the enum (flag names get too long that way), but I do
agree with everything else Barry said (it should be a trivalue flag and
please don't name it cmp).

On Mon, Sep 11, 2017 at 3:16 PM, Ethan Furman  wrote:

> On 09/11/2017 03:00 PM, Barry Warsaw wrote:
>
>> On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:
>>
>>>
>>> I've sometimes wished that attrs let me control whether it generated
>>> equality methods (eq/ne/hash) separately from ordering methods (lt/gt/...).
>>> Maybe the cmp= argument should take an enum with options
>>> none/equality-only/full?
>>>
>>
>> I have had use cases where I needed equality comparisons but not ordered
>> comparisons, so I’m in favor of the option to split them.  (atm, I can’t
>> bring up a specific case, but it’s not uncommon.)
>>
>> Given that you only want to support the three states that Nathaniel
>> describes, I think an enum makes the most sense, and it certainly would
>> read well.  I.e. there’s no sense in supporting the ordered comparisons and
>> not equality, so that’s not a state that needs to be represented.
>>
>> I’d make one other suggestion here: please let’s not call the keyword
>> `cmp`.  That’s reminiscent of Python 2’s `cmp` built-in, which of course
>> doesn’t exist in Python 3.  Using `cmp` is just an unnecessarily
>> obfuscating abbreviation.  I’d suggest just `compare` with an enum like so:
>>
>> enum Compare(enum.Enum):
>>  none = 1
>>  unordered = 2
>>  ordered = 3
>>
>
> I like the enum idea (suprise! ;) but I would suggest "equal" or
> "equivalent" instead of "unordered"; better to say what they are rather
> than what they are not.
>
> --
> ~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/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] PEP 557: Data Classes

2017-09-11 Thread Ethan Furman

On 09/11/2017 03:00 PM, Barry Warsaw wrote:

On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:

I've sometimes wished that attrs let me control whether it generated equality
methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the
cmp= argument should take an enum with options none/equality-only/full?

I have had use cases where I needed equality comparisons but not ordered
comparisons, so I’m in favor of the option to split them. (atm, I can’t bring
up a specific case, but it’s not uncommon.)

Given that you only want to support the three states that Nathaniel describes,
I think an enum makes the most sense, and it certainly would read well. I.e.
there’s no sense in supporting the ordered comparisons and not equality, so
that’s not a state that needs to be represented.

I’d make one other suggestion here: please let’s not call the keyword `cmp`.
That’s reminiscent of Python 2’s `cmp` built-in, which of course doesn’t exist
in Python 3. Using `cmp` is just an unnecessarily obfuscating abbreviation.
I’d suggest just `compare` with an enum like so:

enum Compare(enum.Enum):
none = 1
unordered = 2
ordered = 3

I like the enum idea (suprise! ;) but I would suggest "equal" or "equivalent" instead of "unordered"; better to say what
they are rather than what they are not.

--
~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 557: Data Classes

On Sep 10, 2017, at 20:08, Nathaniel Smith  wrote:
> 
> I've sometimes wished that attrs let me control whether it generated equality 
> methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the 
> cmp= argument should take an enum with options none/equality-only/full?

I have had use cases where I needed equality comparisons but not ordered 
comparisons, so I’m in favor of the option to split them.  (atm, I can’t bring 
up a specific case, but it’s not uncommon.)

Given that you only want to support the three states that Nathaniel describes, 
I think an enum makes the most sense, and it certainly would read well.  I.e. 
there’s no sense in supporting the ordered comparisons and not equality, so 
that’s not a state that needs to be represented.

I’d make one other suggestion here: please let’s not call the keyword `cmp`.  
That’s reminiscent of Python 2’s `cmp` built-in, which of course doesn’t exist 
in Python 3.  Using `cmp` is just an unnecessarily obfuscating abbreviation.  
I’d suggest just `compare` with an enum like so:

enum Compare(enum.Enum):
none = 1
unordered = 2
ordered = 3

One thing I can’t avoid is DRY:

from dataclasses import Compare, dataclass

@dataclass(compare=Compare.unordered)
class Foo:
# …

Maybe exposing the enum items in the module namespace?

——dataclasses/__init__.py-
from enum import Enum

class Compare(Enum):
none = 1
unordered = 2
ordered =3

none = Compare.none
unordered = Compare.unordered
ordered = Compare.ordered
——dataclasses/__init__.py-

from dataclasses import dataclass, unordered

@dataclass(compare=unordered)
class Foo:
# …

Cheers,
-Barry

signature.asc
Description: Message signed with OpenPGP
___
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 549: Instance Properties (aka: module properties)

2017-09-11 Thread Chris Barker

On Mon, Sep 11, 2017 at 10:20 AM, Victor Stinner 
wrote:

> 2017-09-11 19:00 GMT+02:00 Chris Barker :
> > There are a heck of a lot in the os module:
> > ['get_blocking',
>
> This one is not a good example: it takes a parameter. You cannot
> convert it to a property.
>

I'm sure there are many that really do have a good reason for a getter
function, but not all, by any means.

When designing an API, when I have to choose between property and
> function/method, I prefer function/method over a property when the
> code is slow, especially at the first call.
>
> I prefer to "warn" users than a call (like the first one which fills a
> cache) can be slow.
>
> Well, it's not a strong rule, sometimes I use a property even if the
> first call has to fill a cache :-)
>
> Here the sysconfig has to build an internal cache at the first call
> ... if I recall correctly.
>

If we do get properties on modules, then there is plenty of room to discuss
best API for  a given functionality. And chances are, we won't gratuitously
re-factor the standard library.

But your point is well taken, and makes my point in a way -- if we had
properties, then there would be a getter function only if there was a good
reason for it. As it stands, I have no idea if calling, for instance,
sysconfig.get_config_vars is an expensive operation.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

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

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

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

2017-09-11 Thread Victor Stinner

2017-09-11 19:00 GMT+02:00 Chris Barker :
> I wish there were a property feature available almost very time I encounter
> a "get*" method in the stdlib (or any where):
>
> There are a heck of a lot in the os module:
>
> In [4]: [s for s in dir(os) if s.startswith('get')]
> Out[4]:
>
> ['get_blocking',

This one is not a good example: it takes a parameter. You cannot
convert it to a property.

>  'getcwd',

> And just yesterday I was getting annoyed by some in sysconfig:
>
> In [6]: [s for s in dir(sysconfig)  if s.startswith('get')]
> Out[6]:
>
> ['get_config_h_filename',
>  'get_config_var',
>  'get_config_vars',
>  'get_makefile_filename',
>  'get_path',
>  'get_path_names',
>  'get_paths',
>  'get_platform',
>  'get_python_version',
>  'get_scheme_names']

When designing an API, when I have to choose between property and
function/method, I prefer function/method over a property when the
code is slow, especially at the first call.

I prefer to "warn" users than a call (like the first one which fills a
cache) can be slow.

Well, it's not a strong rule, sometimes I use a property even if the
first call has to fill a cache :-)

Here the sysconfig has to build an internal cache at the first call
... if I recall correctly.

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

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

2017-09-11 Thread Chris Barker

On Thu, Sep 7, 2017 at 3:49 PM, Larry Hastings  wrote:

>  But I can cite at least one place in the standard library that would have
> been better if it'd been implemented as a module property:
>
os.stat_float_times().
>
I wish there were a property feature available almost very time I encounter
a "get*" method in the stdlib (or any where):

There are a heck of a lot in the os module:

In [4]: [s for s in dir(os) if s.startswith('get')]
Out[4]:

['get_blocking',
 'get_exec_path',
 'get_inheritable',
 'get_terminal_size',
 'getcwd',
 'getcwdb',
 'getegid',
 'getenv',
 'getenvb',
 'geteuid',
 'getgid',
 'getgrouplist',
 'getgroups',
 'getloadavg',
 'getlogin',
 'getpgid',
 'getpgrp',
 'getpid',
 'getppid',
 'getpriority',
 'getsid',
 'getuid']

Many of those may be good use-cases for getters, but still...

And just yesterday I was getting annoyed by some in sysconfig:

In [6]: [s for s in dir(sysconfig)  if s.startswith('get')]
Out[6]:

['get_config_h_filename',
 'get_config_var',
 'get_config_vars',
 'get_makefile_filename',
 'get_path',
 'get_path_names',
 'get_paths',
 'get_platform',
 'get_python_version',
 'get_scheme_names']

modules serve the very useful function of a global singleton -- if we think
properties are a good idea for classes, then they are a good idea for
modules...

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

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

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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-11 Thread Nathaniel Smith

On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith  wrote:
> On 9/10/17 11:08 PM, Nathaniel Smith wrote:
>>
>> Hi Eric,
>>
>> A few quick comments:
>>
>> Why do you even have a hash= argument on individual fields? For the
>> whole class, I can imagine you might want to explicitly mark a whole
>> class as unhashable, but it seems like the only thing you can do with
>> the field-level hash= argument is to create a class where the __hash__
>> and __eq__ take different fields into account, and why would you ever
>> want that?
>
>
> The use case is that you have a cache, or something similar, that doesn't
> affect the object identity.

But wouldn't this just be field(cmp=False), no need to fiddle with hash=?

>> Though honestly I can see a reasonable argument for removing the
>> class-level hash= option too. And even if you keep it you might want to
>> error on some truly nonsensical options like defining __hash__ without
>> __eq__. (Also watch out that Python's usual rule about defining __eq__
>> blocking the inheritance of __hash__ does not kick in if __eq__ is added
>> after the class is created.)
>>
>> I've sometimes wished that attrs let me control whether it generated
>> equality methods (eq/ne/hash) separately from ordering methods
>> (lt/gt/...). Maybe the cmp= argument should take an enum with options
>> none/equality-only/full?
>
>
> Yeah, I've thought about this, too. But I don't have any use case in mind,
> and if it hasn't come up with attrs, then I'm reluctant to break new ground
> here.

https://github.com/python-attrs/attrs/issues/170

>From that thread, it feels like part of the problem is that it's
awkward to encode this using only boolean arguments, but they're sort
of stuck with that for backcompat with how they originally defined
cmp=, hence my suggestion to consider making it an enum from the start
:-).

>> The "why not attrs" section kind of reads like "because it's too popular
>> and useful"?
>
>
> I'll add some words to that section, probably focused on typing
> compatibility. My general feeling is that attrs has some great design
> decisions, but goes a little too far (e.g., conversions, validations). As
> with most things we add, I'm trying to be as minimalist as possible, while
> still being widely useful and allowing 3rd party extensions and future
> features.

If the question is "given that we're going to add something to the
stdlib, why shouldn't that thing be attrs?" then I guess it's
sufficient to say "because the attrs developers didn't want it". But I
think the PEP should also address the question "why are we adding
something to the stdlib, instead of just recommending people install
attrs".

-n
___
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 557: Data Classes

On Mon, Sep 11, 2017 at 6:51 AM, Eric V. Smith  wrote:

> On 9/11/17 9:43 AM, tds...@mailbox.org wrote:
>
>> Hi Eric,
>>
>> I have on question not addressed yet.
>> The implementation is based on "__annotations__" where the type is
>> specified.
>> But "__annotations__" is not always filled. An interpreter version with
>> special optimization
>> could remove all __annotations__ for performance reasons. (Discussed in
>> other threads)
>>
>> In this case the dataclass does not work or will there be a fallback?
>>
>> I know it is a little bit hypothetical because an interpreter with this
>> optimization is
>> not there yet. I am looking only in the future a bit.
>> Asking this because type annotations are stated as completely optional
>> for Python.
>> And this use case will break this assumption.
>>
>
> Yes, if there are no __annotations__, then Data Classes would break.
> typing.NamedTuple has the same issue. We discussed it a little bit last
> week, but I don't think we came to any conclusions.
>
> Since @dataclass ignores the value of the annotation (except for
> typing.ClassVar), it would continue to work if the type was present, buy
> maybe mapped to None or similar.
>

Let's not worry about a future where there's no __annotations__. Type
annotations will gradually become more mainstream. You won't have to use
them, but some newer features of the language will be inaccessible if you
don't. This has already started with the pattern based on inheriting from
typing.NamedTuple and using field annotations. Dataclasses are simply
another example.

(That said, I strongly oppose *runtime type checking* based on annotations.
It's by and large a mistaken idea. But this has nothing to do with that.)

-- 
--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 549: Instance Properties (aka: module properties)

On Sun, Sep 10, 2017 at 8:52 PM, Larry Hastings  wrote:
>
> On 09/06/2017 02:13 PM, Ronald Oussoren wrote:
>
> To be honest this sounds like a fairly crude hack. Updating the __class__
> of a module object feels dirty, but at least you get normal behavior w.r.t.
> properties.
>
> Okay.  Obviously I disagree, I think it's reasonable.  But I'll assume
> you're -1.
>

I'm still poindering this. I am far from decided about whether it's better
to just add @property support, or whether we should add __getattr__ instead
(it can do everything @property can do, plus other things, but the
@property support would be a little clumsier), or everything that a class
can do with attributes (e.g. __getattribute__, __dir__, __setattr__), or
leave things alone (__class__ assignment can solve everything).

I worry that in the end @property isn't general enough and the major use
cases end up still having to use __class__ assignment, and then we'd have a
fairly useless feature that we cant withdraw, ever.

> Why is there no mechanism to add new descriptors that can work in this
> context?
>
> I've updated the prototype to add one.  I added it as 
> "collections.abc.InstanceDescriptor";
> that's a base class you can inherit from, and then your descriptor will
> work in a module.  Bikeshedding the name is fine.
>

I don't understand the question, or the answer. (And finding the prototype
is taking longer than writing this email.)

> BTW. The interaction with import is interesting… Module properties only
> work as naive users expect when accessing them as attributes of the module
> object, in particular importing the name using “from module import prop”
> would only call the property getter once and that may not be the intended
> behavior.
>
> I spent a fair amount of time thinking about this.  The short answer is:
> we *could* fix it.  We *could* make it so that "from x import y", when
> x.y is an instance descriptor, ensures that y honors the descriptor
> protocol when referenced.  We'd have to do it for three contexts:
>
>- global scope (aka module scope)
>- class scope
>- function scope
>
> The first two are pretty similar; create a proxy object that retains the
> module instance so it remains "bound" to that.  The third one is trickier;
> it'd mean a new bytecode (LOAD_FAST_DESCRIPTOR), but it wouldn't slow down
> people who didn't use it.
>
> Anyway, long story short, I think this would be worse than simply having
> "from x import y" only calling the getter once.  As the Zen says: special
> cases aren't special enough to break the rules.
>

I agree -- let's please not fix this, it's way too complicated for
something that started out as a nice localized tweak. When we write "from x
import y" we already voluntarily give up seeing any later assignments to
x.y. If this prevents a certain use case for lazy import, then so be it --
I don't think lazy import can ever be made so transparent that everything
will work lazily without understanding the difference between lazy and
eager import. (People already have to understand many subtleties of import,
e.g. the difference between import and loading, and how circular imports
work.)

-- 
--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] Fwd: Python programming language vulnerabilities

2017-09-11 Thread Victor Stinner

2017-09-10 11:42 GMT+02:00 Skip Montanaro :
> I chair ISO/IEC/JTC1/SC22/WG23 Programming Language Vulnerabilities. We
> publish an international technical report, ISO IEC TR 24772 Guide to
> avoiding programming language vulnerabilities through language selection
> use. Annex D in this document addresses vulnerabilities in Python. This
> document is freely available from ISO and IEC.

Does someone know where these documents can be found? (URL)

I can link them from my http://python-security.readthedocs.io/ documentation.

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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-11 Thread tds333

Hi Eric,

I have on question not addressed yet.
The implementation is based on "__annotations__" where the type is specified.
But "__annotations__" is not always filled. An interpreter version with special 
optimization
could remove all __annotations__ for performance reasons. (Discussed in other 
threads)

In this case the dataclass does not work or will there be a fallback?

I know it is a little bit hypothetical because an interpreter with this 
optimization is
not there yet. I am looking only in the future a bit.
Asking this because type annotations are stated as completely optional for 
Python.
And this use case will break this assumption.

Personally I am a heavy user of attrs and happy to have a dataclass in the std 
lib.

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

Re: [Python-Dev] PEP 557: Data Classes


On 9/11/17 9:43 AM, tds...@mailbox.org wrote:

Hi Eric,

I have on question not addressed yet.
The implementation is based on "__annotations__" where the type is specified.
But "__annotations__" is not always filled. An interpreter version with special 
optimization
could remove all __annotations__ for performance reasons. (Discussed in other 
threads)

In this case the dataclass does not work or will there be a fallback?

I know it is a little bit hypothetical because an interpreter with this 
optimization is
not there yet. I am looking only in the future a bit.
Asking this because type annotations are stated as completely optional for 
Python.
And this use case will break this assumption.


Yes, if there are no __annotations__, then Data Classes would break. 
typing.NamedTuple has the same issue. We discussed it a little bit last 
week, but I don't think we came to any conclusions.


Since @dataclass ignores the value of the annotation (except for 
typing.ClassVar), it would continue to work if the type was present, buy 
maybe mapped to None or similar.


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 557: Data Classes


On 9/10/17 11:08 PM, Nathaniel Smith wrote:

Hi Eric,

A few quick comments:

Why do you even have a hash= argument on individual fields? For the
whole class, I can imagine you might want to explicitly mark a whole
class as unhashable, but it seems like the only thing you can do with
the field-level hash= argument is to create a class where the __hash__
and __eq__ take different fields into account, and why would you ever
want that?


The use case is that you have a cache, or something similar, that 
doesn't affect the object identity.



Though honestly I can see a reasonable argument for removing the
class-level hash= option too. And even if you keep it you might want to
error on some truly nonsensical options like defining __hash__ without
__eq__. (Also watch out that Python's usual rule about defining __eq__
blocking the inheritance of __hash__ does not kick in if __eq__ is added
after the class is created.)

I've sometimes wished that attrs let me control whether it generated
equality methods (eq/ne/hash) separately from ordering methods
(lt/gt/...). Maybe the cmp= argument should take an enum with options
none/equality-only/full?


Yeah, I've thought about this, too. But I don't have any use case in 
mind, and if it hasn't come up with attrs, then I'm reluctant to break 
new ground here.



The "why not attrs" section kind of reads like "because it's too popular
and useful"?


I'll add some words to that section, probably focused on typing 
compatibility. My general feeling is that attrs has some great design 
decisions, but goes a little too far (e.g., conversions, validations). 
As with most things we add, I'm trying to be as minimalist as possible, 
while still being widely useful and allowing 3rd party extensions and 
future features.


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 557: Data Classes