[resent since I accidentally dropped the list]
Hi,
On 19 April 2012 15:55, Barry Warsaw wrote:
> I'll make this change to the PEP. I'm not entirely sure the Yes/No examples
> are great illustrations of this change in wording though. Here's the diff so
> far (uncommitted):
>
> diff -r 34076bfed
was sent to Barry-only by mistake
On Thu, Apr 19, 2012 at 17:20, Tshepang Lekhonkhobe wrote:
> On Thu, Apr 19, 2012 at 17:15, Barry Warsaw wrote:
>> If I change that phrase to "Use your own judgement" does that help?
>
> I would prefer "This is a matter of taste...". Much closer to original
> me
If I change that phrase to "Use your own judgement" does that help?
It does. It may also help fight the mindset that PEP 8 is a Law.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
On Thu, Apr 19, 2012 at 11:15:38AM -0400, Barry Warsaw wrote:
> On Apr 19, 2012, at 11:00 AM, ??ric Araujo wrote:
> >> +- If operators with different priorities are used, consider adding
> >> + whitespace around the operators with the lowest priority(ies). This
> >> + is very much to taste; howe
On Apr 19, 2012, at 11:00 AM, Éric Araujo wrote:
>Hi,
>
>> +- If operators with different priorities are used, consider adding
>> + whitespace around the operators with the lowest priority(ies). This
>> + is very much to taste; however, never use more than one space, and
>> + always have the sa
On Fri, Apr 20, 2012 at 1:00 AM, Éric Araujo wrote:
> Hi,
>
>> +- If operators with different priorities are used, consider adding
>> + whitespace around the operators with the lowest priority(ies). This
>> + is very much to taste; however, never use more than one space, and
>> + always have th
Hi,
+- If operators with different priorities are used, consider adding
+ whitespace around the operators with the lowest priority(ies). This
+ is very much to taste; however, never use more than one space, and
+ always have the same amount of whitespace on both sides of a binary
+ operator.
On Apr 18, 2012, at 09:26 PM, Guido van Rossum wrote:
>On Wed, Apr 18, 2012 at 8:14 PM, Chris Angelico wrote:
>> On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote:
>>> (quoting GvR)
Let's change this to something more reasonable, e.g.
"""
If operators with different priori
On Apr 18, 2012, at 1:38 PM, Guido van Rossum wrote:
>
> Let's change this to something more reasonable, e.g.
>
> """
> If operators with different priorities are used, consider adding
> whitespace around the operators with the lowest priority(ies). This is
> very much to taste, however, never
On Wed, Apr 18, 2012 at 8:14 PM, Chris Angelico wrote:
> On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote:
>> (quoting GvR)
>>> Let's change this to something more reasonable, e.g.
>>>
>>> """
>>> If operators with different priorities are used, consider adding
>>> whitespace around the opera
On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote:
> (quoting GvR)
>> Let's change this to something more reasonable, e.g.
>>
>> """
>> If operators with different priorities are used, consider adding
>> whitespace around the operators with the lowest priority(ies). This is
>> very much to tast
>>> Quoting from
>>> http://www.python.org/dev/peps/pep-0008/#other-recommendations
>>> (with elision):
>>>
>>> Use spaces around arithmetic operators:
>>> No:
>>> i=i+1
>>> submitted +=1
>>> x = x*2 - 1
>>> hypot2 = x*x + y*y
>>> c = (a+b) * (a-b)
>>>
>>> End quote
Hrvoje Niksic wrote:
The same oddity occurs with expressions in kwargs calls:
func(pos1, pos2, keyword=foo + bar)
I find myself wanting to add parentheses arround the + to make the code
clearer.
Then why don't you?
In the above example, spaces around the + are not only optional but
discou
On Wed, Apr 18, 2012 at 9:25 AM, Georg Brandl wrote:
> On 18.04.2012 17:47, Chris Angelico wrote:
>>
>> On Thu, Apr 19, 2012 at 12:47 AM, Guido van Rossum
>> wrote:
>>>
>>> I don't believe PEP 8 requires whitespace around all binary operators.
>>> Where do you read that?
>>
>>
>> Quoting from
>
On 18.04.2012 17:47, Chris Angelico wrote:
On Thu, Apr 19, 2012 at 12:47 AM, Guido van Rossum wrote:
I don't believe PEP 8 requires whitespace around all binary operators.
Where do you read that?
Quoting from http://www.python.org/dev/peps/pep-0008/#other-recommendations
(with elision):
Us
On Thu, Apr 19, 2012 at 12:47 AM, Guido van Rossum wrote:
> I don't believe PEP 8 requires whitespace around all binary operators.
> Where do you read that?
Quoting from http://www.python.org/dev/peps/pep-0008/#other-recommendations
(with elision):
Use spaces around arithmetic operators:
No:
On Wed, Apr 18, 2012 at 1:29 AM, Floris Bruynooghe wrote:
> And since this is OT by now, one of the other pep8 annoyances I
> have[0] is the blanket whitespace around arithmetic operators,
> including **. To me the first just looks ugly:
>
1024 ** 2
1024**2
>
> Certainly when the expres
On 17 April 2012 16:36, Barry Warsaw wrote:
> On Apr 17, 2012, at 08:25 AM, R. David Murray wrote:
>
>>On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote:
>>> On 16.4.2012 18:10, Nam Nguyen wrote:
>>> > a_list[pos + 1 : -1]
>>>
>>> or other way around
>>>
>>> a_list[pos+1:-1]
>>
>>
>>That's wha
On 04/17/2012 04:21 PM, Guido van Rossum wrote:
I hope that's now what it says about slices -- that was meant for dict
displays. For slices it should be symmetrical. In this case I would
remove the spaces around the +, but it's okay to add spaces around the
: too. It does look odd to have an oper
On Apr 17, 2012, at 08:25 AM, R. David Murray wrote:
>On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote:
>> On 16.4.2012 18:10, Nam Nguyen wrote:
>> > a_list[pos + 1 : -1]
>>
>> or other way around
>>
>> a_list[pos+1:-1]
>
>
>That's what I always use. No spaces inside the brackets for me :)
On Tue, Apr 17, 2012 at 12:14 AM, Paul Moore wrote:
> On 16 April 2012 17:10, Nam Nguyen wrote:
>> PEP 8 suggests no extra spaces after and before square brackets, and
>> colons. So code like this is appropriate:
>>
>> a_list[1:3]
>>
>> But I find it less readable in the case of:
>>
>> a_list[pos
Paul Moore dixit (2012-04-17, 08:14):
> On 16 April 2012 17:10, Nam Nguyen wrote:
> > PEP 8 suggests no extra spaces after and before square brackets, and
> > colons. So code like this is appropriate:
> >
> > a_list[1:3]
> >
> > But I find it less readable in the case of:
> >
> > a_list[pos + 1:-
On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote:
> On 16.4.2012 18:10, Nam Nguyen wrote:
> > a_list[pos + 1 : -1]
>
> or other way around
>
> a_list[pos+1:-1]
That's what I always use. No spaces inside the brackets for me :)
If the expression gets unreadable that way, factor it out.
--
On 16 April 2012 17:10, Nam Nguyen wrote:
> PEP 8 suggests no extra spaces after and before square brackets, and
> colons. So code like this is appropriate:
>
> a_list[1:3]
>
> But I find it less readable in the case of:
>
> a_list[pos + 1:-1]
>
> The colon is seemingly lost in the right.
>
> Woul
On 16.4.2012 18:10, Nam Nguyen wrote:
a_list[pos + 1 : -1]
or other way around
a_list[pos+1:-1]
?
Matěj
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
On Mon, Apr 16, 2012 at 8:30 AM, Barry Warsaw wrote:
> On Apr 15, 2012, at 01:13 PM, Raymond Hettinger wrote:
>
>>We should publish some advice on creating content managers.
>
> I agree, I'm just not sure PEP 8 is the right place for it.
>
> PEP 8 seems like it is structured more as mechanical gui
On Apr 15, 2012, at 01:13 PM, Raymond Hettinger wrote:
>We should publish some advice on creating content managers.
I agree, I'm just not sure PEP 8 is the right place for it.
PEP 8 seems like it is structured more as mechanical guidelines for the look
and feel of code, not so much for the seman
On 15 April 2012 18:13, Raymond Hettinger wrote:
> We should publish some advice on creating content managers.
>
> Context managers are a general purpose tool but have a primary
> use case of creating and releasing resources. This creates an
> expectation that that is what the context managers ar
On Mon, Apr 16, 2012 at 3:13 AM, Raymond Hettinger
wrote:
> Instead, the context manager implements a different behavior. It would
> have been better if that behavior had been given a name:
>
> db = sqlite3.connect(filename)
> with auto_commit_or_rollback(db):
> # do a transaction
We should publish some advice on creating content managers.
Context managers are a general purpose tool but have a primary
use case of creating and releasing resources. This creates an
expectation that that is what the context managers are doing unless
they explicitly say otherwise.
For example
30 matches
Mail list logo
