Checking against NULL will be eliminated?
 

Hello Python-list,


I don't know how to call it, but the following Python 3.2 code seems to raise a
FutureWarning.

def func(root=None):
nonlocal arg
if root:
arg += 1
The warning is "FutureWarning: The behavior of this method will change
in future versions. Use specific 'len(elem)' or 'elem is not None' test instead."
Why is the reason for this idiom to be changed?



--
--
Claudiu Popa

Re: Checking against NULL will be eliminated?
 

On Mar 2, 5:51*am, Claudiu Popa <cp...@bitdefender.com> wrote:
> Hello Python-list,
>
> I *don't *know how to call it, but the following Python 3.2 code seems to raise a
> FutureWarning.
>
> def func(root=None):
> * * nonlocal arg
> * * if root:
> * * * *arg += 1
> The *warning is "FutureWarning: The behavior of this method will change
> in future versions. *Use specific 'len(elem)' or 'elem is not None' test instead."
> Why is the reason for this idiom to be changed?

I'm guessing root is an ElementTree Element?

The reason for this is that some element tree functions will return
None if an element is not found, but an empty element will have a
boolean value of false because it acts like a container. Some people
who use ElementTree don't always have this behavior in mind when they
are testing to see if an element was found, and will use "if element:"
when they need to be using "if element is not None:".

The larger reason is that boolean evaluation in Python tries to be too
many things: for some types is means "not zero", for some types it
means "empty", and for some types it means "this is a value of this
type as opposed to None". That causes conflicts when more than one of
those tests makes sense for a given type, as it does with Elements.

This change is only for ElementTree as far as I know. (Incidentally,
Numpy arrays are another notable type that's disabled implicit
booleans, but it did it a long time ago.)


Carl Banks

Re: Checking against NULL will be eliminated?
 

On Wed, 02 Mar 2011 06:37 -0800, "Carl Banks" <pavlovevidence@gmail.com>
wrote:
> The larger reason is that boolean evaluation in Python tries to be too
> many things: for some types is means "not zero", for some types it
> means "empty", and for some types it means "this is a value of this
> type as opposed to None". That causes conflicts when more than one of
> those tests makes sense for a given type, as it does with Elements.

You're right.

PEP 4000:
Proposing a new, backwards-incompatible version of Python in which
boolean evaluation
is not so overloaded.

Hmm, no, I don't think that will fly. We're stuck with it :(

Fortunately there are work-arounds for the cases that matter, as we've
seen.
Yay Python :)

--
Tom Zych / freethinker@pobox.com
Quidquid latine dictum sit, altum viditur.

Re: Checking against NULL will be eliminated?
 

Back at NCR, they stressed the axiom '90% of the time is spent fixing
10% of the code'.

How true that axiom is. Never more so then when faced with a programming
language fix like PEP 4000. Fortunately for me, I never trusted python's
complex, or should I say 'overloaded' Boolean usage.

If I want to know if a string or list dictionary is empty: if ( len(x)
== 0 ).

If an item is None: if ( type(x) == types.NoneType ):

if truly Boolean and want to 'do' something on False, then I use 'not'.

I really like 'types'. Helps error checking, helps making logic flows
cleaner and less error prone. And since 'pydev/Eclipse' is so good at
finding my from/imports and inserting them for me, I use types liberally.

I guess being an old C programmer makes one a bit more cautious; nothing
worse then compiler errors, accept runtime errors. And over course, I
still use lots of parentheses to group my logic. Hell, I still do a lot
of that when using bash.

So PEP 4000, go ahead, break some over indulgent code and coders; I'm
not bothered.

Steven


On 03/02/2011 07:15 AM, Tom Zych wrote:
> On Wed, 02 Mar 2011 06:37 -0800, "Carl Banks"<pavlovevidence@gmail.com>
> wrote:
>> The larger reason is that boolean evaluation in Python tries to be too
>> many things: for some types is means "not zero", for some types it
>> means "empty", and for some types it means "this is a value of this
>> type as opposed to None". That causes conflicts when more than one of
>> those tests makes sense for a given type, as it does with Elements.
> You're right.
>
> PEP 4000:
> Proposing a new, backwards-incompatible version of Python in which
> boolean evaluation
> is not so overloaded.
>
> Hmm, no, I don't think that will fly. We're stuck with it :(
>
> Fortunately there are work-arounds for the cases that matter, as we've
> seen.
> Yay Python :)
>

Re: Checking against NULL will be eliminated?
 

On Wed, 02 Mar 2011 08:20:56 -0800, Steven Howe wrote:

> Back at NCR, they stressed the axiom '90% of the time is spent fixing
> 10% of the code'.

It's not an axiom, it's a platitude. Nor is it based on any objective
evidence I've ever seen.


> How true that axiom is. Never more so then when faced with a programming
> language fix like PEP 4000.

Do you realise that "PEP 4000" was Tom Zych being sarcastic? There is no
PEP 4000:

http://www.python.org/dev/peps/


> Fortunately for me, I never trusted python's
> complex, or should I say 'overloaded' Boolean usage.

That's your loss. Just because you choose to not trust something which
works deterministically and reliably, doesn't mean the rest of us
shouldn't.


> If I want to know if a string or list dictionary is empty: if ( len(x)
> == 0 ).

Apart from the unnecessary length and the pointless reliance on an
implementation detail, can you please explain how the above differs from
`if not x:`?

For starters, how about giving an example of a built-in string, list or
dictionary where `if len(x) == 0` and `if x` give different results?



> If an item is None: if ( type(x) == types.NoneType ):

Good grief, now that truly is astoundingly unpythonic code!

`if x is None` is the right way to do it. It is also *guaranteed* to be
correct, rather than being subject to failure-modes like this:

>>> import types
>>> types.NoneType = int # monkey-patch the module
>>> x = 42
>>> if type(x) == types.NoneType:
.... print "And now your world comes crashing down in flames!"
....
And now your world comes crashing down in flames!


No rogue libraries or functions can override the `is` operator or the
None singleton. I think it is sad that you've been writing code which is
*less* safe, in the mistaken belief that it was more safe. Perhaps you
should stop writing C in Python, and learn to write Python.


> nothing
> worse then compiler errors, accept runtime errors.

"I find it amusing when novice programmers believe their main job is
preventing programs from crashing. ... More experienced programmers
realize that correct code is great, code that crashes could use
improvement, but incorrect code that doesn’t crash is a horrible
nightmare."
-- Chris Smith
http://cdsmith.wordpress.com/2011/01...ticle-i-wrote/




--
Steven

Re: Checking against NULL will be eliminated?
 

On Wed, 02 Mar 2011 23:46:31 +0000, Steven D'Aprano wrote:

> For starters, how about giving an example of a built-in string, list or
> dictionary where `if len(x) == 0` and `if x` give different results?

Er, how embarrassment... of course I mean either len(x) != 0, or not x,
take your pick.


--
Steven

Re: Checking against NULL will be eliminated?
 

Steven D'Aprano wrote:
> Do you realise that "PEP 4000" was Tom Zych being sarcastic? There is no
> PEP 4000:

Eh, well, maybe 10% sarcastic, 90% facetious. Wasn't trying to give
Carl a hard time.

--
Tom Zych / freethinker@pobox.com
Q: I'm having problems with my Windows software. Will you help me?
A: Yes. Go to a DOS prompt and type "format c:". Any problems you are
experiencing will cease within a few minutes. -- Hacker Howto

Re: Checking against NULL will be eliminated?
 

On Mar 2, 3:46*pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:

> > Fortunately for me, I never trusted python's
> > complex, or should I say 'overloaded' Boolean usage.
>
> That's your loss. Just because you choose to not trust something which
> works deterministically and reliably, doesn't mean the rest of us
> shouldn't.

Perl works deterministically and reliably. In fact, pretty much every
language works deterministically and reliably. Total non-argument.


Carl Banks

Re: Checking against NULL will be eliminated?
 

Steven Howe wrote:
>
> If an item is None: if ( type(x) == types.NoneType ):
>
Bye the way, the beauty of python is that "If an item is None"
translates into "If item is None".

JM

Re: Checking against NULL will be eliminated?
 

Carl Banks wrote:
> Perl works deterministically and reliably. In fact, pretty much every
> language works deterministically and reliably. Total non-argument.

Well, yes. I think the real issue is, how many surprises are
waiting to pounce on the unwary developer. C is deterministic
and reliable, but full of surprises. Python is generally low
in surprises. Using "if <identifier>" is one place where you
do have to think about unintended consequences.

--
Tom Zych / freethinker@pobox.com
Q: I'm having problems with my Windows software. Will you help me?
A: Yes. Go to a DOS prompt and type "format c:". Any problems you are
experiencing will cease within a few minutes. -- Hacker Howto