On 01Aug2020 13:32, Chris Green wrote:
>Having (after lots of help from here, thank you) finally converted my
>Python 2, gtk 2 program to Python 3 and pygobject gtk 3 I'm left with
>a couple of what might be called style questions.
>
>I guess it's mostly down to what feels right to me but there
Having (after lots of help from here, thank you) finally converted my
Python 2, gtk 2 program to Python 3 and pygobject gtk 3 I'm left with
a couple of what might be called style questions.
I guess it's mostly down to what feels right to me but there may be
good reasons for choosing one way over
On Sun, 29 May 2016 03:00 am, Steven D'Aprano wrote:
> On Sun, 29 May 2016 02:15 am, Gerald Britton wrote:
>
>> suppose I have a simple python project setup like this:
[...]
To which I responded:
> If this is a single project, why do you set it up like this? Is there a
> reason why you don't
On Sun, 29 May 2016 02:15 am, Gerald Britton wrote:
> suppose I have a simple python project setup like this:
>
> Project diectory
> prog.py
> pkg directory
> __init__.py
> mod1.py
>class A:
If this is a single project, why do you set it up like
suppose I have a simple python project setup like this:
Project diectory
prog.py
pkg directory
__init__.py
mod1.py
class A:
In order to have class A (unqualified) available from prog.py, there are a
few options that I know about. I'm currently
On 12/03/2014 12:02 PM, Chris Angelico wrote:
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package
- Original Message -
From: Chris Angelico ros...@gmail.com
To: python-list@python.org
Sent: Wednesday, 3 December, 2014 12:02:17 PM
Subject: Style question: Importing modules from packages - 'from' vs 'as'
When importing a module from a subpackage, it's sometimes convenient
On 12/04/2014 09:36 AM, Jean-Michel Pichavant wrote:
I know you specifically stated you didn't want to do this but
import os
os.path.isfile()
is the best option imo, especially from the reader point of view (Namespaces
are one honking great idea).
But, Flat is better than nested
On 12/03/2014 03:02 AM, Chris Angelico wrote:
Throughout the code, I want to refer to path.split(),
path.isfile(), etc, without the os. in front of them. I could do
either of these:
import os.path as path
from os import path
Which one would you recommend? Does it depend on context?
I
On Fri, Dec 5, 2014 at 4:36 AM, Jean-Michel Pichavant
jeanmic...@sequans.com wrote:
I know you specifically stated you didn't want to do this but
import os
os.path.isfile()
is the best option imo, especially from the reader point of view (Namespaces
are one honking great idea).
With
On 04.12.2014 19:05, Chris Angelico wrote:
With os.path it definitely is. With the actual code in question, it's
a Python 2.7 project that mostly uses relative imports - inside
package.module1 is import module2 etc - and I was writing an
external script that calls on one of the modules.
What
On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier
wolfgang.ma...@biologie.uni-freiburg.de wrote:
On 04.12.2014 19:05, Chris Angelico wrote:
With os.path it definitely is. With the actual code in question, it's
a Python 2.7 project that mostly uses relative imports - inside
package.module1 is
On 04.12.2014 22:30, Chris Angelico wrote:
On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier
wolfgang.ma...@biologie.uni-freiburg.de wrote:
On 04.12.2014 19:05, Chris Angelico wrote:
With os.path it definitely is. With the actual code in question, it's
a Python 2.7 project that mostly uses
On Fri, Dec 5, 2014 at 9:10 AM, Wolfgang Maier
wolfgang.ma...@biologie.uni-freiburg.de wrote:
which I read as there has been a stepwise transition between 2.5 and 2.7 so
that 2.7 now behaves like Python 3 even without the __future__ statement.
OTOH, I believe you, of course, if you're saying
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package name is, in the
application, quite superfluous.
On 3 December 2014 at 22:02, Chris Angelico ros...@gmail.com wrote:
import os.path as path
from os import path
Bah - deleted the list and sent directly to Chris ... time to go to bed.
The advantage of the former is that if you want to use a different name,
it's a smaller change. But the
Chris Angelico wrote:
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package name is, in the
On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten __pete...@web.de wrote:
Don't repeat yourself, so
from os import path
always. On the other hand I have never thought about actual renames, e. g.
from os import path as stdpath
versus
import os.path as stdpath
I think I'd use the latter as
On Dec 3, 2014 4:34 AM, Chris Angelico ros...@gmail.com wrote:
On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten __pete...@web.de wrote:
Don't repeat yourself, so
from os import path
always. On the other hand I have never thought about actual renames, e.
g.
from os import path as
On 12/3/2014 6:02 AM, Chris Angelico wrote:
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package name
On Thursday, October 30, 2014 4:10:23 AM UTC-7, Steven D'Aprano wrote:
I don't particularly like either version. I prefer this:
def load_int(obj):
if isinstance(obj, int):
# Case 1), an int, e.g. 7
return obj
elif isinstance(obj, str):
# Case 2) and 3), a
Anton wrote:
Let's say I have an incoming list of values *l*. Every element of *l* can
be one of the following options:
1) an integer value
2) a string in form of 'int_value', e.g. '7'
3) a string with a json serialization of an integer value, e.g. '7'
4) something else that should be
On 2014-10-30 11:10, Steven D'Aprano wrote:
Anton wrote:
Let's say I have an incoming list of values *l*. Every element of *l* can
be one of the following options:
1) an integer value
2) a string in form of 'int_value', e.g. '7'
3) a string with a json serialization of an integer value, e.g.
MRAB wrote:
On 2014-10-30 11:10, Steven D'Aprano wrote:
Anton wrote:
Let's say I have an incoming list of values *l*. Every element of *l*
can be one of the following options:
1) an integer value
2) a string in form of 'int_value', e.g. '7'
3) a string with a json serialization of an
In article 54521c8f$0$12982$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Anton wrote:
Let's say I have an incoming list of values *l*. Every element of *l* can
be one of the following options:
1) an integer value
2) a string in form
Roy Smith wrote:
In article 54521c8f$0$12982$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Anton wrote:
Let's say I have an incoming list of values *l*. Every element of *l*
can be one of the following options:
1) an integer value
On Fri, 31 Oct 2014 09:48:10 +1100, Steven D'Aprano wrote:
MRAB wrote:
How about:
int(str(obj).strip(''))
Absolutely not.
obj = '1\n\n\n\n' # not valid JSON load_int(obj)
= raises ValueError int(str(obj).strip(''))
= wrongly returns 1
How about
#!/usr/bin/python
import re, json
Let's say I have an incoming list of values *l*. Every element of *l* can be
one of the following options:
1) an integer value
2) a string in form of 'int_value', e.g. '7'
3) a string with a json serialization of an integer value, e.g. '7'
4) something else that should be ignored
I need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29/10/2014 10:45, Anton wrote:
Let's say I have an incoming list of values *l*. Every element of
*l* can be one of the following options: 1) an integer value 2) a
string in form of 'int_value', e.g. '7' 3) a string with a json
serialization of
Hi, first in Python 2.7.6 and Python 3.4.0 list haven't got any add
function but they have append.
I think you could do better with something like
==
import json
l = [1, -1, 0, '1', '-1', '0', json.dumps(-1), json.dumps(1),
json.dumps(0), 'x', 'sqjklsqjk__', (1, 2)]
values = []
for c
2014-10-29 12:25 GMT+01:00 Martin Kemp martin.k...@ingg.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29/10/2014 10:45, Anton wrote:
Let's say I have an incoming list of values *l*. Every element of
*l* can be one of the following options: 1) an integer value 2) a
string in form of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29/10/2014 12:01, Rafael Romero Carmona wrote:
2014-10-29 12:25 GMT+01:00 Martin Kemp martin.k...@ingg.com: On
29/10/2014 10:45, Anton wrote:
Let's say I have an incoming list of values *l*. Every
element of *l* can be one of the following
On Wednesday, October 29, 2014 4:43:33 AM UTC-7, Rafael Romero Carmona wrote:
Hi, first in Python 2.7.6 and Python 3.4.0 list haven't got any add
function but they have append.
You are right, in my original code I use set instead of array, so it should be
either values = set() or
On Wednesday, October 29, 2014 4:59:25 AM UTC-7, Rafael Romero Carmona wrote:
2014-10-29 12:25 GMT+01:00 Martin Kemp mar...@ingg.com:
Actually it doesn't work because there is no add function and it
doesn't catch the TypeError function to ignore other exceptions than
ValueError. Doesn't it? I
Am 09.05.2013 02:38 schrieb Colin J. Williams:
On 08/05/2013 4:20 PM, Roy Smith wrote:
A list of FooEntry's +1
Go back to school. Both of you...
That is NOT the way to build a plural form...
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
On 2013-05-08, Denis McMahon denismfmcma...@gmail.com wrote:
On Wed, 08 May 2013 16:20:48 -0400, Roy Smith wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
A list of FooEntries
A list of FooEntrys
A list of FooEntry's
A list of FooEntry instances
Neil Cerutti writes:
If there's no chance for confusion between a class named FooEntry
and another named FooEntries, then the first attempt seems best.
Pluralize a class name by following the usual rules, e.g.,
strings and ints.
Like strings would be foo entries. Which might work well.
(I
On 2013-05-09, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote:
Neil Cerutti writes:
If there's no chance for confusion between a class named
FooEntry and another named FooEntries, then the first attempt
seems best. Pluralize a class name by following the usual
rules, e.g., strings and
On 2013-05-08 21:20, Roy Smith wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
A list of FooEntries
A list of FooEntrys
A list of FooEntry's
A list of FooEntry instances
The first one certainly sounds the best, but it seems wierd to change
the spelling of
FooEntry is a class. How would you describe a list of these in a
docstring?
A list of FooEntries
A list of FooEntrys
A list of FooEntry's
A list of FooEntry instances
The first one certainly sounds the best, but it seems wierd to change
the spelling of the class name to make it plural.
--
This one:
A list of FooEntry instances
Besides the obvious spelling issues in the others, it's not
immediately clear if the list contains just FooEntry instances,
FooEntry classes (perhaps subclasses) or a mix of the two. #4 makes
it clear.
Skip
--
On Wed, May 8, 2013 at 4:20 PM, Roy Smith r...@panix.com wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
A list of FooEntries
A list of FooEntrys
A list of FooEntry's
A list of FooEntry instances
The first one certainly sounds the best, but it seems
On Wed, May 8, 2013 at 2:37 PM, John Downs john.a.do...@gmail.com wrote:
On Wed, May 8, 2013 at 4:20 PM, Roy Smith r...@panix.com wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
A list of FooEntries
A list of FooEntrys
A list of FooEntry's
A list of
On Wed, 08 May 2013 16:20:48 -0400, Roy Smith wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
A list of FooEntries
A list of FooEntrys
A list of FooEntry's
A list of FooEntry instances
The first one certainly sounds the best, but it seems wierd
On Wed, 08 May 2013 16:20:48 -0400, Roy Smith wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
Which language are you writing your docstrings in? Obey the normal rules
of spelling, grammar and punctuation for your language, which I assume is
English.
A
On Thu, May 9, 2013 at 6:20 AM, Roy Smith r...@panix.com wrote:
A list of FooEntry's
Only if you put another apostrophe in:
A list of 'FooEntry's
But the delimited style is almost never of use. I'd go for this only
if there were some sort of automated markup being applied - if the
word
On Wed, 08 May 2013 15:33:07 -0500, Skip Montanaro wrote:
This one:
A list of FooEntry instances
Besides the obvious spelling issues in the others, it's not immediately
clear if the list contains just FooEntry instances, FooEntry classes
(perhaps subclasses) or a mix of the two. #4
On 08/05/2013 4:20 PM, Roy Smith wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
A list of FooEntries 0
A list of FooEntrys -1
A list of FooEntry's +1
A list of FooEntry instances No FooEntry is specified as a class.
The first one certainly sounds
On 09May2013 00:02, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info
wrote:
| On Wed, 08 May 2013 16:20:48 -0400, Roy Smith wrote:
| A list of FooEntry's
|
| Here come's an S! Quick, jam on an apostrophe!
|
| This is called the grocer's apostrophe, and is universally held in
| contempt no
The standard is to use `cls`. In the __new__ method you can use `mcl` or `meta`.
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Jul 17, 2012 at 6:23 AM, Michele Simionato
michele.simion...@gmail.com wrote:
The standard is to use `cls`. In the __new__ method you can use `mcl` or
`meta`.
I've also seen `mcs` a fair amount.
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Jul 17, 2012 at 12:10 AM, alex23 wuwe...@gmail.com wrote:
On Jul 17, 1:29 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
Here's a style question for you: in a metaclass, what should I call the
instance parameter of methods, cls or self?
Maybe portmanteu
On Tue, 17 Jul 2012 05:23:22 -0700, Michele Simionato wrote:
The standard is to use `cls`. In the __new__ method you can use `mcl` or
`meta`.
Thanks to everyone who answered.
I think I will stick with meta and cls.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Here's a style question for you: in a metaclass, what should I call the
instance parameter of methods, cls or self?
class ExampleMeta(type):
def method(self, *args): ...
I'm not quite sure if that feels right. On the one hand, self is the
ExampleMeta instance alright... but on the other
On 7/16/2012 11:29 AM, Steven D'Aprano wrote:
Here's a style question for you: in a metaclass, what should I call the
instance parameter of methods, cls or self?
class ExampleMeta(type):
def method(self, *args): ...
I'm not quite sure if that feels right. On the one hand, self
On Wednesday, 14 March 2012 21:16:05 UTC, Terry Reedy wrote:
On 3/14/2012 4:49 PM, Arnaud Delobelle wrote:
On 14 March 2012 20:37, Croephacroe...@gmail.com wrote:
Which is preferred:
for value in list:
if not value is another_value:
value.do_something()
break
Do you
Which is preferred:
for value in list:
if not value is another_value:
value.do_something()
break
--or--
if list and not list[0] is another_value:
list[0].do_something()
Comments are welcome, Thanks
--
http://mail.python.org/mailman/listinfo/python-list
On 14 March 2012 20:37, Croepha croe...@gmail.com wrote:
Which is preferred:
for value in list:
if not value is another_value:
value.do_something()
break
--or--
if list and not list[0] is another_value:
list[0].do_something()
Hard to say, since they don't do the same thing :)
On 3/14/2012 4:49 PM, Arnaud Delobelle wrote:
On 14 March 2012 20:37, Croephacroe...@gmail.com wrote:
Which is preferred:
for value in list:
if not value is another_value:
value.do_something()
break
Do you really mean 'is' or '=='?
If you mean x is not y, write it that way.
'not
Which is preferred:
for value in list:
if not value is another_value:
value.do_something()
break
Do you really mean 'is' or '=='?
Let me expound on how 'is' and '==' are very different. It may work
for some comparisons but often not for others. Certain examples work
On 14 March 2012 22:15, Prasad, Ramit ramit.pra...@jpmorgan.com wrote:
Only use 'is' if you are looking for objects like True,
False, None or something that MUST be exactly the same object.
I've rarely seen valid uses of 'is True' or 'is False'.
--
Arnaud
--
Only use 'is' if you are looking for objects like True,
False, None or something that MUST be exactly the same object.
I've rarely seen valid uses of 'is True' or 'is False'.
It can be useful when you think something might be None or False. Although,
I suppose you could always just use 'is
On Thu, Mar 15, 2012 at 7:37 AM, Croepha croe...@gmail.com wrote:
Which is preferred:
for value in list:
if not value is another_value:
value.do_something()
break
--or--
if list and not list[0] is another_value:
list[0].do_something()
Comments are welcome, Thanks
General
Gerald Britton wrote:
however, considering what
import a.module.that.is.quite.nested as myModule
Won't work since I get the objects at run time
myModule = __import__('whatever.module.imported.at.run.time', globals(),
locals(), [], -1)
See
Gerald Britton wrote:
Nope. it's nothing to do with imports. It's about objects passed to
methods at run time. Complicated objects with many levels. Not about
modules at all.
Who is providing these objects ?
- Your code ? = as said before, you can fix your design with a proper
object
Gerald Britton wrote:
Hi all,
Today I was thinking about a problem I often encounter.
[snip]
1. You need to call this thing many times with different arguments, so
you wind up with:
x = some.deeply.nested.object.method(some.other.deeply.nested.object.value1)
y =
Hi all,
Today I was thinking about a problem I often encounter. Say that I
have (seems I often do!) a deeply nested object, by which I mean
object within object with object, etc.
For example:
x = some.deeply.nested.object.method(some.other.deeply.nested.object.value)
Well, that's extreme
On Jan 30, 11:51 am, Gerald Britton gerald.brit...@gmail.com wrote:
[...]
that I might confuse with the first. To make it look better I might do this:
_o = some.deeply.nested.object
_o.method(_o.value)
which is fine, I suppose.
It is very fine. And you supposed correctly!
Then,
In article mailman.1469.1296409883.6505.python-l...@python.org,
Gerald Britton gerald.brit...@gmail.com wrote:
1. You need to call this thing many times with different arguments, so
you wind up with:
x =
some.deeply.nested.object.method(some.other.deeply.nested.object.value1)
y =
On 1/30/11 9:51 AM, Gerald Britton wrote:
1. If you had to choose between approaches 1 and 2, which one would
you go for, and why?
Neither. Ideally, I'd tweak the API around so the deeply nested
structure isn't something I need to access regularly. But! If you can't
do that, I'd do something
On Jan 30, 12:23 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
--- start
from contextlib import contextmanager
class Item(object): pass
deeply = Item()
deeply.nested = Item()
deeply.nested.thing = Item()
@contextmanager
def my(thing):
yield thing
with
On 1/30/11 10:35 AM, rantingrick wrote:
Well congratulations Stephen, you win the obfuscation prize of the
year!
Yes,
On 1/30/11 10:09 AM, rantingrick wrote:
Here is how a pythonic local block would look
with this as localvar:
localvar.do_something()
verses
with my(this) as localvar:
On 30/01/2011 17:51, Gerald Britton wrote:
Hi all,
Today I was thinking about a problem I often encounter. Say that I
have (seems I often do!) a deeply nested object, by which I mean
object within object with object, etc.
For example:
x =
On Jan 30, 12:53 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
On 1/30/11 10:35 AM, rantingrick wrote:
Well congratulations Stephen, you win the obfuscation prize of the
year!
Yes,
On 1/30/11 10:09 AM, rantingrick wrote:
Here is how a pythonic local block would look
with this
I don't. I don't expect anyone to write 10 lines of obfuscation code
when just two will suffice. Maybe you should join the perl group as
they would proud!
But Stephen's 10 lines of somewhat obscure code actually works, and your two
lines of code doesn't. I know which one I would prefer.
--
On Sun, 30 Jan 2011 12:51:20 -0500, Gerald Britton wrote:
Hi all,
Today I was thinking about a problem I often encounter. Say that I have
(seems I often do!) a deeply nested object, by which I mean object
within object with object, etc.
For example:
x =
On 1/30/11 1:13 PM, rantingrick wrote:
On Jan 30, 12:53 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote:
OH MY GOD. How can someone be expected to understand what a function does!
Yes, and also how decorators word and generators work, and ...
Be serious! You can't expect that of them.
I'd bet you would stress your point Steven! But you don't need to persuade me,
I do already agree.
I just meant to say that, when the advantage is little, there's no need to
rewrite a working function.
And that with modern CPUs, if tests take so little time, that even some
redundant one is not
On Sat, 18 Dec 2010 19:59:45 -0800, Carl Banks wrote:
On Dec 17, 12:23 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Thu, 16 Dec 2010 20:32:29 -0800, Carl Banks wrote:
Even without the cleanup issue, sometimes you want to edit a function
to affect all return values
On 17/12/2010 0.51, Steven D'Aprano wrote:
Don't get me wrong... spaghetti code is*bad*. But there are other ways
of writing bad code too, and hanging around inside a function long after
you've finished is also bad:
def function(arg):
done = False
do_something()
if
On Sat, 18 Dec 2010 12:29:31 +0100, Francesco wrote:
[...]
I agree to your point, but I'm afraid you chose a wrong example (AFAIK,
and that's not much). Sure, the second version of function(arg) is much
more readable, but why do you think the first one would do *lots* of
unnecessary work?
On Dec 17, 12:23 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Thu, 16 Dec 2010 20:32:29 -0800, Carl Banks wrote:
Even without the cleanup issue, sometimes you want to edit a function to
affect all return values somehow. If you have a single exit point you
just make
On Thu, 16 Dec 2010 20:32:29 -0800, Carl Banks wrote:
Even without the cleanup issue, sometimes you want to edit a function to
affect all return values somehow. If you have a single exit point you
just make the change there; if you have mulitple you have to hunt them
down and change all of
John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def myMethod(self, arg1, arg2
-Original Message-
What about,
def myMethod():
for condition, exitCode in [
(cond1, 'error1'),
(cond2, 'very bad error'),
]:
if not condition:
break
else:
do_some_usefull_stuff() # executed only if the we never hit the
break
On Fri, 17 Dec 2010 09:09:49 -0500, Rob Richardson wrote:
First, just to clarify, I don't think the indentation I saw was what was
originally posted. The else must be indented to match the if, and
the two statements under else are in the else block. The return
statement is indented at the
Rob Richardson wrote:
-Original Message-
What about,
def myMethod():
for condition, exitCode in [
(cond1, 'error1'),
(cond2, 'very bad error'),
]:
if not condition:
break
else:
do_some_usefull_stuff() # executed only if the
On Thu, Dec 16, 2010 at 6:51 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
...
Functions always have one entry. The only way to have multiple entry
points is if the language allows you to GOTO into the middle of a
function, and Python sensibly does not allow this. The one
On 12/17/2010 9:38 AM, Steven D'Aprano wrote:
On Fri, 17 Dec 2010 09:09:49 -0500, Rob Richardson wrote:
First, just to clarify, I don't think the indentation I saw was what was
originally posted. The else must be indented to match the if, and
the two statements under else are in the else
My thanks for pointing out the existence of the else: suite in the for
statement. However, I remain confused. For reference, here's the
original code:
def myMethod():
for condition, exitCode in [
(cond1, 'error1'),
(cond2, 'very bad error'),
]:
if
On 17/12/2010 15:53, Steve Holden wrote:
[... snip example of for-else ...]
This construct appears to be unpopular in actual use, and when it comes
up in classes and seminars there is always interesting debate as people
discuss potential uses and realise there are useful applications.
I use
Jean-Michel Pichavant jeanmic...@sequans.com writes:
What about,
def myMethod():
for condition, exitCode in [
(cond1, 'error1'),
(cond2, 'very bad error'),
]:
if not condition:
break
else:
do_some_usefull_stuff() # executed only if
Rob Richardson wrote:
My thanks for pointing out the existence of the else: suite in the for
statement. However, I remain confused. For reference, here's the
original code:
def myMethod():
for condition, exitCode in [
(cond1, 'error1'),
(cond2, 'very bad error'),
On 12/17/2010 11:13 AM, Tim Golden wrote:
On 17/12/2010 15:53, Steve Holden wrote:
[... snip example of for-else ...]
This construct appears to be unpopular in actual use, and when it comes
up in classes and seminars there is always interesting debate as people
discuss potential uses and
Steve Holden st...@holdenweb.com writes:
I think the choice of keyword is probably not Guido's crowning
language achievement,
I remember the behaviour by considering a typical application:
for thing in things:
if shinyp(thing):
break
else:
raise
Tim Golden m...@timgolden.me.uk writes:
On 17/12/2010 15:53, Steve Holden wrote:
[... snip example of for-else ...]
This construct appears to be unpopular in actual use, and when it comes
up in classes and seminars there is always interesting debate as people
discuss potential uses and
I now remember this idiom as the break else construct: either the loop
breaks, or the else: suite is executed.
A perfect description.
Malcolm
--
http://mail.python.org/mailman/listinfo/python-list
On 2010-12-16, Stefan Sonnenberg-Carstens stefan.sonnenb...@pythonmeister.com
wrote:
The advantage in latter case is fewer operations, because you can
skip the assignments, and it is more readable.
The one entry, one exit is an advice. Not a law.
Your code is OK.
As long as it works ;-)
On 2010-12-16, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Thu, 16 Dec 2010 21:49:07 +, John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I
-Original Message-
You have outlined what happens when cond1 and cond2 both evaluate to
True -- what happens if, say, cond2 evaluates to False?
- I reply
And the light goes on! (And palm strikes forehead.) I was thinking
that the error we were processing was raised
1 - 100 of 216 matches
Mail list logo
