[Python-Dev] Why aren't decorators just expressions?

2017-09-16 Thread Larry Hastings 



The syntax for decorators in the grammar is quite specific:

   decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE

Decorators can be either a dotted name, or a dotted name followed by 
arguments.  This disallows:


   @mapping['async']  # looking something up in a mapping
   @func(1, 2, 3).async # getting the attribute of the /result/ of a
   function call

Obviously these restrictions haven't been too burdensome, as I've 
labored under them for 13+ years and didn't even notice until just now.  
But it set me to wondering.


If it were me, perpetually lazy sod that I am, I'd have written the 
grammar as


   decorator: '@' expr NEWLINE

and been done with it.

So why don't decorators allow arbitrary expressions?  The PEP discusses 
the syntax for decorators, but that whole debate only concerned itself 
with where the decorator goes relative to "def", and what funny 
punctuation might it use.  It never says "decorators shouldn't permit 
arbitrary expressions because--".  Nor is there any info on wiki page 
with the extensive summary of alternative syntax proposals.


Anybody remember?

I'm not proposing that we allow arbitrary expressions as decorators... 
well, I'm not doing that /yet/ at least.  But like I said, the syntax 
has been this way for 13 years and I don't recall anybody complaining.



//arry

/p.s. I experimentally tried modifying the grammar for descriptors to 
allow arbitrary expressions.  The syntax was fine but it crashed in 
ast_for_decorator().  When I updated that to match, it worked fine!  The 
diff is short and mainly consists of deleted code.
___
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] Why aren't decorators just expressions?

2017-09-16 Thread Serhiy Storchaka 

16.09.17 12:39, Larry Hastings пише:
So why don't decorators allow arbitrary expressions?  The PEP discusses 
the syntax for decorators, but that whole debate only concerned itself 
with where the decorator goes relative to "def", and what funny 
punctuation might it use.  It never says "decorators shouldn't permit 
arbitrary expressions because--".  Nor is there any info on wiki page 
with the extensive summary of alternative syntax proposals.


Anybody remember?


https://mail.python.org/pipermail/python-dev/2004-August/046711.html

I'm not proposing that we allow arbitrary expressions as decorators... 
well, I'm not doing that /yet/ at least.  But like I said, the syntax 
has been this way for 13 years and I don't recall anybody complaining.


This may be an argument for not changing the syntax.

Actually I remember somebody raised this question a year or two ago, but 
don't remember details.


___
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] SK-CSIRT identified malicious software libraries in the official Python package repository, PyPI

2017-09-16 Thread Nick Coghlan 
On 16 September 2017 at 07:08, Victor Stinner  wrote:
> Benjamin Bach and Hanno Böck are running
> https://www.pytosquatting.org/ and registered many projects lilke
> https://pypi.python.org/pypi/urllib2
>
> "In June 2016, Typosquatting programming language package managers
> stated that urllib2 had ~4,000 downloads in 2 weeks. The package name
> is now squatted by us (the good guys). We take these findings
> seriously."
>
> It seems like we need a solution to prevent that a project removed
> because it contains malicious code, can be recreated automatically.

The PyPI admins have the ability to blacklist project names (with one
of the simplest mechanisms being for admins to typosquat them
pre-emptively - while, as Jakub notes, that currently requires
uploading an actual sdist, it doesn't need to be an installable one),
so that isn't the hard part of the problem.

The hard parts are the ones that potentially require people to scale:

1. Noticing typosquatting in the first place
2. Evaluating and responding to notifications of malicious
namesquatting in a timely manner
3. Handling requests to use names that have been reserved by the admins

The first part can already be handled in a distributed fashion -
bandersnatch will give anyone a full mirror of PyPI in a few hours
(depending on their available network bandwidth), and going to
https://pypi.org/simple/ will give you a listing of all the registered
project names as a HTML file.

The second part is tricky, since there aren't currently any consistent
public markers for "benign" blacklisting. For example, if you go to
https://pypi.org/simple/pkg-resources/ (the normalised name for
"pkg_resources") you'll get a response, since that's a registered name
with no uploads (IIRC, it's reserved by Donald). However, if you go to
https://pypi.org/project/pkg-resources/ you get a 404 page, rather
than a notification that the name has been reserved by the PyPI
admins.

So that would probably be a useful enhancement - having "reserved by
the PyPI admins" as an explicit state, so 3rd party researchers can
more readily flag such cases as being as safe as we can reasonably
make them from a security perspective.

For the "review for malice" aspect, notifying the PyPI admins of all
close names isn't a particularly viable option as the default
behaviour, since they're either volunteers, or folks with partial time
grants from their employers. However, something that I think does have
the potential to scale reasonably well is to instead notify the
maintainers of projects with similar names:
https://github.com/pypa/warehouse/issues/2268

That way the initial review is distributed to the maintainers of
targeted packages, and then only the cases that those maintainers
consider to be potentially malicious would need to be escalated to the
PyPI admins.

The final aspect is one of the items considered in PEP 541:
https://www.python.org/dev/peps/pep-0541/#invalid-projects

Getting PEP 541 accepted will likely make it easier to start scaling
the ticket review team for PyPI (with both paid and volunteer
efforts), and that's currently with Donald for review as an initial
policy that we can start with, and then iterate on over time.

Cheers,
Nick.

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

Re: [Python-Dev] Why aren't decorators just expressions?

2017-09-16 Thread Nick Coghlan 
On 16 September 2017 at 21:22, Serhiy Storchaka  wrote:
> Actually I remember somebody raised this question a year or two ago, but
> don't remember details.

Aye, I remember that as well, but apparently the thread title for the
discussion was sufficiently unrelated to the eventual topic that I
can't find it with Google.

Anyway, I think the outcome of that particular thread was something like:

1. The most reasonable-sounding enhancement request is the one to
allow subscripts: "@deco_group[deco_id]"
2. If we're going to relax the restrictions at all, it probably makes
sense to just allow arbitrary expressions
3. You can already use arbitrary expressions in practice by defining
"def deco(x): return x", and then writing
"@deco(whatever_expression_you_want)"
4. Nobody was motivated enough to actually implement the change and
then ask Guido if he'd changed his mind on the topic since 2004

Cheers,
Nick.

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

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

2017-09-16 Thread Sven R. Kunze 

Thanks for the PEP! :)

I like the naming. ;) Though, I would like to add to Michel's argument 
in favor of a base class.



On 11.09.2017 08:38, Michel Desmoulin wrote:

- I read Guido talking about some base class as alternative to the
generator version, but don't see it in the PEP. Is it still considered ?

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.


3)  - the order of base classes can arranged appropriately

In our day-to-day work, we use mixins and cooperative multiple 
inheritance a lot.

So, having dataclasses as a base class or a mixin would be great! :)

Combined with 1) and 2), I am much in favor of having dataclasses as 
base class/mixin than as a decorator.

What are the benefits of the decorator? Maybe both is possible?

Cheers,
Sven


PS: @Michel good observation 1). Typing decorators in shell is annoying.
___
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] Why aren't decorators just expressions?

2017-09-16 Thread Barry Warsaw 
On Sep 16, 2017, at 02:39, Larry Hastings  wrote:

> I'm not proposing that we allow arbitrary expressions as decorators... well, 
> I'm not doing that yet at least.  But like I said, the syntax has been this 
> way for 13 years and I don't recall anybody complaining.

Indeed, I can’t remember a single time where I’ve needed that, let alone 
actually realized the restriction existed.  But now that you mention it, I do 
remember discussions in favor of the more restricted syntax when the feature 
was originally being debated.  I don’t remember the reasons though - it well 
could have been an abundance of caution over how far to take the new syntax 
(and understanding of course that it’s easier to relax than restrict).

-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

2017-09-16 Thread Steve Holden 
​I make this suggestion in trepidation, given that Guido called a halt on
the Great Naming Debate, but it seems that a short, neutral name with data
connotations previously not a part of many popular subsystems is required.

I therefore propose "row", which is sufficiently neutral to avoid most
current opposition and yet a common field-oriented mechanism for accessing
units of retrieved data by name.

regards
 Steve​

Steve Holden

On Sat, Sep 16, 2017 at 3:44 PM, Sven R. Kunze  wrote:

> Thanks for the PEP! :)
>
> I like the naming. ;) Though, I would like to add to Michel's argument in
> favor of a base class.
>
>
> On 11.09.2017 08:38, Michel Desmoulin wrote:
>
>> - I read Guido talking about some base class as alternative to the
 generator version, but don't see it in the PEP. Is it still considered ?

>>> 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.
>>
>
> 3)  - the order of base classes can arranged appropriately
>
> In our day-to-day work, we use mixins and cooperative multiple inheritance
> a lot.
> So, having dataclasses as a base class or a mixin would be great! :)
>
> Combined with 1) and 2), I am much in favor of having dataclasses as base
> class/mixin than as a decorator.
> What are the benefits of the decorator? Maybe both is possible?
>
> Cheers,
> Sven
>
>
> PS: @Michel good observation 1). Typing decorators in shell is annoying.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve%
> 40holdenweb.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] Why aren't decorators just expressions?

2017-09-16 Thread David Mertz 
I always realized the restriction was there, and once in a while mention it
in teaching. But I've NEVER had an actual desire to use anything other that
a simple decorator or a "decorator factory" (which I realize is a decorator
in the grammar, but it's worth teaching how to parameterize custom ones,
which is a factory).

I've used barry_as_FLUFL more often, actually... Albeit always joking
around for students, not in production covfefe.

On Sep 16, 2017 9:46 AM, "Barry Warsaw"  wrote:

On Sep 16, 2017, at 02:39, Larry Hastings  wrote:

> I'm not proposing that we allow arbitrary expressions as decorators...
well, I'm not doing that yet at least.  But like I said, the syntax has
been this way for 13 years and I don't recall anybody complaining.

Indeed, I can’t remember a single time where I’ve needed that, let alone
actually realized the restriction existed.  But now that you mention it, I
do remember discussions in favor of the more restricted syntax when the
feature was originally being debated.  I don’t remember the reasons though
- it well could have been an abundance of caution over how far to take the
new syntax (and understanding of course that it’s easier to relax than
restrict).

-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/
mertz%40gnosis.cx
___
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] Why aren't decorators just expressions?

2017-09-16 Thread Skip Montanaro 
> Indeed, I can’t remember a single time where I’ve needed that, let alone
actually realized the restriction existed.

Likewise. I suspect the use of a function sort of just fell out from the
pre-decorator usage. Things like staticmethod()
 and
classmethod() 
were
used well before decorators were available. (According to the linked 2.7
doc references, both were introduced in 2.2, with decorator tweaks coming
along in 2.4.) In fact, those two functions might have been the most
significant driving force in the development of decorators, which, I
believe, were always just thought if as nothing more than syntactic sugar
for existing common use cases.

Skip
___
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] Why aren't decorators just expressions?

2017-09-16 Thread Guido van Rossum 
It was and is all very intentional. I don't want to encourage line noise,
which the at-sign already resembles. But namespacing and some form of
parametrization (i.e. calls) are essential. So that's what we got.

On Sep 16, 2017 11:30 AM, "Skip Montanaro"  wrote:

> > Indeed, I can’t remember a single time where I’ve needed that, let alone
> actually realized the restriction existed.
>
> Likewise. I suspect the use of a function sort of just fell out from the
> pre-decorator usage. Things like staticmethod()
>  and
> classmethod()
>  were used
> well before decorators were available. (According to the linked 2.7 doc
> references, both were introduced in 2.2, with decorator tweaks coming along
> in 2.4.) In fact, those two functions might have been the most significant
> driving force in the development of decorators, which, I believe, were
> always just thought if as nothing more than syntactic sugar for existing
> common use cases.
>
> Skip
>
> ___
> 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
>
>
___
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] [RELEASE] Python 2.7.14

2017-09-16 Thread Benjamin Peterson 
I'm happy to announce to the immediate availability of Python 2.7.14,
yet another bug fix release in the Python 2.7 series. 2.7.14 includes 9
months of conservative bug fixes from the 3.x branch.

Downloads of source code and binaries are at:
https://www.python.org/downloads/release/python-2714/

Bugs may be reported at
https://bugs.python.org/

Warmly,
Benjamin
2.7 release manager
(on behalf of all of 2.7's contributors)
___
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