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 ma
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 a
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 ju
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 this
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 conside
On Fri, Dec 5, 2014 at 9:10 AM, Wolfgang Maier
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 implicit relative imports
> are working
On 04.12.2014 22:30, Chris Angelico wrote:
On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier
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 Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier
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 "import module2" etc - and I wa
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 4: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").
With os.path it defini
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 o
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
- Original Message -
> From: "Chris Angelico"
> 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 subpac
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 nam
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 Dec 3, 2014 4:34 AM, "Chris Angelico" 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 std
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 t
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
> ap
On 3 December 2014 at 22:02, Chris Angelico 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 disadvantage of
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.
Th
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
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
#!/us
Roy Smith wrote:
> In article <54521c8f$0$12982$c3e8da3$54964...@news.astraweb.com>,
> 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 f
In article <54521c8f$0$12982$c3e8da3$54964...@news.astraweb.com>,
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 '', e.g. '7'
> > 3) a
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 '', e.g. '7'
>>> 3) a string with a json serialization
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 '', e.g. '7'
3) a string with a json serialization of an integer value, e.g. '"7"'
4) so
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 '', e.g. '7'
> 3) a string with a json serialization of an integer value, e.g. '"7"'
> 4) something else that should be ignor
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 :
> 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 tested in Py
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 values.append
-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 : 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
2014-10-29 12:25 GMT+01:00 Martin Kemp :
> -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 '', e.g. '7
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 in
-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 '', e.g. '7' 3) a string with a json
> serialization of an int
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 '', 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 transform th
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 spel
On 2013-05-09, Jussi Piitulainen 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 "ints".
>
> Like "s
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
On 2013-05-08, Denis McMahon 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 instan
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 09May2013 00:02, Steven D'Aprano
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 matter what variant of English
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 so
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.
On Thu, May 9, 2013 at 6:20 AM, Roy Smith 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 FooEntry were tur
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.
>
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,
On Wed, May 8, 2013 at 2:37 PM, John Downs wrote:
> On Wed, May 8, 2013 at 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"
>>
>> "A list of FooEntrys"
>>
>> "A list of FooEntry's"
>>
>> "A list of FooEntr
On Wed, May 8, 2013 at 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"
>
> "A list of FooEntrys"
>
> "A list of FooEntry's"
>
> "A list of FooEntry instances"
>
> The first one certainly sounds the best, but it
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
--
http://mail.python.org/mailman/listinfo/p
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
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
On Tue, Jul 17, 2012 at 12:10 AM, alex23 wrote:
> On Jul 17, 1:29 am, Steven D'Aprano +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 "
On Tue, Jul 17, 2012 at 6:23 AM, Michele Simionato
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
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 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
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
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, Croepha wrote:
> >> Which is preferred:
> >>
> >> for value in list:
> >> if not value is another_value:
> >> value.do_something()
> >> break
>
> Do
On Thu, Mar 15, 2012 at 7:37 AM, Croepha 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 principle
> > 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 us
On 14 March 2012 22:15, Prasad, Ramit 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
--
http://mail.python.org/mailman/listinfo/python-list
> >> 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
On 3/14/2012 4:49 PM, Arnaud Delobelle wrote:
On 14 March 2012 20:37, Croepha 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 x is y' can be mis
On 14 March 2012 20:37, Croepha 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 :)
I suspe
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
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:
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 http://docs.python.org/library/function
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 = some.deeply.nested.obj
On 1/30/11 1:13 PM, rantingrick wrote:
> On Jan 30, 12:53 pm, Stephen Hansen 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 don't. I don
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 =
> some.deeply.ne
>
> 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 Jan 30, 12:53 pm, Stephen Hansen 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 as localv
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 = some.deeply.nested.object.method(some.other.deeply
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 loca
On Jan 30, 12:23 pm, Stephen Hansen 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 my(deeply.nested.thing) as o:
>
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 l
In article ,
Gerald Britton 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 =
> some.deeply.nested.object.method(some.other.deeply.nested.object.val
On Jan 30, 11:51 am, Gerald Britton 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, putting on my co
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 bu
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 +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 Dec 17, 12:23 am, Steven D'Aprano 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 the change there; if you have mu
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 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 some_condition:
On Fri, 17 Dec 2010 17:26:08 +, Grant Edwards wrote:
> Give me code that's easy-to-read and doesn't work rather code that works
> and can't be read any day.
Well, in that case, you'll love my new operating system, written in 100%
pure Python:
[start code]
print("this is an operating system"
On Fri, 17 Dec 2010 10:53:45 -0500, Steve Holden wrote about 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.
Yes, I f
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 started learning Python, I wrote a lot of methods tha
-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 by
On 2010-12-16, Steven D'Aprano 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!)
>>
On 2010-12-16, Stefan Sonnenberg-Carstens
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 ;-)
Even that last bit isn't th
> 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
Tim Golden 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 realise there
Steve Holden 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 DullError, 'nothi
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
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'),
Jean-Michel Pichavant 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 the we never
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 t
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 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" ar
On Thu, Dec 16, 2010 at 6:51 PM, Steven D'Aprano
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 entry, one
> exit" rule comes from th
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 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 indente
1 - 100 of 218 matches
Mail list logo
