I've got this code in a django app:
CHOICES = [
('NONE', 'No experience required'),
('SAIL', 'Sailing experience, new to racing'),
('RACE', 'General racing experience'),
('GOOD', 'Experienced racer'),
('ROCK', 'Rock star'),
]
def
On Mon, May 21, 2012 at 10:37 PM, Roy Smith r...@panix.com wrote:
The above code works, but it occurs to me that I could use the much
shorter:
def experience_text(self):
return dict(CHOICES).get(self.level, ???)
So, the question is, purely as a matter of readability, which would
On Mon, 21 May 2012 08:37:29 -0400, Roy Smith wrote:
[...]
The above code works, but it occurs to me that I could use the much
shorter:
def experience_text(self):
return dict(CHOICES).get(self.level, ???)
So, the question is, purely as a matter of readability, which would you
One suggestion is to construct the dictionary first:
CHOICES = dict(
NONE = 'No experience required',
SAIL = 'Sailing experience, new to racing',
RACE = 'General racing experience',
GOOD = 'Experienced racer',
ROCK = 'Rock star'
)
def experience_text(self):
try:
On 05/21/12 08:10, Steven D'Aprano wrote:
On Mon, 21 May 2012 08:37:29 -0400, Roy Smith wrote:
[...]
The above code works, but it occurs to me that I could use the much
shorter:
def experience_text(self):
return dict(CHOICES).get(self.level, ???)
So, the question is, purely
On Monday, 21 May 2012 13:37:29 UTC+1, Roy Smith wrote:
I've got this code in a django app:
CHOICES = [
('NONE', 'No experience required'),
('SAIL', 'Sailing experience, new to racing'),
('RACE', 'General racing experience'),
('GOOD', 'Experienced
On Monday, May 21, 2012 9:39:59 AM UTC-4, Jon Clements wrote:
def experience_text(self):
return dict(CHOICES).get(self.level, ???)
Haven't used django in a while, but doesn't the model provide a
get_experience_display() method which you could use...
Duh, I totally missed
That test was designed to treat None as a boolean False, without
noticing that numeric 0 is also treated as False and could make the
test do the wrong thing. This is an extremely common type of error.
Actually, I felt that 0 not being considered False would be a better
option.
I had lot of
On Thu, Jul 16, 2009 at 11:13 PM, koranthalakoranth...@gmail.com wrote:
That test was designed to treat None as a boolean False, without
noticing that numeric 0 is also treated as False and could make the
test do the wrong thing. This is an extremely common type of error.
Actually, I felt
On Thu, 16 Jul 2009 23:13:51 -0700, koranthala wrote:
That test was designed to treat None as a boolean False, without
noticing that numeric 0 is also treated as False and could make the
test do the wrong thing. This is an extremely common type of error.
Actually, I felt that 0 not being
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
It is very useful to be able to write e.g.:
if header or body or footer:
print assemble_page(header, body, footer)
and have empty strings to be equivalent to False.
Why doesn't assemble_page properly handle the case where
koranthala koranth...@gmail.com (k) wrote:
That test was designed to treat None as a boolean False, without
noticing that numeric 0 is also treated as False and could make the
test do the wrong thing. This is an extremely common type of error.
k Actually, I felt that 0 not being considered
On Fri, 17 Jul 2009 00:34:00 -0700, Paul Rubin wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
It is very useful to be able to write e.g.:
if header or body or footer:
print assemble_page(header, body, footer)
and have empty strings to be equivalent to False.
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
def assemble_page(header, body, footer):
if header or body or footer:
do_lots_of_expensive_processing()
else:
do_nothing_gracefully()
Why should the processing be expensive if all three fields are empty?
On Fri, 17 Jul 2009 07:12:51 -0700, Paul Rubin wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
def assemble_page(header, body, footer):
if header or body or footer:
do_lots_of_expensive_processing()
else:
do_nothing_gracefully()
Why should the
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
Since I haven't specified an implementation for assemble_page, it could
be doing *anything*. Perhaps it has to talk to a remote database over a
slow link, perhaps it generates 300 lines of really inefficient HTML code
with no
Sometimes I see relatively small application, generally task scripts,
written as essentially a list of statements. Other times, I see them neatly
divided into functions and then the if __name__ == '__main__': convention.
Is there a preference? Is there an... application scope such that the
Sometimes I see relatively small application, generally task scripts,
written as essentially a list of statements. Other times, I see them neatly
divided into functions and then the if __name__ == '__main__': convention.
Is there a preference? Is there an... application scope such that the
On 2009-07-17 12:11, Tim Chase wrote:
Sometimes I see relatively small application, generally task scripts,
written as essentially a list of statements. Other times, I see them
neatly
divided into functions and then the if __name__ == '__main__':
convention.
Is there a preference? Is there an...
Robert Kern wrote:
[sage advice snipped]
Don't waste half a day trying to figure out why your script
mysteriously doesn't work. Learn from my mistakes. :-)
I find that's the best type of mistake to learn from: other
people's ;-)
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Wells Oliver wrote:
Sometimes I see relatively small application, generally task scripts,
written as essentially a list of statements. Other times, I see them neatly
divided into functions and then the if __name__ == '__main__': convention.
Is there a preference? Is there an... application
In article 7x8wj4uxnb@ruckus.brouhaha.com,
Paul Rubin http://phr...@nospam.invalid wrote:
Anyway, Python's overloading of bool(...) is yet another misfeature
and although it's convenient, the explicit is better than implicit
principle indicates to avoid that sort of trick.
Well, trading
In article 7x8wj2agma@ruckus.brouhaha.com,
Paul Rubin http://phr...@nospam.invalid wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
but I don't accept that somethingness
vs. nothingness is the same distinction as truth vs falsehood.
It's the distinction used by Python
Albert van der Horst wrote:
Einstein introduced the summation convention for indices that
are used twice. Leaving out summation signs is absolutely hideous,
but it has saved generations of physicists of loosing track (and
their minds.)
There is a joke among mathematicians that if Einstein
If I have to write an extension module with many objects, how can I
organizing the code?
I think: every object in a separate file, and a last file with the
PyInit_. function. But is unmenageable .
Solutions?
Thanks!
--
http://mail.python.org/mailman/listinfo/python-list
tuxagb:
If I have to write an extension module with many objects, how can I
organizing the code?
I think: every object in a separate file, and a last file with the
PyInit_. function. But is unmenageable .
Solutions?
What do you think about using Cython?
Bye,
bearophile
--
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
Yes, it saves a few keystrokes to say if x: instead of if
len(x)==0: or even if bool(x):,
It's not about saving keystrokes -- that's a furphy. It's about
encapsulation. Objects are in a better position to recognise when they
Paul Rubin wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
if len(x) == 0 is wasteful. Perhaps I've passed you a list-like
iterable instead of a list, and calculating the actual length is O(N).
That doesn't happen in any of Python's built-in container types. I
could
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
I wouldn't say Python's None is terrible,...
No, wait, I tell I lie... re.search() sometimes bites me, because
sometimes it returns None and sometimes it returns a matchobject and I
don't use re often enough to have good habits
On Sun, 05 Jul 2009 03:08:16 -0700, Paul Rubin wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
Yes, it saves a few keystrokes to say if x: instead of if
len(x)==0: or even if bool(x):,
It's not about saving keystrokes -- that's a furphy. It's about
encapsulation.
On Sun, 05 Jul 2009 11:37:49 +, Lie Ryan wrote:
Neither python's `if` nor `if` in formal logic is about testing True vs.
False. `if` in python and formal logic receives a statement. The
statement must be evaluatable to True or False, but does not have to be
True or False themselves. It
On Sun, 05 Jul 2009 06:12:25 -0700, Paul Rubin wrote:
There are three natural approaches to (say) re.search() for dealing
with failure:
(1) return a sentinel value like None; (2) return a matchobject which
tests False; (3) raise an exception.
4. Have re.search return a bool and possible
Steven D'Aprano wrote:
On Sun, 05 Jul 2009 11:37:49 +, Lie Ryan wrote:
Neither python's `if` nor `if` in formal logic is about testing True vs.
False. `if` in python and formal logic receives a statement. The
statement must be evaluatable to True or False, but does not have to be
True
Paul Rubin wrote:
I don't know what a furphy is, but I don't accept that somethingness
vs. nothingness is the same distinction as truth vs falsehood. True
and False are values in a specific datatype (namely bool), not
abstract qualities of arbitrary data structures. The idea that the
if
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
but I don't accept that somethingness
vs. nothingness is the same distinction as truth vs falsehood.
It's the distinction used by Python since the dawn of time. Python only
grew a bool type a few versions back.
That's true,
Simon Forman sajmik...@gmail.com writes:
BTW, Paul, kind of a tangent: I reimplemented the same algorithm but
using tuples instead of instances (and empty tuples for NULL
values.) I was trying to mess around in the space you seemed to
indicate existed, i.e. a better implementation using other
On Jul 2, 1:23 pm, Simon Forman sajmik...@gmail.com wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first one is easier [for me anyway] to read and understand, but
upwestdon wrote:
if not (self.higher and self.lower):
return self.higher or self.lower
self.lower = 0
self.higher = 123
???
More than just None is False
--
http://mail.python.org/mailman/listinfo/python-list
a...@pythoncraft.com (Aahz) writes:
AFAICT, in order for Maybe and Option to work, you need to have some
kind of static typing system. Am I missing something?
I'm not sure. Maybe there could be some kind of syntactic support in
a dynamic language (not that I'm suggesting adding that to
upwestdon wrote:
On Jul 2, 1:23 pm, Simon Forman sajmik...@gmail.com wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first one is easier [for me anyway] to read and
On Jul 4, 2:03 am, upwestdon upwest...@gmail.com wrote:
On Jul 2, 1:23 pm, Simon Forman sajmik...@gmail.com wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first
In article 7xws6oa862@ruckus.brouhaha.com,
Paul Rubin http://phr...@nospam.invalid wrote:
In many cases it later turns out that list really was the natural
representation and it ends up growing additional potential elements.
I saw some article about database design recently that claimed as a
Simon Forman sajmik...@gmail.com writes:
if not (self.higher and self.lower):
return self.higher or self.lower
That would work too in this case, both higher and lower are expected
to be either None or an object (that doesn't override the default all-
objects-are-true rule.)
-1.
On Jul 4, 2:10 pm, Paul Rubin http://phr...@nospam.invalid wrote:
Simon Forman sajmik...@gmail.com writes:
if not (self.higher and self.lower):
return self.higher or self.lower
That would work too in this case, both higher and lower are expected
to be either None or an object (that
On Sat, 04 Jul 2009 11:10:48 -0700, Paul Rubin wrote:
Anyway, Python's overloading of bool(...) is yet another misfeature and
although it's convenient, the explicit is better than implicit
principle indicates to avoid that sort of trick.
Overloading of bool()?
I don't understand what that
Tim Harig wrote:
Speaking only to the style issue, when I've wanted to do something like
that, I find:
if self.higher is None is self.lower:
more readable, by making clear they are both being compared to a
constant, rather than compared to each other.
By comparing them to *any*
Simon Forman wrote:
On Jul 2, 3:57 pm, Scott David Daniels scott.dani...@acm.org wrote:
Duncan Booth wrote:
Simon Forman sajmik...@gmail.com wrote:
...
if self.higher is self.lower is None: return
...
As a matter of style however I wouldn't use the shorthand to run two 'is'
comparisons
Paul Rubin wrote:
Generally, having a special
value like None to denote a missing datum was considered standard
practice a few decades ago,
I guess in python, None as the missing datum idiom is still quite prevalent:
def cat_list(a=None, b=None):
# poor man's list concatenation
if a
Lie Ryan wrote:
Tim Harig wrote:
Speaking only to the style issue, when I've wanted to do something like
that, I find:
if self.higher is None is self.lower:
more readable, by making clear they are both being compared to a
constant, rather than compared to each other.
By comparing
Paul Rubin wrote:
Tim Harig user...@ilthio.net writes:
That being the case, it might be a good idea either to handle the situation
and raise an exception or add:
assert self.lower = self.higher
That way an exception will be raised if there is an error somewhere else
in the code rather then
Simon Forman wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
If self is an object (and it must have been), it would be preferrable to
set self.higher and self.lower to a known
Lie Ryan lie.1...@gmail.com writes:
I guess in python, None as the missing datum idiom is still quite prevalent:
Well, sometimes there is no way around it, but:
def cat_list(a=None, b=None):
# poor man's list concatenation
if a is None and b is None: return []
if a is None:
On Thu, 02 Jul 2009 22:14:18 +, Tim Harig wrote:
On 2009-07-02, Paul Rubin http wrote:
Tim Harig user...@ilthio.net writes:
If lower is 5 and higher is 3, then it returns 3 because 3 != None in
the first if.
Sorry, the presumption was that lower = higher, i.e. the comparison
had already
On 2009-07-03, Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
On Thu, 02 Jul 2009 22:14:18 +, Tim Harig wrote:
On 2009-07-02, Paul Rubin http wrote:
Tim Harig user...@ilthio.net writes:
If lower is 5 and higher is 3, then it returns 3 because 3 != None in
the first if.
Simon Forman wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first one is easier [for me anyway] to read and understand, but
Easier for you but not for those who are
On Jul 3, 2:09 am, Lie Ryan lie.1...@gmail.com wrote:
Simon Forman wrote:
On Jul 2, 3:57 pm, Scott David Daniels scott.dani...@acm.org wrote:
Duncan Booth wrote:
Simon Forman sajmik...@gmail.com wrote:
...
if self.higher is self.lower is None: return
...
As a matter of style however
On Jul 3, 12:56 am, Paul Rubin http://phr...@nospam.invalid wrote:
Simon Forman sajmik...@gmail.com writes:
Yes, but the concept of null pointers is considered kludgy these days.
Seriously? kludgy? (I really AM getting old.)
Simon Forman sajmik...@gmail.com writes:
...stick to the principle: NULL is wrong because it causes horrible
and tricky mistakes which appear even after the program was tested
thoroughly. You cannot introduce NULL into the language and tell the
programmer to be careful about it. The programmer
On Jul 3, 4:50 pm, Paul Rubin http://phr...@nospam.invalid wrote:
I wouldn't say Python's None is terrible, but the
programming style in which None is used as a marker
for absent value is genuinely a source of bugs,
requiring care when used. Often it's easy to just
avoid it and all the bugs
On Fri, 03 Jul 2009 13:50:12 -0700, Paul Rubin wrote:
I wouldn't say Python's None is terrible, but the programming style in
which None is used as a marker for absent value is genuinely a source
of bugs, requiring care when used. Often it's easy to just avoid it and
all the bugs that come
In article 7xhbxtjxtn@ruckus.brouhaha.com,
Paul Rubin http://phr...@nospam.invalid wrote:
Simon Forman sajmik...@gmail.com writes:
(I like Haskell's Maybe, but saying A is better than B doesn't imply
that B is therefore terrible.)
I wouldn't say Python's None is terrible, but the
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first one is easier [for me anyway] to read and understand, but
slightly less efficient, while the second is [marginally] harder to
Simon Forman sajmik...@gmail.com wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first one is easier [for me anyway] to read and understand, but
slightly less efficient,
On Jul 2, 1:44 pm, Duncan Booth duncan.bo...@invalid.invalid wrote:
Simon Forman sajmik...@gmail.com wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first one is
the fact that you felt compelled to explain the one minor point in
the first snippet tells me that the second snippet does not need that
explanation and will be easier for someone (like you for example) to
maintain in the future.
Second snippet would be my choice.
Kee Nethery
On Jul 2,
Simon Forman wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first one is easier [for me anyway] to read and understand, but
slightly less efficient, while the second is
Simon Forman sajmik...@gmail.com writes:
These two snippets of code are functionally identical. Which would you
use and why?
Both are terrible. I can't tell what you're really trying to do. As
Terry Reedy points out, the case where self.higher and self.lower are
both not None is not handled.
On 2009-07-02, Duncan Booth duncan.bo...@invalid.invalid wrote:
so apart from reversing the order of the comparisons once you've dropped
the redundant test it is the same as the first one.
I try to evaluate what you have given regardless of what Booth pointed out.
So, I will only evaluate the
Duncan Booth wrote:
Simon Forman sajmik...@gmail.com wrote:
...
if self.higher is self.lower is None: return
...
As a matter of style however I wouldn't use the shorthand to run two 'is'
comparisons together, I'd write that out in full if it was actually needed
here.
Speaking only to the
Simon Forman sajmik...@gmail.com writes:
## Second snippet
if self.higher is None:
if self.lower is None:
return
return self.lower
if self.lower is None:
return self.higher
What do you think?
I'm not sure, but my guess is that what you are really trying to write
is
Tim Harig user...@ilthio.net writes:
If lower is 5 and higher is 3, then it returns 3 because 3 != None in the
first if.
Sorry, the presumption was that lower = higher, i.e. the comparison
had already been made and the invariant was enforced by the class
constructor. The comment should have
On 2009-07-02, Paul Rubin http wrote:
Tim Harig user...@ilthio.net writes:
If lower is 5 and higher is 3, then it returns 3 because 3 != None in the
first if.
Sorry, the presumption was that lower = higher, i.e. the comparison
had already been made and the invariant was enforced by the class
Tim Harig user...@ilthio.net writes:
That being the case, it might be a good idea either to handle the situation
and raise an exception or add:
assert self.lower = self.higher
That way an exception will be raised if there is an error somewhere else
in the code rather then silently passing
On 2009-07-02, Paul Rubin http wrote:
Tim Harig user...@ilthio.net writes:
That being the case, it might be a good idea either to handle the situation
and raise an exception or add:
assert self.lower = self.higher
That way an exception will be raised if there is an error somewhere else
in
On 2009-07-02, Tim Harig user...@ilthio.net wrote:
Sorry, it worked under 2.5:
[SNIP]
None seems to have been evaluated less then any integer. The same isn't
true under 3.0:
None seem to have been evaluated less then any non-negative integer
including 0.
--
On Jul 2, 4:08 pm, Erik Max Francis m...@alcyone.com wrote:
Simon Forman wrote:
Hey I was hoping to get your opinions on a sort of minor stylistic
point.
These two snippets of code are functionally identical. Which would you
use and why?
The first one is easier [for me anyway] to read
On Jul 2, 3:57 pm, Scott David Daniels scott.dani...@acm.org wrote:
Duncan Booth wrote:
Simon Forman sajmik...@gmail.com wrote:
...
if self.higher is self.lower is None: return
...
As a matter of style however I wouldn't use the shorthand to run two 'is'
comparisons together, I'd
Tim Harig user...@ilthio.net writes:
Well, that assert is not right because you have to handle the case
where one of the values is None...
Sorry, it worked under 2.5:
Well, it didn't crash under 2.5. Whether the result was correct
is a different question.
None seems to have been
Simon Forman sajmik...@gmail.com writes:
This code is part of a delete() method for a binary tree
implementation. None is used to simulate a NULL pointer. In the case
where both children are non-None the code goes on to handle that.
None is a unitary or singleton value, so is is the right
On Jul 2, 9:30 pm, Paul Rubin http://phr...@nospam.invalid wrote:
Simon Forman sajmik...@gmail.com writes:
This code is part of a delete() method for a binary tree
implementation. None is used to simulate a NULL pointer. In the case
where both children are non-None the code goes on to
Simon Forman sajmik...@gmail.com writes:
Yes, but the concept of null pointers is considered kludgy these days.
Seriously? kludgy? (I really AM getting old.)
http://math.andrej.com/2009/04/11/on-programming-language-design/
discusses the issue (scroll down to Undefined values section).
81 matches
Mail list logo
