Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

PEP 8 modernisation

  

 
First page Previous page 1 2 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded


ncoghlan at gmail

Aug 1, 2013, 5:44 AM

Post #1 of 36 (187 views)
Permalink
PEP 8 modernisation
With feedback from Guido, Barry, Raymond and others, I have updated
PEP 8 to better describe our current development practices. It started
as an update to describe the different between public and internal
interfaces and to advise against using wildcard imports, but became
substantially more :)

For those that want full details, the relevant commit and tracker
issue are here:

http://hg.python.org/peps/rev/fb24c80e9afb
http://bugs.python.org/issue18472

If you're responsible for a coding standard that includes PEP 8 by
reference, you probably want to take a look at these :)

For everyone else, here are the highlights:

1. Made it clear this is a living document (using the approach of
creating a tracker issue for major updates and adding a new footnote
referencing that issue)
2. Added more specific points to the "foolish consistency" section to
help out those folks resisting pointless PEP 8 compliance for code
that predates the existence of the PEP's recommendations.
3. Stopped being wishy-washy about tabs vs spaces. Use spaces :)
4. Lines up to 99 characters are now permitted (but 79 is still the
preferred limit)
5. The encodings section is now emphatically in favour of UTF-8
(latin-1 is no longer even mentioned)
6. While absolute imports are still favoured, explicit relative
imports are deemed acceptable
7. Wildcard imports are strongly discouraged for most cases (with
dynamic republishing the only acceptable use case, since PEP 8 doesn't
apply at all for the interactive prompt)
8. New section explaining the distinction between public and internal
interfaces (and how to tell which is which)
9. Explicit guideline not to assign lambdas to names (use def, that's
what it's for)
10. Various tweaks to the exception raising and handling guidelines
11. Explicit recommendation to use a decorator in conjunction with
annotations in third party experiments

Cheers,
Nick.

P.S. It's possible this should also be published through
python-announce and other channels...

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


solipsis at pitrou

Aug 1, 2013, 6:10 AM

Post #2 of 36 (181 views)
Permalink
Re: PEP 8 modernisation [In reply to]
Le Thu, 1 Aug 2013 22:44:12 +1000,
Nick Coghlan <ncoghlan [at] gmail> a écrit :
> 4. Lines up to 99 characters are now permitted (but 79 is still the
> preferred limit)

Something magic about 99?

cheers

Antoine.


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


fred at fdrake

Aug 1, 2013, 6:16 AM

Post #3 of 36 (181 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Thu, Aug 1, 2013 at 9:10 AM, Antoine Pitrou <solipsis [at] pitrou> wrote:
> Something magic about 99?

I'm guessing it's short enough you can say you tried, but long
enough to annoy traditionalists anyway.

I'm annoyed already. :-)


-Fred

--
Fred L. Drake, Jr. <fred at fdrake.net>
"A storm broke loose in my mind." --Albert Einstein
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Aug 1, 2013, 6:21 AM

Post #4 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 1 August 2013 23:10, Antoine Pitrou <solipsis [at] pitrou> wrote:
> Le Thu, 1 Aug 2013 22:44:12 +1000,
> Nick Coghlan <ncoghlan [at] gmail> a écrit :
>> 4. Lines up to 99 characters are now permitted (but 79 is still the
>> preferred limit)
>
> Something magic about 99?

One less than 100, same as 79 is one less than 80. The "100" came from Guido :)

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


rdmurray at bitdance

Aug 1, 2013, 7:21 AM

Post #5 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Thu, 01 Aug 2013 09:16:13 -0400, Fred Drake <fred [at] fdrake> wrote:
> On Thu, Aug 1, 2013 at 9:10 AM, Antoine Pitrou <solipsis [at] pitrou> wrote:
> > Something magic about 99?
>
> I'm guessing it's short enough you can say you tried, but long
> enough to annoy traditionalists anyway.
>
> I'm annoyed already. :-)

+1 :)

My terminal windows are usually wider than 80 chars, but I still find it
far far better to limit myself to 79 columns, because it gives me
the flexibility to narrow the windows at need (eg: :vsplit in vi to
see several files side-by-side). The (small) improvement in
readability of longer lines is far less significant to me than
the loss of readability when I want narrower windows (or run into
them in code review tools, as mentioned).

But of course this is just my opinion :) :)

--David
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


steve at pearwood

Aug 1, 2013, 7:31 AM

Post #6 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 01/08/13 22:44, Nick Coghlan wrote:

> 4. Lines up to 99 characters are now permitted (but 79 is still the
> preferred limit)


Coincidentally, there was a discussion about line length on python-list over the last couple of days. I think the two most relevant comments are by Skip Montanaro:

http://mail.python.org/pipermail/python-list/2013-July/652977.html
http://mail.python.org/pipermail/python-list/2013-July/653046.html

If I may be permitted to paraphrase:

- publishers and printers have been dealing with readability of text for an awfully long time, and they pretty much all use a de facto standard of 70-80 characters per line;

- most lines of code are short, stretching the max out to 100 characters when most lines are around 60 just ends up wasting screen real estate if your editor window is wide enough to deal with the max.

To that last point, I add: it's even worse if you keep the editor relatively narrow, since now you have a few lines that require horizontal scrolling, which is awful, or line-wrapping, neither of which are palatable.



--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


kxepal at gmail

Aug 1, 2013, 7:34 AM

Post #7 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
Hi Nick,

On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan <ncoghlan [at] gmail> wrote:
> 9. Explicit guideline not to assign lambdas to names (use def, that's
> what it's for)

Even for propose to fit chars-per-line limit and/or to remove
duplicates (especially for sorted groupby case)?

--
,,,^..^,,,
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ronaldoussoren at mac

Aug 1, 2013, 7:41 AM

Post #8 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 1 Aug, 2013, at 16:34, Alexander Shorin <kxepal [at] gmail> wrote:

> Hi Nick,
>
> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan <ncoghlan [at] gmail> wrote:
>> 9. Explicit guideline not to assign lambdas to names (use def, that's
>> what it's for)
>
> Even for propose to fit chars-per-line limit and/or to remove
> duplicates (especially for sorted groupby case)?

When you do "name = lambda ..." you've created a named function, when you
do that your better of using def statement for the reasons Nick mentioned
in the PEP.

Ronald

>
> --
> ,,,^..^,,,
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ldlandis at gmail

Aug 1, 2013, 7:43 AM

Post #9 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Thu, Aug 1, 2013 at 8:31 AM, Steven D'Aprano <steve [at] pearwood> wrote:

> On 01/08/13 22:44, Nick Coghlan wrote:
>
> 4. Lines up to 99 characters are now permitted (but 79 is still the
>> preferred limit)
>>
>

> Coincidentally, there was a discussion about line length on python-list
> over the last couple of days. I think the two most relevant comments are by
> Skip Montanaro:
>
> http://mail.python.org/**pipermail/python-list/2013-**July/652977.html<http://mail.python.org/pipermail/python-list/2013-July/652977.html>
> http://mail.python.org/**pipermail/python-list/2013-**July/653046.html<http://mail.python.org/pipermail/python-list/2013-July/653046.html>
>
>
I believe there may be a relationship to the 7 plus or minus 2 (times 10)
of human conceptual limits.

Personally I find it very difficult to read text with long lines.

Historically two or three column (newspaper/book) with a barrier margin
was used to get much more text on the page, but still the reader had much
shorter "chunks" to absorb.


> If I may be permitted to paraphrase:
>
> - publishers and printers have been dealing with readability of text for
> an awfully long time, and they pretty much all use a de facto standard of
> 70-80 characters per line;
>
> - most lines of code are short, stretching the max out to 100 characters
> when most lines are around 60 just ends up wasting screen real estate if
> your editor window is wide enough to deal with the max.
>
> To that last point, I add: it's even worse if you keep the editor
> relatively narrow, since now you have a few lines that require horizontal
> scrolling, which is awful, or line-wrapping, neither of which are palatable.
>
>
>
> --
> Steven
>
> ______________________________**_________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> ldlandis%40gmail.com<http://mail.python.org/mailman/options/python-dev/ldlandis%40gmail.com>
>



--
---
NOTE: If it is important CALL ME - I may miss email,
which I do NOT normally check on weekends nor on
a regular basis during any other day.
---
LD Landis - N0YRQ - de la tierra del encanto
3960 Schooner Loop, Las Cruces, NM 88012
651-340-4007 N32 21'48.28" W106 46'5.80"


kxepal at gmail

Aug 1, 2013, 7:48 AM

Post #10 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
Hi Ronald,

I understand this, but I'm a bit confused about fate of lambdas with
such guideline since I see no more reasons to use them with p.9
statement: long lines, code duplicate, no mock and well tests etc. -
all these problems could be solved with assigning lambda to some name,
but now they are looks useless (or useful only for very trivial cases)
--
,,,^..^,,,


On Thu, Aug 1, 2013 at 6:41 PM, Ronald Oussoren <ronaldoussoren [at] mac> wrote:
>
> On 1 Aug, 2013, at 16:34, Alexander Shorin <kxepal [at] gmail> wrote:
>
>> Hi Nick,
>>
>> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan <ncoghlan [at] gmail> wrote:
>>> 9. Explicit guideline not to assign lambdas to names (use def, that's
>>> what it's for)
>>
>> Even for propose to fit chars-per-line limit and/or to remove
>> duplicates (especially for sorted groupby case)?
>
> When you do "name = lambda ..." you've created a named function, when you
> do that your better of using def statement for the reasons Nick mentioned
> in the PEP.
>
> Ronald
>
>>
>> --
>> ,,,^..^,,,
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev [at] python
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
>
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ronaldoussoren at mac

Aug 1, 2013, 7:53 AM

Post #11 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 1 Aug, 2013, at 16:48, Alexander Shorin <kxepal [at] gmail> wrote:

> Hi Ronald,
>
> I understand this, but I'm a bit confused about fate of lambdas with
> such guideline since I see no more reasons to use them with p.9
> statement: long lines, code duplicate, no mock and well tests etc. -
> all these problems could be solved with assigning lambda to some name,
> but now they are looks useless (or useful only for very trivial cases)

That sounds about right :-)

Note that:

f = lambda x: x ** 2

And:

def f(x): return x ** 2

Are functionally equivalent and use the same byte code. The only differences
are that the lambda saves two characters in typing, and the "def" variant has
a more useful value in its __name__ attribute.

IMHO The lambda variant also looks uglier (even with the def variant on a single line).

Ronald

> --
> ,,,^..^,,,
>
>
> On Thu, Aug 1, 2013 at 6:41 PM, Ronald Oussoren <ronaldoussoren [at] mac> wrote:
>>
>> On 1 Aug, 2013, at 16:34, Alexander Shorin <kxepal [at] gmail> wrote:
>>
>>> Hi Nick,
>>>
>>> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan <ncoghlan [at] gmail> wrote:
>>>> 9. Explicit guideline not to assign lambdas to names (use def, that's
>>>> what it's for)
>>>
>>> Even for propose to fit chars-per-line limit and/or to remove
>>> duplicates (especially for sorted groupby case)?
>>
>> When you do "name = lambda ..." you've created a named function, when you
>> do that your better of using def statement for the reasons Nick mentioned
>> in the PEP.
>>
>> Ronald
>>
>>>
>>> --
>>> ,,,^..^,,,
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev [at] python
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
>>

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


steve at pearwood

Aug 1, 2013, 7:57 AM

Post #12 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 01/08/13 22:44, Nick Coghlan wrote:
> With feedback from Guido, Barry, Raymond and others, I have updated
> PEP 8 to better describe our current development practices. It started
> as an update to describe the different between public and internal
> interfaces and to advise against using wildcard imports, but became
> substantially more :)

Before this entire thread be buried in a mountain of controversy over the 79-99 line length issue, let me say thanks Nick and the others for your work on this.



--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


kxepal at gmail

Aug 1, 2013, 8:03 AM

Post #13 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
...and, if so, why lambda's?(: Without backward compatibility point I
see that they are getting "unofficially" deprecated and their usage is
dishonoured.

--
,,,^..^,,,


On Thu, Aug 1, 2013 at 6:53 PM, Ronald Oussoren <ronaldoussoren [at] mac> wrote:
>
> On 1 Aug, 2013, at 16:48, Alexander Shorin <kxepal [at] gmail> wrote:
>
>> Hi Ronald,
>>
>> I understand this, but I'm a bit confused about fate of lambdas with
>> such guideline since I see no more reasons to use them with p.9
>> statement: long lines, code duplicate, no mock and well tests etc. -
>> all these problems could be solved with assigning lambda to some name,
>> but now they are looks useless (or useful only for very trivial cases)
>
> That sounds about right :-)
>
> Note that:
>
> f = lambda x: x ** 2
>
> And:
>
> def f(x): return x ** 2
>
> Are functionally equivalent and use the same byte code. The only differences
> are that the lambda saves two characters in typing, and the "def" variant has
> a more useful value in its __name__ attribute.
>
> IMHO The lambda variant also looks uglier (even with the def variant on a single line).
>
> Ronald
>
>> --
>> ,,,^..^,,,
>>
>>
>> On Thu, Aug 1, 2013 at 6:41 PM, Ronald Oussoren <ronaldoussoren [at] mac> wrote:
>>>
>>> On 1 Aug, 2013, at 16:34, Alexander Shorin <kxepal [at] gmail> wrote:
>>>
>>>> Hi Nick,
>>>>
>>>> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan <ncoghlan [at] gmail> wrote:
>>>>> 9. Explicit guideline not to assign lambdas to names (use def, that's
>>>>> what it's for)
>>>>
>>>> Even for propose to fit chars-per-line limit and/or to remove
>>>> duplicates (especially for sorted groupby case)?
>>>
>>> When you do "name = lambda ..." you've created a named function, when you
>>> do that your better of using def statement for the reasons Nick mentioned
>>> in the PEP.
>>>
>>> Ronald
>>>
>>>>
>>>> --
>>>> ,,,^..^,,,
>>>> _______________________________________________
>>>> Python-Dev mailing list
>>>> Python-Dev [at] python
>>>> http://mail.python.org/mailman/listinfo/python-dev
>>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
>>>
>
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


skip at pobox

Aug 1, 2013, 8:05 AM

Post #14 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
> http://mail.python.org/pipermail/python-list/2013-July/653046.html

One correspondent objected that I was artificial biasing my histogram
because wrapped lines are, more-or-less by definition, going to be <
80 characters. Off-list I responded with a modified version of my
graph where I eliminated all lines which ended in my preferred
continuation characters (open paren-like things and commas). The
resulting histogram is attached (count as a function of line length).
This makes the "wasted space" argument even stronger. Generally, when
I wrap a line, I wrap it fairly near the limit, so by eliminating
them, the shorter lines stand out more clearly.

Skip
Attachments: square2.png (19.9 KB)


alexander.belopolsky at gmail

Aug 1, 2013, 8:05 AM

Post #15 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Thu, Aug 1, 2013 at 10:21 AM, R. David Murray <rdmurray [at] bitdance>wrote:

> > I'm guessing it's short enough you can say you tried, but long
> > enough to annoy traditionalists anyway.
> >
> > I'm annoyed already. :-)
>
> +1 :)


+1 :)

I recently gave up and reset default auto-wrap margin to 120 locally. This
change had little effect on code because most line breaks in code are
inserted manually anyways. However, docstrings are beginning to suffer.
The "short description" line is not that short anymore and multi-paragraph
prose filled between 4- and 120-characters margin is hard to read.

I will start experimenting with 100-char limit, but I think it is still too
wide for auto-wrapped text. Maybe we should have a stronger
recommendation to keep 80-char limit for docstrings and other embedded
text. It is OK to have an occasional long line in code, but readability
suffers when you have every line close to 100 chars.

Another observation is that long lines in code are usually heavily
indented. This makes them still readable because non-white characters
still fit within the field of view. Again, this is not the case for
docstrings, comments or other embedded prose.


rdmurray at bitdance

Aug 1, 2013, 8:07 AM

Post #16 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Thu, 01 Aug 2013 16:53:16 +0200, Ronald Oussoren <ronaldoussoren [at] mac> wrote:
> On 1 Aug, 2013, at 16:48, Alexander Shorin <kxepal [at] gmail> wrote:
> > I understand this, but I'm a bit confused about fate of lambdas with
> > such guideline since I see no more reasons to use them with p.9
> > statement: long lines, code duplicate, no mock and well tests etc. -
> > all these problems could be solved with assigning lambda to some name,
> > but now they are looks useless (or useful only for very trivial cases)
>
> That sounds about right :-)

I don't understand the cases being mentioned in the question, but there
are certainly places where lambdas are useful. The most obvious is as
arguments to functions that expect functions as arguments.

But yes, even in those cases if a lambda isn't fairly trivial, it
probably shouldn't be a lambda.

--David
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


solipsis at pitrou

Aug 1, 2013, 8:09 AM

Post #17 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
Le Thu, 1 Aug 2013 23:21:49 +1000,
Nick Coghlan <ncoghlan [at] gmail> a écrit :
> On 1 August 2013 23:10, Antoine Pitrou <solipsis [at] pitrou> wrote:
> > Le Thu, 1 Aug 2013 22:44:12 +1000,
> > Nick Coghlan <ncoghlan [at] gmail> a écrit :
> >> 4. Lines up to 99 characters are now permitted (but 79 is still the
> >> preferred limit)
> >
> > Something magic about 99?
>
> One less than 100, same as 79 is one less than 80. The "100" came
> from Guido :)

Yes, I've heard about those spiffy BCD computers in the powerful
datacenters of American companies :-)

(and after all, BCD == ABC + 1)

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ronaldoussoren at mac

Aug 1, 2013, 8:11 AM

Post #18 of 36 (177 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 1 Aug, 2013, at 17:03, Alexander Shorin <kxepal [at] gmail> wrote:

> ...and, if so, why lambda's?(: Without backward compatibility point I
> see that they are getting "unofficially" deprecated and their usage is
> dishonoured.

They are still usefull for simple functions that you use in one place,
such as the key argument to sorted. By the time you assign a name to the function
and give it unittests you may as well use a def-statement and let the
function know it its own name.

Ronald

>
> --
> ,,,^..^,,,
>
>
> On Thu, Aug 1, 2013 at 6:53 PM, Ronald Oussoren <ronaldoussoren [at] mac> wrote:
>>
>> On 1 Aug, 2013, at 16:48, Alexander Shorin <kxepal [at] gmail> wrote:
>>
>>> Hi Ronald,
>>>
>>> I understand this, but I'm a bit confused about fate of lambdas with
>>> such guideline since I see no more reasons to use them with p.9
>>> statement: long lines, code duplicate, no mock and well tests etc. -
>>> all these problems could be solved with assigning lambda to some name,
>>> but now they are looks useless (or useful only for very trivial cases)
>>
>> That sounds about right :-)
>>
>> Note that:
>>
>> f = lambda x: x ** 2
>>
>> And:
>>
>> def f(x): return x ** 2
>>
>> Are functionally equivalent and use the same byte code. The only differences
>> are that the lambda saves two characters in typing, and the "def" variant has
>> a more useful value in its __name__ attribute.
>>
>> IMHO The lambda variant also looks uglier (even with the def variant on a single line).
>>
>> Ronald
>>
>>> --
>>> ,,,^..^,,,
>>>
>>>
>>> On Thu, Aug 1, 2013 at 6:41 PM, Ronald Oussoren <ronaldoussoren [at] mac> wrote:
>>>>
>>>> On 1 Aug, 2013, at 16:34, Alexander Shorin <kxepal [at] gmail> wrote:
>>>>
>>>>> Hi Nick,
>>>>>
>>>>> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan <ncoghlan [at] gmail> wrote:
>>>>>> 9. Explicit guideline not to assign lambdas to names (use def, that's
>>>>>> what it's for)
>>>>>
>>>>> Even for propose to fit chars-per-line limit and/or to remove
>>>>> duplicates (especially for sorted groupby case)?
>>>>
>>>> When you do "name = lambda ..." you've created a named function, when you
>>>> do that your better of using def statement for the reasons Nick mentioned
>>>> in the PEP.
>>>>
>>>> Ronald
>>>>
>>>>>
>>>>> --
>>>>> ,,,^..^,,,
>>>>> _______________________________________________
>>>>> Python-Dev mailing list
>>>>> Python-Dev [at] python
>>>>> http://mail.python.org/mailman/listinfo/python-dev
>>>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
>>>>
>>

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

Aug 1, 2013, 8:35 AM

Post #19 of 36 (176 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Aug 01, 2013, at 11:05 AM, Alexander Belopolsky wrote:

>I will start experimenting with 100-char limit, but I think it is still too
>wide for auto-wrapped text. Maybe we should have a stronger
>recommendation to keep 80-char limit for docstrings and other embedded
>text. It is OK to have an occasional long line in code, but readability
>suffers when you have every line close to 100 chars.

In general, long lines are a smell that the code is trying to express
something too complex or is being too clever. Using various strategies
judiciously usually leads to better, more readable code (e.g. use a local
variable, wrap the line after open parens, don't chain too many calls, etc.)

I'm not counting exceptions of course, it's PEP 8 after all!

So I would greatly prefer that stdlib files be kept to the 79 character
limit. I see most violations of this in the library documents, but especially
there, paragraphs should be wrapped to 79 characters, and can easily be done
without losing expressability.

Cheers,
-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


alexander.belopolsky at gmail

Aug 1, 2013, 8:35 AM

Post #20 of 36 (176 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Thu, Aug 1, 2013 at 11:03 AM, Alexander Shorin <kxepal [at] gmail> wrote:

> ...and, if so, why lambda's?(: Without backward compatibility point I
> see that they are getting "unofficially" deprecated and their usage is
> dishonored.
>
>
Here is one use-case where .. = lambda .. cannot be replaced with def ..

op['add'] = lambda x,y: x+y
op['mul'] = lambda x, y: x*y
..


rdmurray at bitdance

Aug 1, 2013, 8:52 AM

Post #21 of 36 (176 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Thu, 01 Aug 2013 11:35:38 -0400, Barry Warsaw <barry [at] python> wrote:
> So I would greatly prefer that stdlib files be kept to the 79 character
> limit. I see most violations of this in the library documents, but especially
> there, paragraphs should be wrapped to 79 characters, and can easily be done
> without losing expressability.

The documentation often has line lengths longer than 80 chars for two
reasons: (1) the original translation from TeX was done by a script, and
the script had a bug in it that made the lines slightly too long, and no
one noticed in time and (2) until relatively recently Sphinx didn't
support wrapping prototype lines (it now does).

So as we edit the docs, we re-wrap. Just like we do with the legacy
code :)

The code examples in the docs are a bit trickier, since if you wrap the
source to 79 you wind up with even-shorter-than-79 wrapping in the
actual code lines, which can look odd when the text is rendered. So
there it's a judgement call...but I still generally try to wrap the
source to 79, sometimes refactoring the example to make that more
elegant. Which, as you point out, often makes it better as well :).

--David
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

Aug 1, 2013, 8:59 AM

Post #22 of 36 (176 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On Aug 01, 2013, at 11:52 AM, R. David Murray wrote:

>So as we edit the docs, we re-wrap. Just like we do with the legacy
>code :)

+1!

-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tjreedy at udel

Aug 1, 2013, 1:29 PM

Post #23 of 36 (173 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 8/1/2013 10:34 AM, Alexander Shorin wrote:
> Hi Nick,
>
> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan <ncoghlan [at] gmail> wrote:
>> 9. Explicit guideline not to assign lambdas to names (use def, that's
>> what it's for)
>
> Even for propose to fit chars-per-line limit

def f(x): return 2*x
f = lambda x: 2*x

Three spaces is seldom a crucial difference. If the expression is so
long it go past the limit (whatever we decide it is), it can be wrapped.

> and/or to remove duplicates (especially for sorted groupby case)?

I do not understand this.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tjreedy at udel

Aug 1, 2013, 1:35 PM

Post #24 of 36 (173 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 8/1/2013 10:48 AM, Alexander Shorin wrote:
> I understand this, but I'm a bit confused about fate of lambdas with
> such guideline since I see no more reasons to use them with p.9
> statement: long lines, code duplicate, no mock and well tests etc. -
> all these problems could be solved with assigning lambda to some name,
> but now they are looks useless (or useful only for very trivial cases)

I do not understand most of that, but...
The guideline is not meant to cover passing a function by parameter
name. mylist.sort(key=lambda x: x[0]) is still ok. Does "Always use a
def statement instead of assigning a lambda expression to a name." need
'in an assignment statement' added?

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tjreedy at udel

Aug 1, 2013, 1:36 PM

Post #25 of 36 (173 views)
Permalink
Re: PEP 8 modernisation [In reply to]
On 8/1/2013 11:03 AM, Alexander Shorin wrote:
> ...and, if so, why lambda's?(: Without backward compatibility point I
> see that they are getting "unofficially" deprecated and their usage is
> dishonoured.

Please stop both the top-posting and the FUD.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

First page Previous page 1 2 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.