Re: Adding method to a class on the fly
On Jun 22, 3:02 pm, John Henry <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I have a need to create class methods on the fly. For example, if I
> do:
>
> class Dummy:
> def __init__(self):
> exec '''def method_dynamic(self):\n\treturn
> self.method_static("it's me")'''
> return
>
> def method_static(self, text):
> print text
> return
>
> I like that to be the same as:
>
> class Dummy:
> def __init__(self):
> return
>
> def method_dynamic(self):
> return self.method_static("it's me")
>
> def method_static(self, text):
> print text
> return
>
> so that I can do:
>
> dum=Dummy.method_dynamic()
>
> and see "it's me" printed.
>
> Can that be done?
>
> Thanks,
class Dummy:
def method(self, arg):
print arg
def method2(self, arg):
self.method(arg)
Dummy.method2 = method2
Dummy.method2('Hello, world!')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python plain-text database or library that supports joins?
On Jun 22, 1:18 pm, felciano <[EMAIL PROTECTED]> wrote: > Hello -- > > Is there a convention, library or Pythonic idiom for performing > lightweight relational operations on flatfiles? I frequently find > myself writing code to do simple SQL-like operations between flat > files, such as appending columns from one file to another, linked > through a common id. For example, take a list of addresses and append > a 'district' field by looking up a congressional district from a > second file that maps zip codes to districts. > > Conceptually this is a simple database operation with a join on a > common field (zip code in the above example). Other case use other > relational operators (projection, cross-product, etc) so I'm really > looking for something SQL-like in functionality. However, the data is > in flat-files, the file structure changes frequently, the files are > dynamically generated from a range of sources, are short-lived in > nature, and otherwise not warrant the hassle of a database setup. So > I've been looking around for a nice, Pythonic, zero-config (no > parsers, no setup/teardown, etc) solution for simple queries that > handles a database of csv-files-with-headers automatically. There are > number of solutions that are close, but in the end come up short: > > - KirbyBase 1.9 (latest Python version) is the closest that I could > find, as it lets you keep your data in flatfiles and perform > operations using the field names from those text-based tables, but it > doesn't support joins (the more recent Ruby version seems to). > - Buzhug and Sqlite have their data structures w no automatic .tab > or .csv parsing (unless sqlite includes a way to map flatfiles to > sqlite virtual tables that I don't know about). > -http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/159974is > heading in the right direction, as it shows how to perform relational > operations on lists and are index based rather than field-name based. > -http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498130andhttp://furius.ca/pubcode/pub/conf/common/bin/csv-db-import.html > provide ways of automatically populating DBs but not the reverse > (persist changes back out to the data files) > > The closest alternatives I've found are the GNU textutils that support > join, cut, merge, etc but I need to add additional logic they don't > support, nor do they allow field-level write operations from Python > (UPDATE ... WHERE ...). Normally I'd jump right in and start coding > but this seems like something so common that I would have expected > someone else to have solved, so in the interest of not re-inventing > the wheel I thought I'd see if anyone had any other suggestions. Any > thoughts? > > Thanks! > > Ramon ramon, i don't think that using flat text files as a database is common these days. if you need relational database features what stops you from using rdbms? if the only reason for that is some legacy system then i'd still use in-memory sqlite database for all relational operations. import, process, export back to text if you need to. -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding method to a class on the fly
On Jun 22, 5:17 pm, 7stud <[EMAIL PROTECTED]> wrote:
> On Jun 22, 2:24 pm, askel <[EMAIL PROTECTED]> wrote:
>
> > class Dummy:
> > def method(self, arg):
> > print arg
>
> > def method2(self, arg):
> > self.method(arg)
>
> > Dummy.method2 = method2
> > Dummy.method2('Hello, world!')
>
> Traceback (most recent call last):
> File "test1.py", line 8, in ?
> Dummy.method2('Hello, world!')
> TypeError: unbound method method2() must be called with Dummy instance
> as first argument (got str instance
> instead)
>
>
>
> >I like that to be the same as:
>
> >class Dummy:
> >def __init__(self):
> >return
>
> >def method_dynamic(self):
> >return self.method_static("it's me")
>
> >def method_static(self, text):
> >print text
> > return
>
> >so that I can do:
>
> >dum=Dummy.method_dynamic()
>
> >and see "it's me" printed.
>
> When are you able to see that?
sorry, of course last line should be:
Dummy().method2('Hello, world!')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Adding method to a class on the fly
On Jun 22, 5:17 pm, 7stud <[EMAIL PROTECTED]> wrote:
> On Jun 22, 2:24 pm, askel <[EMAIL PROTECTED]> wrote:
>
> > class Dummy:
> > def method(self, arg):
> > print arg
>
> > def method2(self, arg):
> > self.method(arg)
>
> > Dummy.method2 = method2
> > Dummy.method2('Hello, world!')
>
> Traceback (most recent call last):
> File "test1.py", line 8, in ?
> Dummy.method2('Hello, world!')
> TypeError: unbound method method2() must be called with Dummy instance
> as first argument (got str instance
> instead)
>
>
>
> >I like that to be the same as:
>
> >class Dummy:
> >def __init__(self):
> >return
>
> >def method_dynamic(self):
> >return self.method_static("it's me")
>
> >def method_static(self, text):
> >print text
> > return
>
> >so that I can do:
>
> >dum=Dummy.method_dynamic()
>
> >and see "it's me" printed.
>
> When are you able to see that?
there is no way to call instance method from static one. but in your
case you can make something like:
class Dummy:
@staticmethod
def method(arg):
print arg
def method2(arg):
Dummy.method(arg)
Dummy.method2 = staticmethod(method2)
Dummy.method2('Hello, world!')
- OR -
def method2(cls, arg):
cls.method(arg)
Dummy.method2 = classmethod(method2)
Dummy.method2('Hello, world!')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Creating a multi-tier client/server application
On Aug 29, 1:31 pm, Jeff <[EMAIL PROTECTED]> wrote: > Goldfish--thanks, I'll check it out. > > > > That, or something similar, may be what I do. It would mean, however, > > > developing my own method for transferring objects across the network, > > > Why transfering "objects" ? You only need to transfer data. > > I suppose I don't need to transfer objects, it just seems like it > would make it far easier (certainly less repetition of code) to > program the client-side app. If you prefer to deal with RPC-like protocol, take a look at Ice by ZeroC (http://www.zeroc.com/). -- http://mail.python.org/mailman/listinfo/python-list
Re: Communication between Python and PHP
On Jun 25, 6:59 pm, nicodotti2 <[EMAIL PROTECTED]> wrote: > On Jun 25, 1:50 pm, Larry Bates <[EMAIL PROTECTED]> wrote: > > > > > nicodotti2 wrote: > > > Don't ask me why, but we have a bunch of legacy code in PHP on a > > > server and a wee-bit of Python code for integrating GData google > > > calendar services. We now need to build a way of sending messages > > > between them. The general flow is: > > > > PHP Web Page(on apache) ---> Python Gdata Consumer -> Gdata > > > and then json is returned back like: > > > PHP Web Page> > > So I tried to convince my boss to let me use the python c extension to > > > write a native bridge but 'no dice'. He also does not want anything > > > 'experimental' so pyphp is out. He'd like me to basically have them > > > communicate by passing the json via http/apache - so in essence, I'll > > > have to make (what I feel) are very expensive calls between two > > > objects that, in a perfect world, would be on the same machine in the > > > same language! I see this as a potential bottleneck. Any suggestions? > > > I have to start prototyping this today so the sooner the better, um, > > > please ;) Thanks gurus out there. > > > Use sockets. They are efficient and both languages have good > > implementations. > > > -Larry > > Thanks Larry I'll look into going that route. I wouldn't even try to reinvent the wheel in such a case. You are going to use GData and yet consider HTTP over LAN to be expensive. Get real, man. Save yourself a time by not developing and supporting your own very special wheel. Your boss is not that stupid as he probably seems to you. -- http://mail.python.org/mailman/listinfo/python-list
