Home Original page

Python-list Digest, Vol 45, Issue 410

hari sirigibathina hari.siri74 at gmail.com
Wed Jun 27 19:51:33 EDT 2007 
Hi all,

Have a question which is making me unrest:

-Calling a method say aMethod() from another method where i mistakenly
initialised a variable with name same as the called method like aMethod =
'string'. When i run this py script triggered "Unbound Local error".
can any  one explain me whats going here ? curios to learn from my mistake
:)

-- 
Warm Regards,

Hari


On 6/27/07, python-list-request at python.org <python-list-request at python.org>
wrote:
>
> Send Python-list mailing list submissions to
>         python-list at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.python.org/mailman/listinfo/python-list
> or, via email, send a message with subject or body 'help' to
>         python-list-request at python.org
>
> You can reach the person managing the list at
>         python-list-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-list digest..."
>
> Today's Topics:
>
>    1. Re: Collections of non-arbitrary objects ? (Bruno Desthuilliers)
>    2. Re: Return name of caller function? (Matthew Peter)
>    3. Re: ANN: PyDAO - Python Hibernate-like Object-Relational
>       Mapper (Luis M. Gonz?lez)
>    4. Re: Zip File Woes (Dave Kuhlman)
>    5. Re: Too many 'self' in python.That's a big flaw in this
>       language. (Bruno Desthuilliers)
>    6. listing the type of an object (Stef Mientki)
>    7. Re: equality & comparison by default (was Re: Too many 'self'
>       in        python.That's a big flaw in this language.) (Aahz)
>    8. Re: listing the type of an object (Thomas Jollans)
>    9. Re: Too many 'self' in python.That's a big flaw in this
>       language. (John Nagle)
>   10. log caller (Matthew Peter)
>
>
> ---------- Forwarded message ----------
> From: Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr>
> To: python-list at python.org
> Date: Thu, 28 Jun 2007 06:36:25 +0200
> Subject: Re: Collections of non-arbitrary objects ?
> walterbyrd a écrit :
> > On Jun 26, 8:23 am, Bruno Desthuilliers <bruno.
> > 42.desthuilli... at wtf.websiteburo.oops.com> wrote:
> >
> >>walterbyrda écrit :
> >>
> >>
> >>>>You do program carefully, don't you ?-)
> >>
> >>>I try. But things like typos are a normal part a life.
> >>
> >>So are they in any language. I fail to see much difference here.
> >>
> >
> >
> > For example: if I mis-type a variable name in C, the program will
> > probably not even compile.
>
> It sometimes happens - but chances are low, for sure.
>
> > Whereas, with Python, the program will
> > probably run, but may give unexpected results.
> >
> Yes, true. Well, in some cases. In one case, to be true: the use of the
> '=' operator. IIRC, any other use of an undefined symbol will raise an
> exception. But this has to do with how symbols are defined in Python
> (ie: the fact that binding => definition), and has nothing to do with
> static (compile-time) type checking.
>
> >
> >>>Guido
> >>>must think python has a lot of room for improvement since he's
> >>>completely throwing out backward compatibility with python 3000.
> >>
> >>Not "completely throwing out". Just allowing *some* major breakages -
> >>the kind you usually get with each major release of other languages, but
> >>that Python managed to avoid as much as possible so far.
> >
> >
> > I don't know, but here is a direct quote from Guido's blog: "Python
> > 3.0 will break backwards compatibility. Totally."
> >
> > http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>
> Please take it with a grain of the salt. This is mostly about getting
> rid of long-time deprecated features.
>
> >
> >>>It seems to me that tuple are essentially immutable lists.
> >>
> >>They are not (even if you can use them that way too). FWIW and IIRC,
> >>this is a FAQ.
> >
> > A few posters here have stated that tuples are not just immutable but
> > when I compare lists, to tuples, I notice that both are ordered
> > collections of arbitrary objects, with the primary difference being
> > that list are mutable, and tuples are not.
>
> This is of course technically true. And you forgot to compare to sets,
> while we're at it. But the answer to your questions about tuples is not
> technical - it's about use case.
>
> > It seems to me that if a
> > list were immutable, it would be a tuple. That is the one big
> > difference.
> >
> > Tuples have been compared to records/structures in other languages.
> > But, in general, I can not use a for loop to loop through the fields
> > in a record,
>
> For which definition of "in general" ? I can do this with at least
> Python, PHP, Javascript, Ruby, and probably Java (IIRC).
>
> > and I can not sort those fields either.
>
> Did you try to sort a tuple ?
>
> >>> (1, "aaa").sort()
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> AttributeError: 'tuple' object has no attribute 'sort'
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Matthew Peter <survivedsushi at yahoo.com>
> To: Jay Loden <python at jayloden.com>
> Date: Wed, 27 Jun 2007 13:44:57 -0700 (PDT)
> Subject: Re: Return name of caller function?
>
> --- Jay Loden <python at jayloden.com> wrote:
>
> >
> > Matthew Peter wrote:
> > > For example, how do I get this to work?
> > >
> > > def func():
> > >     print "This is", __?__
> > >     return __caller__
> > >
> > > def echo():
> > >     print "This is ", __?__
> > >     return func()
> > >
> > >
> > >>>> print echo()
> > > This is echo
> > > This is func
> > > echo
> >
> > This may not be what you're looking for but here's the solution I ended
> up with
> > after some help from the list. It's designed for getting the name of an
> instance
> > method, but in case it applies to your particular situation:
> >
> > #!/usr/bin/python
> >
> > import functools
> >
> > class TestClass:
> >   def __init__(self):
> >     pass
> >
> >   def __getattr__(self, name):
> >     try:
> >       return getattr(self.__class__, name)
> >     except AttributeError:
> >       return functools.partial(self.foo, name)
> >
> >   def foo(self, name, **args):
> >     print "This is", name
> >
> > test = TestClass()
> > test.someMethod()
> > test.anotherMethod()
> >
> > Otherwise the inspect module may be the way to go, as Stephen already
> pointed out
> > (though I must admit it seems a very inelegant route, especially
> compared to
> > Python's usually clean and clear style).
> >
> > -Jay
> >
>
>
> Thanks for the reply.
>
> The goal is to get it working outside of a class. Overloading the method
> with
> getattr semi-works but it doesn't work in the larger context of what I am
> trying to
> accomplish.
>
> You could avoid the exception block in your example:
>
>
> >   def __getattr__(self, name):
> >     try:
> >       return getattr(self.__class__, name)
> >     except AttributeError:
> >       return functools.partial(self.foo, name)
>
> to:
>
>    def __getattr__(self, name, *args, **kw):
>        return getattr(self.__class__, name, functools.partial(self.foo,
> name, *args,
> **kw))
>
>    def foo(self, name, *args, **kw):
>      print "This is", name, args, kw
>
>
> print test.squeaky("I need oil")
>
>
>
>
>
>
>
> ____________________________________________________________________________________
> Looking for a deal? Find great prices on flights and hotels with Yahoo!
> FareChase.
> http://farechase.yahoo.com/
>
>
>
> ---------- Forwarded message ----------
> From: Luis M. González <luismgz at gmail.com>
> To: python-list at python.org
> Date: Wed, 27 Jun 2007 20:43:55 -0000
> Subject: Re: ANN: PyDAO - Python Hibernate-like Object-Relational Mapper
> On Jun 27, 4:08 pm, cieslak.dari... at gmail.com wrote:
> > PyDAO is very thin object-relational mapper similar to Hibernate (but
> > much simpler). It's created to speed-up application development. It's
> > very simple, but powerful, based on POPO (Plain Old Python Objects).
> >
> >  http://aplikacja.info/PyDAO.html
> >
> > Main features:
> >
> >  - can use any database that has DB-API interface (MySQLdb, psycopg
> >    tested)
> >  - can work without database at all (useful for early phases of
> >    development)
> >  - speeds up unit testing (dedicated in memory database)
> >
> > What is not handled:
> >
> >  - automatic scheme generation
> >  - separate query language
> >  - automated handling of associations (replaced by filtering by
> >    foreign keys)
> >
> > Here's an example how to use PyDAO:
> >
> >     class User:
> >         def __init__(self):
> >             self.id = None
> >             self.login = None
> >             self.password = None
> >
> >     dao = pydao.InMemoryDao()
> >
> >     # filling database
> >     user = User()
> >     user.login = "user1"
> >     user.password = "roh8OoPh"
> >     dao.save(user)
> >
> >     # filtering based on example
> >     userSearch = User()
> >     userSearch.login = "user1"
> >     userList = dao.list(userSearch)
> >
> >     # updating
> >     user.password = "eew8Me8g"
> >     dao.update(user)
> >
> > Enjoy!
> >
> > --
> > Dariusz Cieslakhttp://aplikacja.info- custom software systems
>
>
> Interesting, but The link to AbstractDaoTest.py gives me an error
> message...
>
>
>
>
> ---------- Forwarded message ----------
> From: Dave Kuhlman <dkuhlman at rexx.com>
> To: python-list at python.org
> Date: Wed, 27 Jun 2007 20:56:17 GMT
> Subject: Re: Zip File Woes
> Jerry Hill wrote:
>
> > On 6/27/07, Robert Rawlins - Think Blue
> > <robert.rawlins at thinkbluemedia.co.uk> wrote:
> >>               zip = zipfile.ZipFile('Media/Media.zip', 'r')
> >
> > Shouldn't you open this file in binary mode?  It shouldn't make
> > any difference on unix machines, but will possibly break under
> > windows. That may also explain why it works properly in one
> > environment, and not in another.
> >
>
> It wouldn't hurt, but ...
>
> Actually, it is the underlying file that should be opened in
> binary mode.
>
> I just looked at the source for the zipfile module.  It throws
> away the 'b' if the mode contains a 'b'.
>
> If you pass it a file name, zipfile always opens the underlying
> file in binary mode.  If you pass in a file, then it is your
> responsibility to open that file in binary mode.
>
> Dave
>
> --
> http://www.rexx.com/~dkuhlman
>
>
>
> ---------- Forwarded message ----------
> From: Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr>
> To: python-list at python.org
> Date: Thu, 28 Jun 2007 07:00:23 +0200
> Subject: Re: Too many 'self' in python.That's a big flaw in this language.
> Jorgen Bodde a écrit :
> > I had the same feeling when I started, coming from a C++ background, I
> > forgot about self a lot, creating local copies of what should be an
> > assign to a class instance, or methods that could not be found because
> > I forgot 'self' .
> >
> > Now I am 'kinda' used to it, as every language has some draw backs
> > (you can't please all). But, what about something in between like only
> > using the dot (.) for a shorter notation?
> >
> > self.some_var = True
> >
> > Could become:
> >
> > .some_var = True
> >
> > Which basically shows about the same thing, but you leave 'self' out
> > of the syntax. Ofcourse it should not be allowed to break a line
> > between the dot and the keywords, else Python would never know what to
> > do;
> >
> > my_class()
> > .my_var = True
> >
> > Should not be parsed the same as;
> >
> > my_class().my_var = True
> >
> > Just a suggestion. I am pretty happy with self, but I could settle for
> > a shorter version if possible.
> >
> What is nice with the required, explicit reference to the instance -
> which BTW and so far is not required to be *named* 'self' - is that it
> avoids the need for distinct rules (and different implementations) for
> functions and methods. The different 'method' types are just very thin
> wrappers around function objects. Which in turn allow to use 'ordinary'
> functions (defined outside a class) as methods - IOW, to dynamically
> extend classes (and instances) with plain functions. Uniformity can also
> have very practical virtues...
>
>
>
> ---------- Forwarded message ----------
> From: Stef Mientki <S.Mientki-nospam at mailbox.kun.nl>
> To: python-list at python.org
> Date: Wed, 27 Jun 2007 23:12:26 +0200
> Subject: listing the type of an object
> How can I list a type of an object instance ?
>
> I tried:
>
> class tLED (tDevice):
>    def some_proc(self):
>      print 'type(self)', type(self)
>
> But i gives me:
>    type(self) <type 'instance'>
>
> Moreover, I want even the type to be listed by it's ancestor, like this
>
> class tDevice:
>    def some_other_proc:
>      print 'type(self)', type(self)
>
> thanks,
> Stef Mientki
>
>
>
>
> ---------- Forwarded message ----------
> From: aahz at pythoncraft.com (Aahz)
> To: python-list at python.org
> Date: 27 Jun 2007 14:13:50 -0700
> Subject: Re: equality & comparison by default (was Re: Too many 'self' in
> python.That's a big flaw in this language.)
> In article <1i0cy8z.z94q5d1dxgexxN%aleax at mac.com>,
> Alex Martelli <aleax at mac.com> wrote:
> >
> >In Python 3000, ordering comparisons will not exist by default (sigh, a
> >modest loss of practicality on the altar of purity -- ah well, saw it
> >coming, ever since complex numbers lost ordering comparisons), but
> >equality and hashing should remain just like now (yay!).
>
> While emotionally I agree with you, in practice I have come to agree
> with the POV that allowing default ordering comparisons between disjoint
> types causes subtle bugs that are more difficult to fix than the small
> amount of boilerplate needed to force comparisons when desired.
> --
> Aahz (aahz at pythoncraft.com)           <*>
> http://www.pythoncraft.com/
>
> "as long as we like the same operating system, things are cool." --piranha
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Jollans <thomas at jollans.com>
> To: python-list at python.org
> Date: Wed, 27 Jun 2007 23:21:34 +0200
> Subject: Re: listing the type of an object
> Stef Mientki wrote:
> > How can I list a type of an object instance ?
> >
> > I tried:
> >
> > class tLED (tDevice):
> >   def some_proc(self):
> >     print 'type(self)', type(self)
> >
> > But i gives me:
> >   type(self) <type 'instance'>
> >
> > Moreover, I want even the type to be listed by it's ancestor, like this
> >
> > class tDevice:
> >   def some_other_proc:
> >     print 'type(self)', type(self)
> >
>
> Ahhh, history. At the moment (that is in  2.2 <= Python Version < 3.0 ),
> there are two types of classes: old-style classes are the default and a
> load of WTF?, which new-style classes make sense and behave like you
> (that is "one" in general and you, Stef, in particular) expect.
>
> As I'm too lazy to explain what all this is about, I'll point you to a
> page with a promising title:
>
> http://wiki.python.org/moin/NewClassVsClassicClass
>
> Thomas Jollans
>
>
>
> ---------- Forwarded message ----------
> From: John Nagle <nagle at animats.com>
> To: python-list at python.org
> Date: Wed, 27 Jun 2007 14:54:36 -0700
> Subject: Re: Too many 'self' in python.That's a big flaw in this language.
> Bruno Desthuilliers wrote:
> > Jorgen Bodde a écrit :
> >
> >> But, what about something in between like only
> >> using the dot (.) for a shorter notation?
>
>      How about "Mavis Beacon Teaches Typing"?
>
>                                 John Nagle
>
>
>
> ---------- Forwarded message ----------
> From: Matthew Peter <survivedsushi at yahoo.com>
> To: python-list at python.org
> Date: Wed, 27 Jun 2007 14:42:45 -0700 (PDT)
> Subject: log caller
> Is it possible to print the function calls to a module? Like:
>
> test.py
> import mymod
> print mymod.x()
>
>
> mymod.py
> # each time a function is called we print out the called function and
> module
> print 'Func call: %s from %s' % (???, ???)
>
> def x():
>      return 'hello'
>
> Where would I pick up the ??? variables? A brief example would be nice too
> :) Thanks
> in advance!
>
>
>
>
> ____________________________________________________________________________________
> The fish are biting.
> Get more visitors on your site using Yahoo! Search Marketing.
> http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>


-- 
Warm Regards,

Hari
617.770.1159
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20070627/3e3934bb/attachment.html>
More information about the Python-list mailing list