Send Python-list mailing list submissions to
python-list@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
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
To: python-list@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.
> [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
To: Jay Loden <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 13:44:57 -0700 (PDT)
Subject: Re: Return name of caller function?
--- Jay Loden <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
To: python-list@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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
To: python-list@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
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
To: python-list@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 <[EMAIL PROTECTED]>
To: python-list@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: [EMAIL PROTECTED] (Aahz)
To: python-list@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 <[EMAIL PROTECTED]>,
Alex Martelli <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <*>
http://www.pythoncraft.com/
"as long as we like the same operating system, things are cool." --piranha
---------- Forwarded message ----------
From: Thomas Jollans <[EMAIL PROTECTED]>
To: python-list@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 <[EMAIL PROTECTED]>
To: python-list@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 <[EMAIL PROTECTED]>
To: python-list@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
