Re: Use cases for del

Discussion in 'Python' started by Jp Calderone, Jul 6, 2005.

  1. Jp Calderone

    Jp Calderone Guest

    On Wed, 06 Jul 2005 09:45:56 -0400, Peter Hansen <> wrote:
    >Tom Anderson wrote:
    >> How about just getting rid of del? Removal from collections could be
    >> done with a method call, and i'm not convinced that deleting variables
    >> is something we really need to be able to do (most other languages
    >> manage without it).

    >
    >Arguing the case for del: how would I, in doing automated testing,
    >ensure that I've returned everything to a "clean" starting point in all
    >cases if I can't delete variables? Sometimes a global is the simplest
    >way to do something... how do I delete a global if not with "del"?
    >


    Unless you are actually relying on the global name not being defined, "someGlobal = None" would seem to do just fine.

    Relying on the global name not being defined seems like an edge case.

    Jp
    Jp Calderone, Jul 6, 2005
    #1
    1. Advertising

  2. On Wed, 06 Jul 2005 10:00:02 -0400, Jp Calderone wrote:

    > On Wed, 06 Jul 2005 09:45:56 -0400, Peter Hansen <> wrote:
    >>Tom Anderson wrote:
    >>> How about just getting rid of del? Removal from collections could be
    >>> done with a method call, and i'm not convinced that deleting variables
    >>> is something we really need to be able to do (most other languages
    >>> manage without it).

    >>
    >>Arguing the case for del: how would I, in doing automated testing,
    >>ensure that I've returned everything to a "clean" starting point in all
    >>cases if I can't delete variables? Sometimes a global is the simplest
    >>way to do something... how do I delete a global if not with "del"?
    >>

    >
    > Unless you are actually relying on the global name not being defined, "someGlobal = None" would seem to do just fine.
    >
    > Relying on the global name not being defined seems like an edge case.


    Er, there is a lot of difference between a name not existing and it being
    set to None.

    $ cat mymodule1.py

    # define some temporary names
    a, b, c, d, e, f = 1, 2, 3, 4, 5, 6
    # do some work
    result = a+b+c+d*e**f
    # delete the temp variables
    del a
    del b
    del c
    del d
    del e
    del f

    $ cat mymodule2.py

    # define some temporary names
    a, b, c, d, e, f = 1, 2, 3, 4, 5, 6
    # do some work
    result = a+b+c+d*e**f
    # delete the temp variables
    a = None
    b = None
    c = None
    d = None
    e = None
    f = None

    Now import them into Python:

    py> import mymodule1, mymodule2
    py> dir(mymodule1)
    ['__file__', '__name__', result]
    py> dir(mymodule2)
    ['__file__', '__name__', result, a, b, c, d, e, f]

    Or worse, do this:

    py> a = 1
    py> from mymodule2 import *
    py> a + 1
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

    It is bad enough that from module import * can over-write your variables
    with the modules' variables, but for it to do so with DELETED variables is
    unforgivable.



    --
    Steven.
    Steven D'Aprano, Jul 6, 2005
    #2
    1. Advertising

  3. Jp Calderone

    Ron Adam Guest

    Steven D'Aprano wrote:
    > On Wed, 06 Jul 2005 10:00:02 -0400, Jp Calderone wrote:
    >
    >
    >>On Wed, 06 Jul 2005 09:45:56 -0400, Peter Hansen <> wrote:
    >>
    >>>Tom Anderson wrote:
    >>>
    >>>>How about just getting rid of del? Removal from collections could be
    >>>>done with a method call, and i'm not convinced that deleting variables
    >>>>is something we really need to be able to do (most other languages
    >>>>manage without it).
    >>>
    >>>Arguing the case for del: how would I, in doing automated testing,
    >>>ensure that I've returned everything to a "clean" starting point in all
    >>>cases if I can't delete variables? Sometimes a global is the simplest
    >>>way to do something... how do I delete a global if not with "del"?
    >>>

    >>
    >>Unless you are actually relying on the global name not being defined, "someGlobal = None" would seem to do just fine.
    >>
    >>Relying on the global name not being defined seems like an edge case.

    >
    >
    > Er, there is a lot of difference between a name not existing and it being
    > set to None.


    Yes, they are not currently the same thing.


    But what if assigning a name to None actually unbound it's name?


    And accessing an undefined name returned None instead of a NameError?


    Using an undefined name in most places will still generate some sort of
    an None type error.

    I think the biggest drawback to this second suggestion is that we would
    have to test for None in places where it would matter, but that's
    probably a good thing and enables checking if a variable exists without
    using a try-except.


    $ cat mymodule2.py

    # define some temporary names
    a, b, c, d, e, f = 1, 2, 3, 4, 5, 6
    # do some work
    result = a+b+c+d*e**f
    # delete the temp variables
    a = b = c = d = e = f = None # possibly unbind names

    This would work if None unbound names.


    > It is bad enough that from module import * can over-write your variables
    > with the modules' variables, but for it to do so with DELETED variables is
    > unforgivable.


    Yes, I agree using None as an alternative to delete currently is
    unacceptable.

    Cheers,
    Ron
    Ron Adam, Jul 6, 2005
    #3
  4. On 2005-07-06 18:10:16, Ron Adam wrote:

    > But what if assigning a name to None actually unbound it's name?
    > And accessing an undefined name returned None instead of a NameError?


    Yes, and we can make

    someunknownlist[] = 2

    magically do someunknownlist = list() and append 2.


    Please.

    --
    Stian Søiland Work toward win-win situation. Win-lose
    Trondheim, Norway is where you win and the other lose.
    http://soiland.no/ Lose-lose and lose-win are left as an
    exercise to the reader. [Limoncelli/Hogan]
    Stian =?iso-8859-1?Q?S=F8iland?=, Jul 6, 2005
    #4
  5. Jp Calderone

    Benji York Guest

    Stian Søiland wrote:
    > Yes, and we can make
    >
    > someunknownlist[] = 2
    >
    > magically do someunknownlist = list() and append 2.


    I hope you're being sarcastic. :)

    If not, why don't you like:

    some_list = [2]
    --
    Benji York
    Benji York, Jul 6, 2005
    #5
  6. Jp Calderone

    Ron Adam Guest

    Ron Adam wrote:

    > And accessing an undefined name returned None instead of a NameError?


    I retract this. ;-)

    It's not a good idea. But assigning to None as a way to unbind a name
    may still be an option.
    Ron Adam, Jul 6, 2005
    #6
  7. Ron Adam wrote:
    > Ron Adam wrote:
    >
    >> And accessing an undefined name returned None instead of a NameError?

    >
    > I retract this. ;-)
    >
    > It's not a good idea. But assigning to None as a way to unbind a name
    > may still be an option.


    IMO, it isn't. This would completely preclude the usage of None as a value.
    None is mostly used as a "null value". The most prominent example is default
    function arguments:

    def foo(bar, baz=None):

    With None unbinding the name, what would you suggest should happen? baz being
    undefined in the function scope?

    Or, what should happen for

    somedict[1] = None

    The same as

    del somedict[1]

    ? Also, the concept of _assigning_ something to a name to actually _unassign_
    the name is completely wrong.

    Of course, this is a possible way to unassign names if (and only if)
    (1) there is a real "undefined" value (not None)
    (2) unbound names return the undefined value

    Look at Perl. Do we want to be like that? ;)

    Reinhold
    Reinhold Birkenfeld, Jul 6, 2005
    #7
  8. Jp Calderone

    Ron Adam Guest

    Reinhold Birkenfeld wrote:

    > Ron Adam wrote:
    >
    >>Ron Adam wrote:
    >>
    >>
    >>>And accessing an undefined name returned None instead of a NameError?

    >>
    >>I retract this. ;-)
    >>
    >>It's not a good idea. But assigning to None as a way to unbind a name
    >>may still be an option.

    >
    > IMO, it isn't. This would completely preclude the usage of None as a value.
    > None is mostly used as a "null value". The most prominent example is default
    > function arguments:
    >
    > def foo(bar, baz=None):
    >
    > With None unbinding the name, what would you suggest should happen? baz being
    > undefined in the function scope?


    It would be a way to set an argument as being optional without actually
    assigning a value to it. The conflict would be if there where a global
    with the name baz as well. Probably it would be better to use a valid
    null value for what ever baz if for. If it's a string then "", if its a
    number then 0, if it's a list then [], etc...

    If it's an object... I suppose that would be None... Oh well. ;-)

    > Or, what should happen for
    >
    > somedict[1] = None


    Remove the key of course.

    var = somedict[1] Would then give an error.

    and

    (somedict[1] == None) Would evaluate to True.


    > ? Also, the concept of _assigning_ something to a name to actually _unassign_
    > the name is completely wrong.


    That's not anymore wrong than ([] == [None]) --> False.

    Having a None value remove a name binding could make the above condition
    True.

    > Of course, this is a possible way to unassign names if (and only if)
    > (1) there is a real "undefined" value (not None)
    > (2) unbound names return the undefined value
    >
    > Look at Perl. Do we want to be like that? ;)
    >
    > Reinhold


    The problem I had with perl is that number of symbols and ways of
    combining them can be quite confusing when you don't use it often. So
    it's either a language you use all the time... or avoid.

    Anyway, there seems to be enough subtle side effects both small and
    large to discount the idea. While implementing it may be possible, it
    would require a number of other changes as well as a different way of
    thinking about it, so I expect it would be disliked quite a bit.

    Cheers,
    Ron
    Ron Adam, Jul 6, 2005
    #8
  9. On 2005-07-06, Ron Adam <> wrote:

    > It would be a way to set an argument as being optional without actually
    > assigning a value to it. The conflict would be if there where a global
    > with the name baz as well. Probably it would be better to use a valid
    > null value for what ever baz if for. If it's a string then "", if its a
    > number then 0, if it's a list then [], etc...


    Except those aren't "null values" for those types. 0 is a
    perfectly good integer value, and I use it quite often. There's
    a big difference between an "invalid integer value" and an
    integer with value 0.

    --
    Grant Edwards grante Yow! I've read SEVEN
    at MILLION books!!
    visi.com
    Grant Edwards, Jul 6, 2005
    #9
  10. Jp Calderone

    Ron Adam Guest

    Grant Edwards wrote:

    > On 2005-07-06, Ron Adam <> wrote:
    >
    >
    >>It would be a way to set an argument as being optional without actually
    >>assigning a value to it. The conflict would be if there where a global
    >>with the name baz as well. Probably it would be better to use a valid
    >>null value for what ever baz if for. If it's a string then "", if its a
    >>number then 0, if it's a list then [], etc...

    >
    >
    > Except those aren't "null values" for those types. 0 is a
    > perfectly good integer value, and I use it quite often. There's
    > a big difference between an "invalid integer value" and an
    > integer with value 0.


    Why would you want to use None as an integer value?

    If a value isn't established yet, then do you need the name defined?
    Wouldn't it be better to wait until you need the name then give it a value?
    Ron Adam, Jul 7, 2005
    #10
  11. On 2005-07-07, Ron Adam <> wrote:
    > Grant Edwards wrote:
    >
    >> On 2005-07-06, Ron Adam <> wrote:
    >>
    >>
    >>>It would be a way to set an argument as being optional without
    >>>actually assigning a value to it. The conflict would be if
    >>>there where a global with the name baz as well. Probably it
    >>>would be better to use a valid null value for what ever baz if
    >>>for. If it's a string then "", if its a number then 0, if it's
    >>>a list then [], etc...

    >>
    >> Except those aren't "null values" for those types. 0 is a
    >> perfectly good integer value, and I use it quite often. There's
    >> a big difference between an "invalid integer value" and an
    >> integer with value 0.

    >
    > Why would you want to use None as an integer value?


    1) So I know whether an parameter was passed in or not. Perhaps
    it's not considered good Pythonic style, but I like to use a
    single method for both get and set operations. With no
    parameters, it's a get. With a parameter, it's a set:

    class demo:
    def foo(v=None):
    if v is not None:
    self.v = v
    return self.v

    2) So I can use it as sort of a NaN equivalent.

    if self.fd is None:
    self.fd = os.open('foo.bar','w')

    if self.fd is not None:
    os.close(self.fd)
    self.fd = None

    > If a value isn't established yet, then do you need the name
    > defined?


    I find it more obvious to set the name to None during the
    periods that it isn't valid than to delete it and check for a
    NameError when I want to know if the value is usable or not.

    > Wouldn't it be better to wait until you need the name then
    > give it a value?


    "Better" is a value judgement. I prefer setting it None and
    than deleting it and then checking for existance.

    --
    Grant Edwards grante Yow! Hey, LOOK!! A pair of
    at SIZE 9 CAPRI PANTS!! They
    visi.com probably belong to SAMMY
    DAVIS, JR.!!
    Grant Edwards, Jul 7, 2005
    #11
  12. Grant Edwards wrote:
    > 1) So I know whether an parameter was passed in or not. Perhaps
    > it's not considered good Pythonic style, but I like to use a
    > single method for both get and set operations. With no
    > parameters, it's a get. With a parameter, it's a set:
    >
    > class demo:
    > def foo(v=None):
    > if v is not None:
    > self.v = v
    > return self.v


    _NOVALUE = object()
    class demo:
    def foo(v=_NOVALUE):
    if v is _NOVALUE:
    return self.v
    else:
    self.v = v

    But what's wrong with properties?
    Leif K-Brooks, Jul 7, 2005
    #12
  13. On 2005-07-07, Leif K-Brooks <> wrote:

    > Grant Edwards wrote:
    >> 1) So I know whether an parameter was passed in or not. Perhaps
    >> it's not considered good Pythonic style, but I like to use a
    >> single method for both get and set operations. With no
    >> parameters, it's a get. With a parameter, it's a set:
    >>
    >> class demo:
    >> def foo(v=None):
    >> if v is not None:
    >> self.v = v
    >> return self.v

    >
    > _NOVALUE = object()
    > class demo:
    > def foo(v=_NOVALUE):
    > if v is _NOVALUE:
    > return self.v
    > else:
    > self.v = v


    Apart from the change in the logic such that the set operation
    doesn't return a value, how is that any different? You're just
    creating your own non-integer-value "None" object instead of
    using the one built in to the language.

    > But what's wrong with properties?


    Huh?

    --
    Grant Edwards grante Yow!
    at TAILFINS!!... click...
    visi.com
    Grant Edwards, Jul 7, 2005
    #13
  14. "Grant Edwards" wrote:

    > In 2005-07-07, Leif K-Brooks <> wrote:
    >
    > - Hide quoted text -
    > - Show quoted text -
    > > Grant Edwards wrote:
    > >> 1) So I know whether an parameter was passed in or not. Perhaps
    > >> it's not considered good Pythonic style, but I like to use a
    > >> single method for both get and set operations. With no
    > >> parameters, it's a get. With a parameter, it's a set:

    >
    > >> class demo:
    > >> def foo(v=None):
    > >> if v is not None:
    > >> self.v = v
    > >> return self.v

    >
    > > _NOVALUE = object()
    > > class demo:
    > > def foo(v=_NOVALUE):
    > > if v is _NOVALUE:
    > > return self.v
    > > else:
    > > self.v = v

    >
    > Apart from the change in the logic such that the set operation
    > doesn't return a value, how is that any different? You're just
    > creating your own non-integer-value "None" object instead of
    > using the one built in to the language.
    >
    > > But what's wrong with properties?

    >
    > Huh?


    I guess he means why not define foo as property:

    class demo(object):
    foo = property(fget = lambda self: self.v,
    fset = lambda self,v: setattr(self,'v',v))

    d = demo()
    d.foo = 3
    print d.foo


    George
    George Sakkis, Jul 7, 2005
    #14
  15. Grant Edwards wrote:
    > On 2005-07-07, Leif K-Brooks <> wrote:
    >>_NOVALUE = object()
    >>class demo:
    >> def foo(v=_NOVALUE):
    >> if v is _NOVALUE:
    >> return self.v
    >> else:
    >> self.v = v

    >
    >
    > Apart from the change in the logic such that the set operation
    > doesn't return a value, how is that any different? You're just
    > creating your own non-integer-value "None" object instead of
    > using the one built in to the language.


    Sorry, my mistake: for some reason, I misunderstood your message as
    complaining that you couldn't do the same thing if you needed None to be
    usable as a value too.

    >>But what's wrong with properties?

    >
    > Huh?


    Why not use a property
    (http://www.python.org/2.2.1/descrintro.html#property) instead of a
    special property-like method?
    Leif K-Brooks, Jul 7, 2005
    #15
  16. On 2005-07-07, George Sakkis <> wrote:

    > I guess he means why not define foo as property:
    >
    > class demo(object):
    > foo = property(fget = lambda self: self.v,
    > fset = lambda self,v: setattr(self,'v',v))
    >
    > d = demo()
    > d.foo = 3
    > print d.foo


    In some ways that's even cleaner.

    In my simplivied example all the foo() method was doing was
    setting/returning an attribute, but usually there's a bit more
    going on (e.g. system calls with possible side effects).

    To me it's a bit more explicit that

    d.foo(3)
    d.foo()

    are doing something other than just getting/setting the value
    of an instance attribute. If all I really wanted to do was
    get/set the instance's "v" attribute, I probably would have
    just done it like this

    d.v = 3
    print d.v

    --
    Grant Edwards grante Yow! .. I wonder if I
    at ought to tell them about my
    visi.com PREVIOUS LIFE as a COMPLETE
    STRANGER?
    Grant Edwards, Jul 7, 2005
    #16
  17. On 2005-07-07, Leif K-Brooks <> wrote:
    > Grant Edwards wrote:
    >> On 2005-07-07, Leif K-Brooks <> wrote:
    >>>_NOVALUE = object()
    >>>class demo:
    >>> def foo(v=_NOVALUE):
    >>> if v is _NOVALUE:
    >>> return self.v
    >>> else:
    >>> self.v = v

    >>
    >>
    >> Apart from the change in the logic such that the set operation
    >> doesn't return a value, how is that any different? You're just
    >> creating your own non-integer-value "None" object instead of
    >> using the one built in to the language.

    >
    > Sorry, my mistake: for some reason, I misunderstood your message as
    > complaining that you couldn't do the same thing if you needed None to be
    > usable as a value too.


    Somebody had proposed eliminating None as a usable object and
    people who use None now should just use 0, [], "", or ()
    depending on the "type" of the expected value. I was providing
    an example of where I would use None in a context where an
    "integer context" and where 0 wasn't a good substitue.

    >>>But what's wrong with properties?

    >>
    >> Huh?

    >
    > Why not use a property
    > (http://www.python.org/2.2.1/descrintro.html#property) instead of a
    > special property-like method?


    Habit and the desire to make it explicit that something more is
    going on that just assigning or evaluating an instance's
    attribute.

    --
    Grant Edwards grante Yow! I want EARS! I
    at want two ROUND BLACK
    visi.com EARS to make me feel warm
    'n secure!!
    Grant Edwards, Jul 7, 2005
    #17
  18. Jp Calderone

    Ron Adam Guest

    Grant Edwards wrote:

    > On 2005-07-07, Ron Adam <> wrote:
    >
    >>Grant Edwards wrote:
    >>
    >>
    >>>On 2005-07-06, Ron Adam <> wrote:
    >>>
    >>>
    >>>
    >>>>It would be a way to set an argument as being optional without
    >>>>actually assigning a value to it. The conflict would be if
    >>>>there where a global with the name baz as well. Probably it
    >>>>would be better to use a valid null value for what ever baz if
    >>>>for. If it's a string then "", if its a number then 0, if it's
    >>>>a list then [], etc...
    >>>
    >>>Except those aren't "null values" for those types. 0 is a
    >>>perfectly good integer value, and I use it quite often. There's
    >>>a big difference between an "invalid integer value" and an
    >>>integer with value 0.

    >>
    >>Why would you want to use None as an integer value?

    >
    >
    > 1) So I know whether an parameter was passed in or not. Perhaps
    > it's not considered good Pythonic style, but I like to use a
    > single method for both get and set operations. With no
    > parameters, it's a get. With a parameter, it's a set:
    >
    > class demo:
    > def foo(v=None):
    > if v is not None:
    > self.v = v
    > return self.v


    You are really checking if v exists, so having it undefined in namespace
    as the default is consistent with what you are doing.

    As I said above...

    >>>>It would be a way to set an argument as being optional without
    >>>>actually assigning a value to it.


    So it would still work like you expect even though v is not bound to
    anything. Like I said the bigger problem is that globals will be
    visible and that would create a conflict. Setting a value to None in a
    function hides globals of the same name. That wouldn't happen if None
    unbound names as del does.

    So you would need to use something else for that purpose I suppose, but
    that was why None became a literal in the first place, so maybe it's
    taking a step backwards.


    > 2) So I can use it as sort of a NaN equivalent.
    >
    > if self.fd is None:
    > self.fd = os.open('foo.bar','w')
    >
    > if self.fd is not None:
    > os.close(self.fd)
    > self.fd = None


    It would still work as you expect. A while back I suggested an 'also'
    for if that would do exactly that with only one test. Nobody liked it.

    if self.fd is None:
    self.fd = os.open('foo.bar','w')
    # do something with self.fd

    also:
    os.close(self.fd)
    self.fd = None


    >>If a value isn't established yet, then do you need the name
    >>defined?

    >
    > I find it more obvious to set the name to None during the
    > periods that it isn't valid than to delete it and check for a
    > NameError when I want to know if the value is usable or not.


    You would still be able to do that explicitly and it probably would be a
    good idea when you aren't sure if a name is left over from something else.

    If a name is None, it means it's available and unassigned, so you don't
    have to check for a NameError.


    >>Wouldn't it be better to wait until you need the name then
    >>give it a value?

    >
    > "Better" is a value judgement. I prefer setting it None and
    > than deleting it and then checking for existance.


    They would be the same in this case. Setting it to None would delete it
    also. And checking it for None will let you know it's available or if
    it has a value...

    You are right that it's a value judgment. I agree. BTW, I'm sort of
    just exploring this a bit, not trying to argue it's any better than what
    we currently do. I think it could work either way, but it would mean
    doing things in a different way also, not neccisarily a good idea.

    Cheers,
    Ron
    Ron Adam, Jul 7, 2005
    #18
  19. Ron Adam wrote:

    > Why would you want to use None as an integer value?
    >
    > If a value isn't established yet, then do you need the name defined?
    > Wouldn't it be better to wait until you need the name then give it a value?


    Er, maybe I'm misunderstanding something here, but
    surely the most obvious case is for default and special
    function arguments:

    def count_records(record_obj, start=0, end=None):
    if end == None:
    end = len(record_obj)
    if start == None: # this is not the default!
    # start at the current position
    start = record_obj.current
    n = 0
    for rec in record_obj.data[start:end]:
    if not rec.isblank():
    n += 1
    return n

    which you call with:

    # current position to end
    count_records(myRecords, None)
    # start to end
    count_records(myRecords)
    # start to current position
    count_records(myRecords, end=myRecords.current)

    --
    Steven.
    Steven D'Aprano, Jul 7, 2005
    #19
  20. On 2005-07-07, Ron Adam <> wrote:

    >> class demo:
    >> def foo(v=None):
    >> if v is not None:
    >> self.v = v
    >> return self.v

    >
    > You are really checking if v exists, so having it undefined in
    > namespace as the default is consistent with what you are
    > doing.
    >
    > As I said above...
    >
    > >>>>It would be a way to set an argument as being optional without
    > >>>>actually assigning a value to it.

    >
    > So it would still work like you expect even though v is not
    > bound to anything. Like I said the bigger problem is that
    > globals will be visible and that would create a conflict.
    > Setting a value to None in a function hides globals of the
    > same name. That wouldn't happen if None unbound names as del
    > does.


    Good point. I hadn't thought of that.

    > So you would need to use something else for that purpose I
    > suppose, but that was why None became a literal in the first
    > place, so maybe it's taking a step backwards.
    >
    >
    >> 2) So I can use it as sort of a NaN equivalent.
    >>
    >> if self.fd is None:
    >> self.fd = os.open('foo.bar','w')
    >>
    >> if self.fd is not None:
    >> os.close(self.fd)
    >> self.fd = None

    >
    > It would still work as you expect. A while back I suggested an 'also'
    > for if that would do exactly that with only one test. Nobody liked it.
    >
    > if self.fd is None:
    > self.fd = os.open('foo.bar','w')
    > # do something with self.fd
    >
    > also:
    > os.close(self.fd)
    > self.fd = None
    >
    >
    >>>If a value isn't established yet, then do you need the name
    >>>defined?

    >>
    >> I find it more obvious to set the name to None during the
    >> periods that it isn't valid than to delete it and check for a
    >> NameError when I want to know if the value is usable or not.

    >
    > You would still be able to do that explicitly and it probably would be a
    > good idea when you aren't sure if a name is left over from something else.
    >
    > If a name is None, it means it's available and unassigned, so
    > you don't have to check for a NameError.


    How would you spell "if a name is None"?

    Personally, I think the spellings

    del name
    if 'name' in locals()

    is much more explicit/obvious than

    name = None
    name is None

    I expect the "=" operator to bind a name to a value. Having it
    do something completely different some of the time seems a bit
    unpythonic.

    --
    Grant Edwards grante Yow! Today, THREE WINOS
    at from DETROIT sold me a
    visi.com framed photo of TAB HUNTER
    before his MAKEOVER!
    Grant Edwards, Jul 7, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Patrick.O.Ige
    Replies:
    1
    Views:
    443
  2. Uncle Bob (Robert C. Martin)

    Use Cases -- A minimalist's View

    Uncle Bob (Robert C. Martin), Jul 2, 2003, in forum: Java
    Replies:
    0
    Views:
    760
    Uncle Bob (Robert C. Martin)
    Jul 2, 2003
  3. Alan Cyment
    Replies:
    1
    Views:
    1,366
    Esmond Pitt
    Jan 29, 2004
  4. python
    Replies:
    7
    Views:
    304
    Bruno Desthuilliers
    Jun 3, 2006
  5. Albert Hopkins

    When (and why) to use del?

    Albert Hopkins, Dec 9, 2008, in forum: Python
    Replies:
    5
    Views:
    233
Loading...

Share This Page