On 16/07/2012 04:05, Chris Angelico wrote:
On Mon, Jul 16, 2012 at 12:58 PM, Steven D'Aprano
wrote:
And that, the reason given in the sentence above, is the reason that we,
collectively all programmers, should prefer to be explicit, not merely
conveying meaning by implication about everything w
On Mon, Jul 16, 2012 at 3:03 PM, Ranting Rick
wrote:
> But if you are going to argue that "if obj" is *explicit enough*, then
> apply your argument consistently to "String"+1.75 also. Why must we be
> explicit about string conversion BUT not boolean conversion? Can you
> reduce this to the absurd?
On Mon, Jul 16, 2012 at 2:53 PM, Ranting Rick
wrote:
> "if obj" is in essence doing "if bool(obj)" behind the scenes. My
> question is: Why hide such valuable information from the reader? It's
> obvious that "if bool(obj)" will return a boolean; whereas "if obj" is
> ambiguous.
Proves nothing. At
On Jul 15, 11:20 pm, Steven D'Aprano wrote:
> (It's not like explicit and implicit are distinct -- everything depends
> on something implicit, if only the meaning of the words you use to
> describe it.)
>
> It certainly doesn't mean that the semantics of Python the language must
> be written out
On Jul 15, 11:03 pm, Steven D'Aprano wrote:
> On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
> It boggles my mind that people who are perfectly happy to program to an
> interface or protocol when it comes to (say) iterables, numbers or even
> big complex classes with dozens of method
On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
> For example, instead of "if stack:" or "if bool(stack):", we could use
> "if stack.isempty():". This line tells us explicitly that stack is a
> container.
isempty is not a container method.
py> container = []
py> container.isempty()
On Jul 15, 9:58 pm, Steven D'Aprano wrote:
> On Sun, 15 Jul 2012 18:21:06 -0700, Ranting Rick wrote:
> > If HOWEVER we want to "truth test" an object (as in: "if obj") we should
> > be FORCED to use the bool! Why? Because explicit is better than implicit
>
> And this is why Rick always writes code
On Mon, Jul 16, 2012 at 12:58 PM, Steven D'Aprano
wrote:
> And that, the reason given in the sentence above, is the reason that we,
> collectively all programmers, should prefer to be explicit, not merely
> conveying meaning by implication about everything we, collectively all
> programmers, write
On Sun, 15 Jul 2012 18:21:06 -0700, Ranting Rick wrote:
> If HOWEVER we want to "truth test" an object (as in: "if obj") we should
> be FORCED to use the bool! Why? Because explicit is better than implicit
And this is why Rick always writes code like:
integer_value_three = int(1) + int(2)
assert
On Jul 15, 9:15 pm, Devin Jeanpierre wrote:
> For example, instead of "if stack:" or "if bool(stack):", we could use
> "if stack.isempty():". This line tells us explicitly that stack is a
> container. Or instead of "if dist:" or "if bool(dist):" we could use
> "if dist == 0:". This tells us expli
On Mon, Jul 16, 2012 at 12:41 PM, Ranting Rick
wrote:
> On Jul 15, 9:13 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>
>> I have just written a bunch of code with about two dozen examples similar
>> to this:
>>
>> for item in (seq or []):
>> do_something_with(item)
>
> Short ci
On Jul 15, 9:13 pm, Steven D'Aprano wrote:
> I have just written a bunch of code with about two dozen examples similar
> to this:
>
> for item in (seq or []):
> do_something_with(item)
>
> iterates over seq if it is non-empty, or the empty list. Writing it like
> this would be more painful, m
On Sun, 15 Jul 2012 12:02:37 -0500, Andrew Berg wrote:
> On 7/15/2012 5:56 AM, Steven D'Aprano wrote:
>> 3) Rather than distinguishing "true" from "false", a more useful
>> dichotomy is between "something" and "nothing". Python includes a
>> number of ways of spelling "nothing" of various types, s
On Jul 15, 8:51 pm, Chris Angelico wrote:
> On Mon, Jul 16, 2012 at 11:21 AM, Ranting Rick
>
> wrote:
> > If HOWEVER we want to "truth test" an object (as in: "if obj") we
> > should be FORCED to use the bool! Why? Because explicit is better than
> > implicit and readability counts if we want to
On Sun, Jul 15, 2012 at 9:51 PM, Chris Angelico wrote:
>> if bool(obj) and a==b: # Correct!
>> if obj and a==b: # Incorrect!
>
> That still doesn't answer the question of what bool(obj) should do if
> obj is not a bool, and why if can't do the exact same thing, since if,
> by definition, is
On Sun, 15 Jul 2012 10:19:16 -0600, Ian Kelly wrote:
> On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
> wrote:
>> (For the record, I can only think of one trap for the unwary: time
>> objects are false at *exactly* midnight.)
>
> Ugh, that's irritating. I can't think of any scenario where I w
On Sun, Jul 15, 2012 at 6:57 PM, hamilton wrote:
> On 7/15/2012 7:38 PM, Chris Rebert wrote:
>>
>> On Sun, Jul 15, 2012 at 6:26 PM, hamilton wrote:
>>>
>>> Subject: Diagramming code
>>>
>>> Is there any software to help understand python code ?
>>
>> What sort of diagrams? Control flow diagrams?
On 7/15/2012 7:38 PM, Chris Rebert wrote:
On Sun, Jul 15, 2012 at 6:26 PM, hamilton wrote:
Subject: Diagramming code
Is there any software to help understand python code ?
What sort of diagrams? Control flow diagrams? Class diagrams? Sequence
diagrams? Module dependency diagrams? There are m
On Mon, Jul 16, 2012 at 11:21 AM, Ranting Rick
wrote:
> If HOWEVER we want to "truth test" an object (as in: "if obj") we
> should be FORCED to use the bool! Why? Because explicit is better than
> implicit and readability counts if we want to create maintainable code
> bases!
>
> if bool(obj) and
On Sun, Jul 15, 2012 at 6:26 PM, hamilton wrote:
> Subject: Diagramming code
>
> Is there any software to help understand python code ?
What sort of diagrams? Control flow diagrams? Class diagrams? Sequence
diagrams? Module dependency diagrams? There are many different types
you could be referrin
Is there any software to help understand python code ?
Thanks
hamilton
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 15, 4:53 pm, Chris Angelico wrote:
> Then the construct "if bool(some_condition):" is redundant.
Wrong again, pay attention Chris!
It's ONLY redundant IF "some_condition" is a rich comparison: like
"(a==b)" OR a boolean function: like "callable(a)".
If HOWEVER we want to "truth test" an
On Mon, Jul 16, 2012 at 4:56 AM, Rick Johnson
wrote:
> On Sunday, July 15, 2012 1:01:58 PM UTC-5, Ian wrote:
>
>> So now instead of having to understand how "if" handles arbitrary
>> values, we have to understand how "bool" handles arbitrary values.
>> How is that an improvement?
>
> Because we ar
On 7/15/2012 1:02 PM, Andrew Berg wrote:
On 7/15/2012 5:56 AM, Steven D'Aprano wrote:
3) Rather than distinguishing "true" from "false", a more useful
dichotomy is between "something" and "nothing". Python includes a number
of ways of spelling "nothing" of various types, such as:
None, 0,
On 7/15/2012 12:19 PM, Ian Kelly wrote:
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
wrote:
(For the record, I can only think of one trap for the unwary: time
objects are false at *exactly* midnight.)
Ugh, that's irritating. I can't think of any scenario where I would
ever want the seman
Thanks for the suggestions, Ian! I implemented most of them and pushed the
code.
> That's because the Pythonic way is to either create a new object and
> return it, or mutate the existing object and return None.
You're saying what I was already thinking.
> In Python 2.7+, intersection and diff
On 15/07/12 10:44:09, Chris Angelico wrote:
> On Sun, Jul 15, 2012 at 6:32 PM, Steven D'Aprano
> wrote:
>> At compile time, Python parses the source code and turns it into byte-
>> code. Class and function definitions are executed at run time, the same
>> as any other statement.
>
> Between the p
In article ,
pyt...@bdurham.com wrote:
> Hi Roy,
>
> > I've been using unittest for many years, but have steadfastly
> (perhaps stubbornly) avoided newfangled improvements like nose.
> I finally decided to take a serious look at nose.
>
> Thanks for sharing your nose experience.
>
> What mo
On Sunday, July 15, 2012 1:01:58 PM UTC-5, Ian wrote:
> So now instead of having to understand how "if" handles arbitrary
> values, we have to understand how "bool" handles arbitrary values.
> How is that an improvement?
Because we are keeping the condition consistent. We are not relying on impli
Hi Roy,
> I've been using unittest for many years, but have steadfastly
(perhaps stubbornly) avoided newfangled improvements like nose.
I finally decided to take a serious look at nose.
Thanks for sharing your nose experience.
What motivated you to migrate from unittest to nose?
After years
On Sun, Jul 15, 2012 at 10:50 AM, Rick Johnson
wrote:
> I think this issue is not so much a "bool test" vs "type test", but more an
> ambiguous syntax issue. Consider this:
>
> ## EXAMPLE A ##
> py> if money:
> ... do_something()
>
> The syntax "if money" implies we are testing/measuring some
On Sun, Jul 15, 2012 at 11:16 AM, Andrew Berg wrote:
> On 7/15/2012 11:19 AM, Ian Kelly wrote:
>> Ugh, that's irritating. I can't think of any scenario where I would
>> ever want the semantics "if timeval (is not midnight):".
> It's not implemented with such a test, but
> logging.handlers.TimedRo
On Sat, Jul 14, 2012 at 5:56 PM, Leif wrote:
> Hi, everybody. I am trying to collect all the functions I've found useful for
> working with dicts into a library:
>
> https://github.com/leifp/dictutil
>
> If you have a favorite dict-related func / class, or know of similar
> projects, please let
On 7/15/2012 11:19 AM, Ian Kelly wrote:
> Ugh, that's irritating. I can't think of any scenario where I would
> ever want the semantics "if timeval (is not midnight):".
It's not implemented with such a test, but
logging.handlers.TimedRotatingFileHandler has an option to rollover at
midnight.
--
C
On 7/15/2012 5:56 AM, Steven D'Aprano wrote:
> 3) Rather than distinguishing "true" from "false", a more useful
> dichotomy is between "something" and "nothing". Python includes a number
> of ways of spelling "nothing" of various types, such as:
>
> None, 0, 0.0, '', [], {}, set()
>
> and n
On Sunday, July 15, 2012 11:19:16 AM UTC-5, Ian wrote:
> On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
> wrote:
> > (For the record, I can only think of one trap for the unwary: time
> > objects are false at *exactly* midnight.)
>
> Ugh, that's irritating. I can't think of any scenario where
On Mon, Jul 16, 2012 at 2:19 AM, Rick Johnson
wrote:
> On Sunday, July 15, 2012 10:57:00 AM UTC-5, Chris Angelico wrote:
>> On Mon, Jul 16, 2012 at 1:35 AM, wrote:
>> > Besides, you can skip most of those steps by Shift+RightClicking
>> > the file icon and choosing "Open Command Window Here".
>>
On Jul 15, 11:35 am, Dieter Maurer wrote:
> moo...@yahoo.co.uk writes:
> > ...
> > Does pickle have any advantages over json/yaml?
>
> It can store and retrieve almost any Python object with almost no effort.
>
> Up to you whether you see it as an advantage to be able to store
> objects rather tha
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
wrote:
> (For the record, I can only think of one trap for the unwary: time
> objects are false at *exactly* midnight.)
Ugh, that's irritating. I can't think of any scenario where I would
ever want the semantics "if timeval (is not midnight):". T
On Sunday, July 15, 2012 10:57:00 AM UTC-5, Chris Angelico wrote:
> On Mon, Jul 16, 2012 at 1:35 AM, wrote:
> > Besides, you can skip most of those steps by Shift+RightClicking
> > the file icon and choosing "Open Command Window Here".
>
> That's not standard. Me, I can invoke git bash anywhere I
On Mon, Jul 16, 2012 at 1:35 AM, wrote:
> Besides, you can skip most of those steps by Shift+RightClicking the file
> icon and choosing "Open Command Window Here".
That's not standard. Me, I can invoke git bash anywhere I want it, but
that doesn't mean I'd recommend installing git just so that
On Friday, February 20, 2009 9:41:42 AM UTC-6, David Smith wrote:
> What I meant was open open the command prompt, type cd, space, DO NOT
> hit enter yet. Drag the folder with your script into the command prompt
> window. Then go to the command prompt window and hit enter. This
> should compose
On Friday, July 6, 2012 8:39:58 AM UTC+10, Andrew Cooper wrote:
> On 05/07/2012 22:46, Evan Driscoll wrote:
> > On 01/-10/-28163 01:59 PM, Alexander Blinne wrote:
> >> 5+0 is actually 4+0, because 5 == 4, so 5+0 gives 4.
> >> 5+1 is actually 4+1, which is 5, but 5 is again 4.
> >> 5+2 is 4+2 which
Dieter Maurer wrote:
> moo...@yahoo.co.uk writes:
>> ...
>> Does pickle have any advantages over json/yaml?
>
> It can store and retrieve almost any Python object with almost no effort.
>
> Up to you whether you see it as an advantage to be able to store
> objects rather than (almost) pure data
On Sun, 15 Jul 2012 03:34:46 -0500, Andrew Berg wrote:
> This has probably been discussed before,
By the hoary hosts of Hoggoth, has it ever!
> but why is there an implicit
> conversion to a boolean in if and while statements?
It's nothing to do with if and while. All Python objects are duck-t
On 7/15/2012 4:32 AM, Steven D'Aprano wrote:
On Sun, 15 Jul 2012 10:49:48 +1000, Chris Angelico wrote:
On Sun, Jul 15, 2012 at 9:29 AM, Steven D'Aprano
wrote:
Not necessarily *compile* time, but the distinction is between when the
function is defined (which may at compile time, or it may be a
Andrew Berg, 15.07.2012 10:34:
> This has probably been discussed before, but why is there an implicit
> conversion to a boolean in if and while statements?
There isn't. This has nothing to do with "if" or "while".
All objects have a truth value in Python, evaluating to True by default
(object),
On Sun, Jul 15, 2012 at 6:34 PM, Andrew Berg wrote:
> Converting 0 and 1 to False and True seems reasonable, but I don't see
> the point in converting other arbitrary values.
It's for convenience. Unfortunately, not all languages treat all types
the same way. It's very handy, though, to be able t
On Sun, Jul 15, 2012 at 6:32 PM, Steven D'Aprano
wrote:
> At compile time, Python parses the source code and turns it into byte-
> code. Class and function definitions are executed at run time, the same
> as any other statement.
Between the parse step and the 'def' execution, a code object is
cre
On Sun, 15 Jul 2012 10:49:48 +1000, Chris Angelico wrote:
> On Sun, Jul 15, 2012 at 9:29 AM, Steven D'Aprano
> wrote:
>> Not necessarily *compile* time, but the distinction is between when the
>> function is defined (which may at compile time, or it may be at run
>> time) versus when the function
This has probably been discussed before, but why is there an implicit
conversion to a boolean in if and while statements?
if not None:
print('hi')
prints 'hi' since bool(None) is False.
If this was discussed in a PEP, I would like a link to it. There are so
many PEPs, and I wouldn't know
On 15/07/12 07:31, Michael Torrie wrote:
> On 07/14/2012 11:13 AM, rusi wrote:
>> I looked at the second link and find code like this:
>>
>> app = None if ( not app ): app = QtGui.QApplication([])
>>
>> Maybe I'm dense but whats that if doing there?
>>
>> Frankly I seem to be a bit jinxed with gui
52 matches
Mail list logo
