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
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 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
-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
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
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 that looked
like
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
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)
(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):
if some_good_condition
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
On 2010-12-16, John Gordon gor...@panix.com wrote:
I like this style more, mostly because it eliminates a lot of indentation.
However I recall one of my college CS courses stating that one entry,
one exit was a good way to write code, and this style has lots of exits.
So, take the good
On 2010-12-16, John Gordon gor...@panix.com 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
Am 16.12.2010 22:49, schrieb John Gordon:
(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
On Thu, 2010-12-16 at 21:49 +, 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
On Thu, Dec 16, 2010 at 3:41 PM, Stefan Sonnenberg-Carstens
stefan.sonnenb...@pythonmeister.com wrote:
return [x for x,y in
((bad1,some_bad_condition),(bad2,some_other_bad_condition),(bad3,yet_another_bad_condition),(good1,do_some_useful_stuff()
or True)) if x][0]
This doesn't work.
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 that looked
like
John Gordon gor...@panix.com wrote:
But lately I've been preferring this style:
def myMethod(self, arg1, arg2):
if some_bad_condition:
return bad1
elif some_other_bad_condition:
return bad2
elif yet_another_bad_condition:
return bad3
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message
news:4d0aa5e7$0$29997$c3e8da3$54964...@news.astraweb.com...
It doesn't look like you were learning Python. It looks like you were
learning C with Python syntax :(
True, although in many cases one has to interface to legacy C
On Dec 16, 2:56 pm, Ryan Kelly r...@rfk.id.au wrote:
On Thu, 2010-12-16 at 21:49 +, 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
On 12/16/2010 11:32 PM, Carl Banks wrote:
On Dec 16, 2:56 pm, Ryan Kelly r...@rfk.id.au wrote:
On Thu, 2010-12-16 at 21:49 +, 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
K-Dawg wrote:
I am trying to become more pythonic as I learn python and get my mind
around it instead of other languages I have used.
I have an app that has a series of classes for objects it uses. From a
style perspective, which should be done:
Different py file for each class
or
Steve Holden wrote:
K-Dawg wrote:
I am trying to become more pythonic as I learn python and get my mind
around it instead of other languages I have used.
I have an app that has a series of classes for objects it uses. From a
style perspective, which should be done:
Different py file for each
On Jan 9, 11:51 pm, Fredrik Lundh [EMAIL PROTECTED] wrote:
Steve Brown wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated
-On [20080110 06:51], Steve Brown ([EMAIL PROTECTED]) wrote:
I don't like the duplicated information: But the comment is attractive,
I find it unattractive to be honest.
and the docstring self.__doc__ is already in use in the test log. I've read
that all modules and classes should have
On Behalf Of Steve Brown
What do you think?
I think that comments are for maintainers, and docstrings are for users.
Some of the things I use comments for:
* Visually separate classes (using a syntax-highlighting editor)
* Explain algorithm choices
* Explain bug fixes so I don't later fix
Russ P. wrote:
On Jan 9, 9:47 pm, Steve Brown [EMAIL PROTECTED] wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated information: But the
Russ P. [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Jan 9, 11:51 pm, Fredrik Lundh [EMAIL PROTECTED] wrote:
Steve Brown wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class
On Jan 10, 2008 12:47 AM, Steve Brown [EMAIL PROTECTED] wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated information: But the comment
Neil Cerutti [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Jan 10, 2008 12:47 AM, Steve Brown [EMAIL PROTECTED] wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
What I'm trying to do with the tests is pare them back so that
the code explicitly and concisely documents the tests.
It is important that the comments and doc strings NOT contain
information about how Temperature Sense works because that
is outside the scope of the test.
More generally,
On Fri, 11 Jan 2008 13:09:26 +1100, Steve Brown wrote:
What I'm trying to do with the tests is pare them back so that the code
explicitly and concisely documents the tests.
Yes, this is good.
It is important that the comments and doc strings NOT contain
information about how Temperature
Steve Brown wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated information: But the comment is attractive, and
the docstring
On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
Jorgen Grahn wrote:
...
(I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
system for C++ code, where identifiers and strings are in Times italic,
operators in Courier, and so on.)
the idea
In article [EMAIL PROTECTED],
Jorgen Grahn [EMAIL PROTECTED] writes:
|
| Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the
| time; these people all programmed using fixed-width fonts, on teletypes or
| character-mapped terminals. Hell, even full-screen editors were new and
I just have a basic style question here. Suppose you have the program:
def foo1():
do something
def foo2()
do something else
Assume that you want to call these functions at execution. Is it more
proper to call them directly like:
foo1()
foo2()
or in an if __name__ == __main__
that the script runs its main functions when called as a standalone
program, but you can also import the code and do something with it
without setting off those functions.
THN
Brian wrote:
I just have a basic style question here. Suppose you have the program:
def foo1():
do something
def foo2
Brian wrote:
I just have a basic style question here. Suppose you have the program:
def foo1():
do something
def foo2()
do something else
Assume that you want to call these functions at execution. Is it more
proper to call them directly like:
foo1()
foo2
72 matches
Mail list logo
