Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Silence warning about set but unused variable inside compile_atom() in

2013-08-01 Thread Ronald Oussoren 

On 31 Jul, 2013, at 23:50, christian.heimes  wrote:

> http://hg.python.org/cpython/rev/0e09588a3bc2
> changeset:   84939:0e09588a3bc2
> parent:  84937:809a64ecd5f1
> parent:  84938:83a55ca935f0
> user:Christian Heimes 
> date:Wed Jul 31 23:48:04 2013 +0200
> summary:
>  Silence warning about set but unused variable inside compile_atom() in 
> non-debug builds
> 
> files:
>  Parser/pgen.c |  1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/Parser/pgen.c b/Parser/pgen.c
> --- a/Parser/pgen.c
> +++ b/Parser/pgen.c
> @@ -283,6 +283,7 @@
> 
> REQ(n, ATOM);
> i = n->n_nchildren;
> +(void)i; /* Don't warn about set but unused */
> REQN(i, 1);

Why didn't you change this to  "REQN(n->nchilderen, 1);" (and then remove 
variable "i")? 

Ronald

> n = n->n_child;
> if (n->n_type == LPAR) {
> 
> -- 
> Repository URL: http://hg.python.org/cpython
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Silence warning about set but unused variable inside compile_atom() in

2013-08-01 Thread Christian Heimes 
Am 01.08.2013 09:03, schrieb Ronald Oussoren:
> 
> On 31 Jul, 2013, at 23:50, christian.heimes  
> wrote:
> 
>> http://hg.python.org/cpython/rev/0e09588a3bc2
>> changeset:   84939:0e09588a3bc2
>> parent:  84937:809a64ecd5f1
>> parent:  84938:83a55ca935f0
>> user:Christian Heimes 
>> date:Wed Jul 31 23:48:04 2013 +0200
>> summary:
>>  Silence warning about set but unused variable inside compile_atom() in 
>> non-debug builds
>>
>> files:
>>  Parser/pgen.c |  1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>>
>> diff --git a/Parser/pgen.c b/Parser/pgen.c
>> --- a/Parser/pgen.c
>> +++ b/Parser/pgen.c
>> @@ -283,6 +283,7 @@
>>
>> REQ(n, ATOM);
>> i = n->n_nchildren;
>> +(void)i; /* Don't warn about set but unused */
>> REQN(i, 1);
> 
> Why didn't you change this to  "REQN(n->nchilderen, 1);" (and then remove 
> variable "i")? 
> 
> Ronald
> 
>> n = n->n_child;
>> if (n->n_type == LPAR) {

It doesn't work because a few lines later the code does:

n = n->n_child;
if (n->n_type == LPAR) {
REQN(i, 3);

n is no longer the right n and REQN(i, 3) would fail.

Christian

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Silence warning about set but unused variable inside compile_atom() in

2013-08-01 Thread Ronald Oussoren 

On 1 Aug, 2013, at 9:49, Christian Heimes  wrote:

> Am 01.08.2013 09:03, schrieb Ronald Oussoren:
>> 
>> On 31 Jul, 2013, at 23:50, christian.heimes  
>> wrote:
>> 
>>> http://hg.python.org/cpython/rev/0e09588a3bc2
>>> changeset:   84939:0e09588a3bc2
>>> parent:  84937:809a64ecd5f1
>>> parent:  84938:83a55ca935f0
>>> user:Christian Heimes 
>>> date:Wed Jul 31 23:48:04 2013 +0200
>>> summary:
>>> Silence warning about set but unused variable inside compile_atom() in 
>>> non-debug builds
>>> 
>>> files:
>>> Parser/pgen.c |  1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>> 
>>> 
>>> diff --git a/Parser/pgen.c b/Parser/pgen.c
>>> --- a/Parser/pgen.c
>>> +++ b/Parser/pgen.c
>>> @@ -283,6 +283,7 @@
>>> 
>>>REQ(n, ATOM);
>>>i = n->n_nchildren;
>>> +(void)i; /* Don't warn about set but unused */
>>>REQN(i, 1);
>> 
>> Why didn't you change this to  "REQN(n->nchilderen, 1);" (and then remove 
>> variable "i")? 
>> 
>> Ronald
>> 
>>>n = n->n_child;
>>>if (n->n_type == LPAR) {
> 
> It doesn't work because a few lines later the code does:
> 
>n = n->n_child;
>if (n->n_type == LPAR) {
>REQN(i, 3);
> 
> n is no longer the right n and REQN(i, 3) would fail.

I overlooked that one. 

Thanks for the explanation,

 Ronald

> 
> Christian
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 8 modernisation

2013-08-01 Thread Nick Coghlan 
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   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Antoine Pitrou 
Le Thu, 1 Aug 2013 22:44:12 +1000,
Nick Coghlan  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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Fred Drake 
On Thu, Aug 1, 2013 at 9:10 AM, Antoine 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.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Nick Coghlan 
On 1 August 2013 23:10, Antoine Pitrou  wrote:
> Le Thu, 1 Aug 2013 22:44:12 +1000,
> Nick Coghlan  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   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread R. David Murray 
On Thu, 01 Aug 2013 09:16:13 -0400, Fred Drake  wrote:
> On Thu, Aug 1, 2013 at 9:10 AM, Antoine 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Steven D'Aprano 

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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Alexander Shorin 
Hi Nick,

On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan  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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Ronald Oussoren 

On 1 Aug, 2013, at 16:34, Alexander Shorin  wrote:

> Hi Nick,
> 
> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan  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
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread LD 'Gus' Landis 
On Thu, Aug 1, 2013 at 8:31 AM, Steven D'Aprano  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/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
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: 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"
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Alexander Shorin 
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  wrote:
>
> On 1 Aug, 2013, at 16:34, Alexander Shorin  wrote:
>
>> Hi Nick,
>>
>> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan  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
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Ronald Oussoren 

On 1 Aug, 2013, at 16:48, Alexander Shorin  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  
> wrote:
>> 
>> On 1 Aug, 2013, at 16:34, Alexander Shorin  wrote:
>> 
>>> Hi Nick,
>>> 
>>> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan  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
>>> [email protected]
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: 
>>> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
>> 

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Steven D'Aprano 

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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

2013-08-01 Thread Martin v. Löwis 
Am 30.07.13 23:32, schrieb Antoine Pitrou:
> - it is held alive by a C extension: the main example is the locale
>   module, which is held alive by _io and in turn keeps alive other
>   Python modules (such as collections or re). 

If the _locale module would use PEP 3121 (issue15662), this problem
should go away.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Skip Montanaro 
> 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
<>___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Alexander Shorin 
...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  wrote:
>
> On 1 Aug, 2013, at 16:48, Alexander Shorin  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  
>> wrote:
>>>
>>> On 1 Aug, 2013, at 16:34, Alexander Shorin  wrote:
>>>
 Hi Nick,

 On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan  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
 [email protected]
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
>>>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Lambda [was Re: PEP 8 modernisation]

2013-08-01 Thread Steven D'Aprano 

Hi Alexander,

On 02/08/13 00:48, Alexander Shorin 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)


Lambda is still useful for the reason lambda has always been useful: it is an 
expression, not a statement, so you can embed it directly where needed.

# Preferred:
sorted(data, key=lambda value: value['spam'].casefold())

# Allowed:
def f(value): return value['spam'].casefold()
sorted(data, key=f)

# Prohibited:
f = lambda value: value['spam'].casefold()
sorted(data, key=f)

# SyntaxError:
sorted(data, key=def f(value): value['spam'].casefold())



--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread R. David Murray 
On Thu, 01 Aug 2013 16:53:16 +0200, Ronald Oussoren  
wrote:
> On 1 Aug, 2013, at 16:48, 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)
> 
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Antoine Pitrou 
Le Thu, 1 Aug 2013 23:21:49 +1000,
Nick Coghlan  a écrit :
> On 1 August 2013 23:10, Antoine Pitrou  wrote:
> > Le Thu, 1 Aug 2013 22:44:12 +1000,
> > Nick Coghlan  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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Ronald Oussoren 

On 1 Aug, 2013, at 17:03, 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.

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  
> wrote:
>> 
>> On 1 Aug, 2013, at 16:48, Alexander Shorin  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  
>>> wrote:
 
 On 1 Aug, 2013, at 16:34, Alexander Shorin  wrote:
 
> Hi Nick,
> 
> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan  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
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
 
>> 

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Alexander Belopolsky 
On Thu, Aug 1, 2013 at 10:21 AM, R. David Murray 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.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

2013-08-01 Thread Antoine Pitrou 
Le Thu, 01 Aug 2013 17:03:03 +0200,
"Martin v. Löwis"  a écrit :
> Am 30.07.13 23:32, schrieb Antoine Pitrou:
> > - it is held alive by a C extension: the main example is the locale
> >   module, which is held alive by _io and in turn keeps alive other
> >   Python modules (such as collections or re). 
> 
> If the _locale module would use PEP 3121 (issue15662), this problem
> should go away.

Not really: I'm talking about the pure Python locale module.
However, I've got another solution for this one (using weakrefs,
unsurprisingly):
http://bugs.python.org/issue18608

cheers

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Barry Warsaw 
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Alexander Belopolsky 
On Thu, Aug 1, 2013 at 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
> 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
..
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread R. David Murray 
On Thu, 01 Aug 2013 11:35:38 -0400, Barry Warsaw  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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Barry Warsaw 
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lambda [was Re: PEP 8 modernisation]

2013-08-01 Thread Alexander Shorin 
Hi Steven,

On Thu, Aug 1, 2013 at 7:06 PM, Steven D'Aprano  wrote:
> Hi Alexander,
>
> On 02/08/13 00:48, Alexander Shorin 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)
>
>
> Lambda is still useful for the reason lambda has always been useful: it is
> an expression, not a statement, so you can embed it directly where needed.
>
> # Preferred:
> sorted(data, key=lambda value: value['spam'].casefold())
>
> # Allowed:
> def f(value): return value['spam'].casefold()
> sorted(data, key=f)
>
> # Prohibited:
> f = lambda value: value['spam'].casefold()
> sorted(data, key=f)
>
> # SyntaxError:
> sorted(data, key=def f(value): value['spam'].casefold())

The case:

items =  [[0, 'foo'], [3, 'baz'],  [2, 'foo'], [1, 'bar']]

Need to group by second item. Quite common task:

>>> from itertools import groupby
>>>
>>> for key, items in groupby(items, key=lambda i: i[1]):
>>>   print(key, ':', list(items))
foo : [[0, 'foo']]
baz : [[3, 'baz']]
foo : [[2, 'foo']]
bar : [[1, 'bar']]

oops, failed, we need to sort things first by this item and it looks
we have to duplicate grouping function:

fun = lambda i: i[1]
for key, items in groupby(sorted(items, key=fun), key=fun):
  print(key, ':', list(items))

Ok, PEP suggests to use defs, so we adds 3 more lines (before and
after def + return) to code:

def fun(i):
  return i[1]

for key, items in groupby(sorted(items, key=fun), key=fun):
  print(key, ':', list(items))

so that's the question: what is the rationale of this if lambdas
successfully solves the problem with minimal amount of typing, code
and thinking? I thought there should be only one way to do something,
but this PEP-8 statement conflicts with PEP-20 one:

> There should be one-- and preferably only one --obvious way to do it.

It's really not oblivious why lambdas couldn't be assignment to some
name, especially in the light of fact that if they are been passed to
some function as argument, they will be assignee to some name.



--
,,,^..^,,,
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lambda [was Re: PEP 8 modernisation]

2013-08-01 Thread Chris Angelico 
On Thu, Aug 1, 2013 at 5:58 PM, Alexander Shorin  wrote:
> fun = lambda i: i[1]
> for key, items in groupby(sorted(items, key=fun), key=fun):
>   print(key, ':', list(items))

I'd do a direct translation to def here:

def fun(i): return i[1]
for key, items in groupby(sorted(items, key=fun), key=fun):
  print(key, ':', list(items))

ChrisA
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lambda [was Re: PEP 8 modernisation]

2013-08-01 Thread Brett Cannon 
On Thu, Aug 1, 2013 at 12:58 PM, Alexander Shorin  wrote:

> Hi Steven,
>
> On Thu, Aug 1, 2013 at 7:06 PM, Steven D'Aprano 
> wrote:
> > Hi Alexander,
> >
> > On 02/08/13 00:48, Alexander Shorin 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)
> >
> >
> > Lambda is still useful for the reason lambda has always been useful: it
> is
> > an expression, not a statement, so you can embed it directly where
> needed.
> >
> > # Preferred:
> > sorted(data, key=lambda value: value['spam'].casefold())
> >
> > # Allowed:
> > def f(value): return value['spam'].casefold()
> > sorted(data, key=f)
> >
> > # Prohibited:
> > f = lambda value: value['spam'].casefold()
> > sorted(data, key=f)
> >
> > # SyntaxError:
> > sorted(data, key=def f(value): value['spam'].casefold())
>
> The case:
>
> items =  [[0, 'foo'], [3, 'baz'],  [2, 'foo'], [1, 'bar']]
>
> Need to group by second item. Quite common task:
>
> >>> from itertools import groupby
> >>>
> >>> for key, items in groupby(items, key=lambda i: i[1]):
> >>>   print(key, ':', list(items))
> foo : [[0, 'foo']]
> baz : [[3, 'baz']]
> foo : [[2, 'foo']]
> bar : [[1, 'bar']]
>
> oops, failed, we need to sort things first by this item and it looks
> we have to duplicate grouping function:
>
> fun = lambda i: i[1]
> for key, items in groupby(sorted(items, key=fun), key=fun):
>   print(key, ':', list(items))
>
> Ok, PEP suggests to use defs, so we adds 3 more lines (before and
> after def + return) to code:
>
> def fun(i):
>   return i[1]
>
> for key, items in groupby(sorted(items, key=fun), key=fun):
>   print(key, ':', list(items))
>
> so that's the question: what is the rationale of this if lambdas
> successfully solves the problem with minimal amount of typing, code
> and thinking? I thought there should be only one way to do something,
> but this PEP-8 statement conflicts with PEP-20 one:
>
> > There should be one-- and preferably only one --obvious way to do it.
>
> It's really not oblivious why lambdas couldn't be assignment to some
> name, especially in the light of fact that if they are been passed to
> some function as argument, they will be assignee to some name.
>

 Just because you can doesn't mean you should.

This guideline is all about being explicit over implicit, not about saving
typing. If you want to bind a function to a name then you should use a def
to specify that fact; you also lose some things otherwise (e.g. __name__ is
not set). Lambdas should be thought of one-off functions you write inline
because it expresses the intent of the code just as well. Assigning a
lambda to a variable is in no way more beneficial compared to using def and
thus this guideline suggesting you use def to make it at least as clear, if
not more and to gain benefits such as __name__ being set (which helps with
debugging, etc.).
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lambda [was Re: PEP 8 modernisation]

2013-08-01 Thread Stephen J. Turnbull 
Chris Angelico writes:
 > On Thu, Aug 1, 2013 at 5:58 PM, Alexander Shorin  wrote:
 > > fun = lambda i: i[1]
 > > for key, items in groupby(sorted(items, key=fun), key=fun):
 > >   print(key, ':', list(items))
 > 
 > I'd do a direct translation to def here:
 > 
 > def fun(i): return i[1]
 > for key, items in groupby(sorted(items, key=fun), key=fun):
 >   print(key, ':', list(items))

As long as it's about readability, why not make it readable?

def second(pair): return pair[1]
for key, items in groupby(sorted(items, key=second), key=second):
print(key, ':', list(items))

I realize it's somewhat unfair (for several reasons) to compare that
to Alexander's "fun = lambda i: i[1]", but I can't help feeling that
in another sense it is fair.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lambda [was Re: PEP 8 modernisation]

2013-08-01 Thread André Malo 
* Stephen J. Turnbull wrote:

> Chris Angelico writes:
>  > On Thu, Aug 1, 2013 at 5:58 PM, Alexander Shorin  
wrote:
>  > > fun = lambda i: i[1]
>  > > for key, items in groupby(sorted(items, key=fun), key=fun):
>  > >   print(key, ':', list(items))
>  >
>  > I'd do a direct translation to def here:
>  >
>  > def fun(i): return i[1]
>  > for key, items in groupby(sorted(items, key=fun), key=fun):
>  >   print(key, ':', list(items))
>
> As long as it's about readability, why not make it readable?
>
> def second(pair): return pair[1]
> for key, items in groupby(sorted(items, key=second), key=second):
> print(key, ':', list(items))
>
> I realize it's somewhat unfair (for several reasons) to compare that
> to Alexander's "fun = lambda i: i[1]", but I can't help feeling that
> in another sense it is fair.

Seems to run OT somewhat, but "second" is probably a bad name here. If the 
key changes, you have to rename it in several places (or worse, you DON'T 
rename it, and then the readability is gone).
Usually I'm using a name with "key" in it - describing what it's for, not 
how it's done. The minimal distance to its usage is supporting that, too.

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Terry Reedy 

On 8/1/2013 10:34 AM, Alexander Shorin wrote:

Hi Nick,

On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan  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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Terry Reedy 

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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Terry Reedy 

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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Brian Curtin 
On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy  wrote:
> 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.

Top posting doesn't matter.

The end.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Alexander Belopolsky 
On Thu, Aug 1, 2013 at 4:29 PM, Terry Reedy  wrote:

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

Am I the only one who finds the second line above much more readable than
the first?  The def statement is not intended to be written in one line.
 The readability suffers because the argument is separated from the value
expression by return keyword.

When def statement is written traditionally:

def f(x):
return 2*x

It is easy to run the eyes over the right margin and recognize a function
that in a math paper would be written as "f: x -> 2 x".  Same is true about
lambda expression.  While C# syntax "f = (x => 2*x)" is probably closest to
mathematical notation, "f = lambda x: 2*x" is close enough.  One can
mentally focus on the "x: 2*x" part and ignore the rest.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Terry Reedy 

On 8/1/2013 11:35 AM, Alexander Belopolsky wrote:


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


Yes, you are binding the functions to named slots, not to names, so not 
covered by the PEP. Once might still want to replace the expressions 
themselves, at the cost of more typing, for the advantage of better 
representations.


op = { 'add': lambda x,y: x*y, 'mul':  lambda x, y: x+y}
print(op)  # no apparent problem
# {'add':  at 0x0227F730>,
# 'mul':  at 0x033867B8>}

def add(x, y): return x + y
def mul(x, y): return x * y
# These can be unittested individually

op = {'add': mul, 'mul': add}  # mistake easily seen in original code
print(op)
# {'add': ,
# 'mul': }
# problem apparent to user who import this object and prints it when 
code fails


If op has 20 such functions, names become even more of an advantage

--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Brian Curtin 
On Thu, Aug 1, 2013 at 3:44 PM, Brian Curtin  wrote:
> On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy  wrote:
>> 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.
>
> Top posting doesn't matter.
>
> The end.

Actually, quick expansion on this before moving along: if you're going
to call someone out for top posting, you can't ignore the many high
profile people who do it every time and single out the newcomer.
That's why I said something.

Sorry for the OT.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

2013-08-01 Thread Nick Coghlan 
On 2 Aug 2013 01:18, "Alexander Belopolsky" 
wrote:
>
>
> On Thu, Aug 1, 2013 at 10:21 AM, R. David Murray 
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.

1. The recommended length limit for flowed text is still *72* (since it
doesn't have the structural constraints code does).
2. The preferred length limit for code is still 79.

The "up to 99 if it improves readability" escape clause was added because
Guido deemed the occasional long line a lesser evil than the contortions he
has seen people apply to code to stay within the 79 character limit (most
notably, using cryptic variable names because they're shorter).

That entire section of the PEP was completely rewritten - we didn't just
s/79/99/ with the old content.

Cheers,
Nick.

>
> 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.
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 446: Open issues/questions

2013-08-01 Thread Victor Stinner 
2013/7/30 Richard Oudkerk :
> The documentation for STARTUPINFO says this about STARTF_USESTDHANDLES:
>
>   If this flag is specified when calling one of the process creation
>   functions, the handles must be inheritable and the function's
>   bInheritHandles parameter must be set to TRUE.
>
> So, as I said, if you redirect the streams then you inherit all inheritable
> handles.

Outch! It means that all Python applications redirecting at least one
standard stream inherit almost all open handles, including open files.
The situation on Windows is worse than what I expected.

If I understood correctly, making new handles and new file descriptors
non-inheritable by default on Windows would improve the situation
because they will not stay "open" (they are not inheritable anymore)
in child processes.

On Windows, a file cannot be removed if at least one process opened
it. If you create a temporary file, run a program, and delete the
temporary file: the deletion fails if the program inherited the file
and the program is not done before the deletion. Is this correct?

I didn't check this use case on Windows, but it is similar to the
following Haskell (GHC) issue:
http://ghc.haskell.org/trac/ghc/ticket/2650

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 446: Open issues/questions

2013-08-01 Thread Victor Stinner 
2013/7/30 Victor Stinner :
> I would be nice to have a "pass_handles" on Windows.

I'm not sure that it's possible to implement this atomically. It's
probably better to leave the application to choose how the inheritance
is defined.

Example:

for handle in handles:
os.set_inheritable(handle, True)
subprocess.call(...)
for handle in handles:
os.set_inheritable(handle, False)

This example is safe if the application has a single thread (if a
single thread spawn new programs). Making handles non-inheritable
again may be useless.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 446: Open issues/questions

2013-08-01 Thread Victor Stinner 
2013/7/28 Antoine Pitrou :
>> (A) How should we support support where os.set_inheritable() is not
>> supported? Can we announce that os.set_inheritable() is always
>> available or not? Does such platform exist?
>
> FD_CLOEXEC is POSIX:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html

Ok, but this information does not help me. Does Python support
non-POSIX platforms? (Windows has HANDLE_FLAG_INHERIT.)

If we cannot answer to my question, it's safer to leave
os.get/set_inheritable() optional (need hasattr in tests for example).

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 446: Open issues/questions

2013-08-01 Thread Victor Stinner 
2013/7/30 Antoine Pitrou :
> Le Tue, 30 Jul 2013 09:09:38 +0200,
> Charles-François Natali  a écrit :
>> This looks more and more like PEP 433 :-)
>>
>> And honestly, when I think about it, I think that this whole mess is a
>> solution looking for a problem.
>> If we don't want to inherit file descriptors in child processes, the
>> answer is simple: the subprocess module (this fact is not even
>> mentioned in the PEP).
>
> This is a good point. Are there any reasons (other than fd inheritance)
> not to use subprocess? If there are, perhaps we should try to eliminate
> them by improving subprocess.

On Windows, inheritable handles (including open files) are still
inherited when a standard stream is overriden in the subprocess module
(default value of close_fds is set to False in this case). This issue
cannot be solved (at least, I don't see how): it is a limitation of
Windows. bInheritedHandles must be set to FALSE (inherit *all*
inheritable handles) when handles of standard streams are specified in
the startup information of CreateProcess().

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lambda [was Re: PEP 8 modernisation]

2013-08-01 Thread Vito De Tullio 
Steven D'Aprano wrote:

> Lambda is still useful for the reason lambda has always been useful: it is
> an expression, not a statement, so you can embed it directly where needed.

are there some possibilities to change def to an expression? do I need to 
wait 'till python9k?

yes, this brings to the possibility to write something like

foo = def bar():
pass

but at least should let the lambda to die in peace...


-- 
ZeD

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 446: Open issues/questions

2013-08-01 Thread Charles-François Natali 
2013/8/2 Victor Stinner :
> 2013/7/28 Antoine Pitrou :
>>> (A) How should we support support where os.set_inheritable() is not
>>> supported? Can we announce that os.set_inheritable() is always
>>> available or not? Does such platform exist?
>>
>> FD_CLOEXEC is POSIX:
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
>
> Ok, but this information does not help me. Does Python support
> non-POSIX platforms? (Windows has HANDLE_FLAG_INHERIT.)
>
> If we cannot answer to my question, it's safer to leave
> os.get/set_inheritable() optional (need hasattr in tests for example).

On Unix platforms, you should always have FD_CLOEXEC.
If there were such a platform without FD inheritance support, then it
would probably make sense to make it a no-op anyway.

cf
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 446: Open issues/questions

2013-08-01 Thread Charles-François Natali 
2013/8/2 Victor Stinner :
> On Windows, inheritable handles (including open files) are still
> inherited when a standard stream is overriden in the subprocess module
> (default value of close_fds is set to False in this case). This issue
> cannot be solved (at least, I don't see how): it is a limitation of
> Windows. bInheritedHandles must be set to FALSE (inherit *all*
> inheritable handles) when handles of standard streams are specified in
> the startup information of CreateProcess().

Then how about changing the default to creating file descriptors
unheritable on Windows (which is apparently the default)?
Then you can implement keep_fds by setting them inheritable right
before creation, and resetting them right after: sure there's a race
in a multi-threaded program, but AFAICT that's already the case right
now, and Windows API doesn't leave us any other choice.
Amusingly, they address this case by recommending putting process
creation in a critical section:
http://support.microsoft.com/kb/315939/en-us

This way, we keep default platform behavior on Unix and on Windows (so
user using low-level syscalls/APIs won't be surprised), and we have a
clean way to selectively inherit FD in child processes through
subprocess.

cf
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com