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
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 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
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, 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
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 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
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
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 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
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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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
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 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
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 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 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
Is there any software to help understand python code ?
Thanks
hamilton
--
http://mail.python.org/mailman/listinfo/python-list
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
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 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 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 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 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 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, 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, 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 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: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 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 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 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 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, 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 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 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 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 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
52 matches
Mail list logo
