, formattazione dell'operatore di slice

Question

PEP 8 non menziona l'operatore di slice. Dalla mia comprensione, a differenza di altri operatori, non dovrebbe essere circondato da spazi bianchi

spam[3:5] # OK 
spam[3 : 5] # NOT OK 

Questo attesa quando si usano espressioni complesse, cioè, che uno è considerato migliore stile

 
    1. spam[ham(66)//3:44+eggs()] 
    2. spam[ham(66) // 3: 44 + eggs()] 
    3. spam[ham(66) // 3 : 44 + eggs()] 
    4. something else? 

Answer 1

Come già accennato, PEP8 non menziona esplicitamente l'operatore porzione in quel formato, ma spam[3:5] è decisamente più comune e IMHO più leggibile.

Se pep8 checker è tutto da seguire, lo spazio prima : verrà contrassegnato fino

[me@home]$ pep8 <(echo "spam[3:44]") # no warnings 
[me@home]$ pep8 <(echo "spam[3 : 44]") 
/dev/fd/63:1:7: E203 whitespace before ':' 

... ma questo è solo a causa di esso presuppone : ad essere l'operatore per definire una dict letterale e nessuno spazio è previsto prima dell'operatore. spam[3: 44] passa per quella ragione, ma questo non sembra giusto.

A tal proposito, vorrei attenermi a spam[3:44].

---

Le operazioni aritmetiche annidate sono un po 'più complicate. Dei tuoi 3 esempi, solo il 2 ° si passa la convalida PEP8:

[me@home]$ pep8 <(echo "spam[ham(66)//3:44+eggs()]") 
/dev/fd/63:1:13: E225 missing whitespace around operator 

[me@home]$ pep8 <(echo "spam[ham(66) // 3:44 + eggs()]") # OK 

[me@home]$ pep8 <(echo "spam[ham(66) // 3 : 44 + eggs()]") 
/dev/fd/63:1:18: E203 whitespace before ':' 

Tuttavia, ritengo che tutto quanto sopra difficili da analizzare con occhio al primo sguardo.

Per facilitare la lettura e l'osservanza PEP8, io personalmente andare per:

spam[(ham(66) // 3):(44 + eggs())] 

o per ulteriori operazioni di complicazione:

s_from = ham(66) // 3 
s_to = 44 + eggs() 
spam[s_from:s_to] 

Answer 2

Sono d'accordo con la tua primo esempio Per quest'ultimo: PEP 20. Conta la leggibilità La parte semanticamente più importante della tua complessa espressione di sezione è l'operatore di slice stesso, divide l'espressione in due parti che devono essere analizzate separatamente (sia dal lettore umano che dall'interprete). Quindi la mia intuizione è che la coerenza con PEP 8 dovrebbe essere sacrificata per evidenziare l'operatore :, ad es. circondandolo con spazi bianchi come nell'esempio 3. domanda è se omettendo gli spazi bianchi all'interno dei due lati della espressione aumenta la leggibilità o no:

1. spam[ham(66)/3 : 44+eggs()] 

vs.

2. spam[ham(66)/3 : 44 + eggs()] 

trovo 1. veloce analizzare.

Answer 3

Vedo affettare utilizzato in PEP8:

 
    - Use ''.startswith() and ''.endswith() instead of string slicing to check 
     for prefixes or suffixes. 

     startswith() and endswith() are cleaner and less error prone. For 
     example: 

     Yes: if foo.startswith('bar'): 

     No: if foo[:3] == 'bar': 

Non direi che definitiva, ma esegue il backup (e la mia) comprensione:

spam[3:5] # OK 

Per quanto riguarda quale da usare nella situazione più complessa, userei # 3. Non credo che il metodo non-spazi-around-the-: guarda bene in quel caso:

spam[ham(66)/3:44 + eggs()] # looks like it has a time in the middle. Bad. 

Se si desidera che il : per stare di più, non sacrificare la spaziatura operatore, aggiungere spazi aggiuntivi per il ::

spam[ham(66)/3 : 44 + eggs()] # Wow, it's easy to read! 

non userei 1 # perché mi piace la spaziatura operatore, e # 2 sembra troppo simile al dizionario key: value sintassi.

Inoltre, non lo chiamerei operatore. E 'sintassi speciale per la costruzione di un oggetto slice - si potrebbe anche fare

spam[slice(3, 5)]