From baiju.m.mail at gmail.com  Wed Feb 12 05:49:10 2014
From: baiju.m.mail at gmail.com (Baiju Muthukadan)
Date: Tue, 11 Feb 2014 20:49:10 -0800 (PST)
Subject: [Chennaipy] PyCon India 2014 Call for Proposals
Message-ID: <52fafd46.c2d1440a.70c3.ffffb270@mx.google.com>

Hi,

It's that time of year again! PyCon India 2014 will be taking place
from September 26-28 in Bangalore and we're ready to accept
proposals. Registration will open soon, so mark your calendars and get
ready to visit Bangalore for another great PyCon India.

The PyCon India website has received a beautiful refresh, 
Check out our new site at: http://in.pycon.org/2014

We've received good numbers of proposals over each of the last several
years, and we expect this year to be no different. For 2013 we
received nearly 100 proposals for talks and workshops.

If you're interested in submitting a proposal, take a look at our Call
for Proposals at http://in.pycon.org/funnel/2014/ and poke around the
site for advice and resources to help you create a great proposal.

If your company is interested in sponsorship, we need you. Sponsors
are what make PyCon India a possibility, and sponsorship offers some
great values to the generous organizations who support the
conference. Check out prospectus at
http://in.pycon.org/2014/sponsorship-prospectus.pdf Contact Vijay
Kumar at vnbang2003 at gmail.com with any sponsorship inquiries.

Keep an eye out for news on our blog at http://in.pycon.org/blog/ and
follow us on twitter at https://twitter.com/pyconindia and Facebook at
https://www.facebook.com/PyConIndia

Vijay Kumar, Coordinator
vnbang2003 at gmail.com

Baiju Muthukadan, Publicity Coordinator
baiju.m.mail at gmail.com

From vijaykumar at bravegnu.org  Thu Feb 13 17:59:55 2014
From: vijaykumar at bravegnu.org (Vijay Kumar)
Date: Thu, 13 Feb 2014 22:29:55 +0530
Subject: [Chennaipy] Talks for the next meet
Message-ID: <52FCFA0B.807@bravegnu.org>

Hi Everyone,
the monthly meet is on the 22nd of this month. If you
are interested in giving a talk, please let us know.

Regards,
Vijay

From tshrinivasan at gmail.com  Tue Feb 18 06:47:51 2014
From: tshrinivasan at gmail.com (Shrinivasan T)
Date: Tue, 18 Feb 2014 11:17:51 +0530
Subject: [Chennaipy] Fwd: Looking for speakers at MIT
In-Reply-To: <CAND2797FU0uR4Ui_+OaS_uo-LkJrnkqKGQSMEkSZTzcHjdbg7w@mail.gmail.com>
References: <CAND2797FU0uR4Ui_+OaS_uo-LkJrnkqKGQSMEkSZTzcHjdbg7w@mail.gmail.com>
Message-ID: <CAND2794gXuZP_a56Th4srnxSzkLZuw3159egRv2vXdPpHAxLMQ@mail.gmail.com>

Can anyone give a talk on python ?
---------- Forwarded message ----------
From: "Shrinivasan T" <tshrinivasan at gmail.com>
Date: Feb 14, 2014 5:55 PM
Subject: Looking for speakers at MIT
To: "ILUG-C" <ilugc at ae.iitm.ac.in>
Cc:

MIT, chromepet is conducting a technical event on march 14.

They are looking for 5-6 speakers to speak on various topics.

Talks can be around one or two hours.

Reply here if you are interested in giving a talk.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chennaipy/attachments/20140218/5df34eb3/attachment.html>

From prasmailme at gmail.com  Tue Feb 18 07:28:43 2014
From: prasmailme at gmail.com (Prasanna Venkadesh)
Date: Tue, 18 Feb 2014 11:58:43 +0530
Subject: [Chennaipy] Fwd: Looking for speakers at MIT
In-Reply-To: <CAND2794gXuZP_a56Th4srnxSzkLZuw3159egRv2vXdPpHAxLMQ@mail.gmail.com>
References: <CAND2797FU0uR4Ui_+OaS_uo-LkJrnkqKGQSMEkSZTzcHjdbg7w@mail.gmail.com>
 <CAND2794gXuZP_a56Th4srnxSzkLZuw3159egRv2vXdPpHAxLMQ@mail.gmail.com>
Message-ID: <CACm7z1YMwx7CtONm33hjCXo6HBS7uVwVFq7F=WkG9g9HGQBpbg@mail.gmail.com>

On Tue, Feb 18, 2014 at 11:17 AM, Shrinivasan T <tshrinivasan at gmail.com>wrote:

> Can anyone give a talk on python ?
>
I can. On what level the talk should be? Could you post more details on it?


> ---------- Forwarded message ----------
> From: "Shrinivasan T" <tshrinivasan at gmail.com>
> Date: Feb 14, 2014 5:55 PM
> Subject: Looking for speakers at MIT
> To: "ILUG-C" <ilugc at ae.iitm.ac.in>
> Cc:
>
> MIT, chromepet is conducting a technical event on march 14.
>
> They are looking for 5-6 speakers to speak on various topics.
>
> Talks can be around one or two hours.
>
> Reply here if you are interested in giving a talk.
>
> Thanks.
>
> _______________________________________________
> Chennaipy mailing list
> Chennaipy at python.org
> https://mail.python.org/mailman/listinfo/chennaipy
>
>


-- 
Thanks & Regards,
Prasanna Venkadesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chennaipy/attachments/20140218/b1929b2a/attachment.html>

From baiju.m.mail at gmail.com  Wed Feb 19 07:46:37 2014
From: baiju.m.mail at gmail.com (Baiju Muthukadan)
Date: Tue, 18 Feb 2014 22:46:37 -0800 (PST)
Subject: [Chennaipy] PyCon India 2014 Call for Sponsors
Message-ID: <5304534d.a3b2440a.2b32.ffffac96@mx.google.com>

Hi,
 
I hope you've received the mail regarding call for proposals for PyCon
India 2014.  This time, I want your help to get more sponsors for the
event!

If your company is interested in sponsorship, we need you.  Sponsors
are what make PyCon India a possibility, and sponsorship offers some
great values to the generous organizations who support the conference.
Check out prospectus at
http://in.pycon.org/2014/sponsorship-prospectus.pdf Contact Vijay
Kumar at vnbang2003 at gmail.com with any sponsorship inquiries.

By sponsoring the conference, your organization will be better
connected to the Indian Python community.  Your sponsorship helps keep
PyCon India affordable and accessible to the widest possible audience.

This year, PyCon India 2014 will be taking place from September 26-28
in Bangalore.  Check out our site at: http://in.pycon.org/2014
 
Keep an eye out for news on our blog at http://in.pycon.org/blog/ and
follow us on twitter at https://twitter.com/pyconindia and Facebook at
https://www.facebook.com/PyConIndia

Please forward this mail to other related groups, organizations,
companies and individuals who can help us to get some sponsorship.
 
Help us make the event more awesome!

Vijay Kumar, Coordinator
vnbang2003 at gmail.com
 
Baiju Muthukadan, Publicity Coordinator
baiju.m.mail at gmail.com

From vijaykumar at bravegnu.org  Thu Feb 20 03:19:08 2014
From: vijaykumar at bravegnu.org (Vijay Kumar)
Date: Thu, 20 Feb 2014 07:49:08 +0530
Subject: [Chennaipy] February Monthly Meet
Message-ID: <5305661C.5010100@bravegnu.org>

= February Monthly Meet

== Date & Time

22nd February
3:00pm to 5:00pm

== Venue

Zilogic Systems,
Fourth Main Road,
Kamaraj Nagar,
Thiruvanmiyur,
Chennai

Location map: http://www.zilogic.com/contact.html

== Agenda

Talk 1: XML-RPC and Python
by Vijay Kumar
Duration: 45 min

XML-RPC is a remote procedure call protocol which uses XML to
encode its calls and HTTP as a transport mechanism. This talk will
cover the following topics.

   * XML Basics
   * XML-RPC Protocol
   * Writing XML-RPC clients in Python
   * Writing XML-RPC servers in Python

If you would like to give a lightning talk, just come prepared, we
will be able to accommodate you.

If you are new to Python, the tutorial at
http://learnxinyminutes.com/docs/python/ will give you a quick
overview of what Python is all about.

Regards,
Vijay

From sangeeth.saravanaraj at gmail.com  Tue Feb 25 01:49:51 2014
From: sangeeth.saravanaraj at gmail.com (Sangeeth Saravanaraj)
Date: Tue, 25 Feb 2014 06:19:51 +0530
Subject: [Chennaipy] Class decorator to capture the creation and deletion of
	objects
Message-ID: <CAPbKEUp_OS_PukUz2KObOSLQzjwGehPOfG4C-3Gq9qq=RaASgQ@mail.gmail.com>

This question was initially asked in tutor at python.org; Now I am widening
the audience to gain attention.

I want to create a decorator which should do the following things:
 => When an object of the decorated class is created, the objects name (say
the value of the incoming "id" argument) should be stored as a record in a
table in a database.
 => When an object of the decorated class is deleted, the record with this
deleted objects name (i.e. object.id) should be removed from the table.

Now, for example - consider the following snippet:

@saveme
class A(object):
    def __init__(self, id):
        self.id = id

@saveme
class B(object):
    def __init__(self, id):
        self.id = id

"saveme" should do what I have explained earlier.

a1 = A("A1")
a2 = A("A2")
a3 = A("A3")
b1 = B("B1")
b2 = B("B2")

At this point if I query and print all the records in a table, I should get
the following output:
["A1", "A2", "A3", "B1", "B2"]

del a1
del a2
del a3
del b1
del b2

At this point, all entries in the table should be deleted; query should
return an empty list!

And, I want to highlight that the classes that are being decorated with
"saveme" can de derived classes too [which initialises its base classes
using super() method]!

Now the following is what I have tried:

class saveme(object):
    def __init__(self, klass):
        print "saveme::__init__()"
        self._klass = klass

    def __call__(self, *args, **kwargs):
        print "saveme::__call__()"
        obj = self._klass(*args, **kwargs)
        # creation of DB record will happen here!
        # i.e. something like add_to_db(kwargs.get("id"))
        return obj

    def __del__(self):
        # deletion of DB record will happen here!
        # i.e. something like remove_from_db(id)
        # TODO: how to retrieve the "id" here?!
        print "saveme::__del__()"


class Parent1(object):
    def __init__(self):
        print "Parent1:: __init__()"
        super(Parent1, self).__init__()


class Parent2(object):
    def __init__(self):
        print "Parent2:: __init__()"
        super(Parent2, self).__init__()


@saveme
class A(Parent1, Parent2):
    def __init__(self, id):
        print "A::__init__()"
        self.id = id
        #super(A, self).__init__()


#@saveme
#class B(object):
#    def __init__(self, id):
#        print "B::__init__()"
#        self.id = id


def main():
    a1 = A(id="A1")
#    b1 = B(id="B1")

if __name__ == "__main__":
    main()


When executed the above, I ran in to the following:

saveme::__init__()
saveme::__call__()
A::__init__()
Traceback (most recent call last):
  File "1.py", line 54, in <module>
    main()
  File "1.py", line 50, in main
    a1 = A(id="A1")
  File "1.py", line 10, in __call__
    obj = self._klass(*args, **kwargs)
  File "1.py", line 39, in __init__
    super(A, self).__init__()
TypeError: must be type, not saveme
saveme::__del__()


When I commented "super(A, self).__init__()" in the class A :: __init__()
method, it returned an object of type A and I was able to see the prints in
the __call__ and __del__ methods but the __init__() methods of the base
classes (Parent1 & Parent2) were not called!

>From the error message, what I could understand is - the object returned by
saveme::__call__() is not of type A but of type saveme. But when I put a
print in the saveme::__call__() I could see it returns an object of type A
and not saveme.

Now the question is - with this approach to capture the initiation and
deletion events of an object, how do I initialise the base classes using
super()?

Or, is there any other better way to capture the __call__ and __del__
 events for an object of a certain class - if so, how?!

Thank you,

Sangeeth


PS:
http://stackoverflow.com/questions/21826854/typeerror-when-using-super-method-with-class-decorator-for-a-derived-class
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chennaipy/attachments/20140225/116c3533/attachment.html>

From aleax at google.com  Tue Feb 25 03:24:52 2014
From: aleax at google.com (Alex Martelli)
Date: Mon, 24 Feb 2014 18:24:52 -0800
Subject: [Chennaipy] [Baypiggies] Class decorator to capture the
 creation and deletion of objects
In-Reply-To: <CAPbKEUp_OS_PukUz2KObOSLQzjwGehPOfG4C-3Gq9qq=RaASgQ@mail.gmail.com>
References: <CAPbKEUp_OS_PukUz2KObOSLQzjwGehPOfG4C-3Gq9qq=RaASgQ@mail.gmail.com>
Message-ID: <CAE46Be9Ght7zj3rk=40=fKNmASq_1ER96Xp4PaPXLuiyMmbD1A@mail.gmail.com>

Off the cuff, I'd make saveme into a function, not a class;
the saveme function would alter the class passed in as its only argument
(saving __init__ and/or __del__ methods it may have and replacing them with
other -- nested -- functions that call them and do the rest of the job) and
return the same class object it received.

No time to actually write the code but this seems a much sounder
architecture.


Alex



On Mon, Feb 24, 2014 at 4:49 PM, Sangeeth Saravanaraj <
sangeeth.saravanaraj at gmail.com> wrote:

> This question was initially asked in tutor at python.org; Now I am widening
> the audience to gain attention.
>
> I want to create a decorator which should do the following things:
>  => When an object of the decorated class is created, the objects name
> (say the value of the incoming "id" argument) should be stored as a record
> in a table in a database.
>  => When an object of the decorated class is deleted, the record with this
> deleted objects name (i.e. object.id) should be removed from the table.
>
> Now, for example - consider the following snippet:
>
> @saveme
> class A(object):
>     def __init__(self, id):
>         self.id = id
>
> @saveme
> class B(object):
>     def __init__(self, id):
>         self.id = id
>
> "saveme" should do what I have explained earlier.
>
> a1 = A("A1")
> a2 = A("A2")
> a3 = A("A3")
> b1 = B("B1")
> b2 = B("B2")
>
> At this point if I query and print all the records in a table, I should
> get the following output:
> ["A1", "A2", "A3", "B1", "B2"]
>
> del a1
> del a2
> del a3
> del b1
> del b2
>
> At this point, all entries in the table should be deleted; query should
> return an empty list!
>
> And, I want to highlight that the classes that are being decorated with
> "saveme" can de derived classes too [which initialises its base classes
> using super() method]!
>
> Now the following is what I have tried:
>
> class saveme(object):
>     def __init__(self, klass):
>         print "saveme::__init__()"
>         self._klass = klass
>
>     def __call__(self, *args, **kwargs):
>         print "saveme::__call__()"
>         obj = self._klass(*args, **kwargs)
>         # creation of DB record will happen here!
>         # i.e. something like add_to_db(kwargs.get("id"))
>         return obj
>
>     def __del__(self):
>         # deletion of DB record will happen here!
>         # i.e. something like remove_from_db(id)
>         # TODO: how to retrieve the "id" here?!
>         print "saveme::__del__()"
>
>
> class Parent1(object):
>     def __init__(self):
>         print "Parent1:: __init__()"
>         super(Parent1, self).__init__()
>
>
> class Parent2(object):
>     def __init__(self):
>         print "Parent2:: __init__()"
>         super(Parent2, self).__init__()
>
>
> @saveme
> class A(Parent1, Parent2):
>     def __init__(self, id):
>         print "A::__init__()"
>         self.id = id
>         #super(A, self).__init__()
>
>
> #@saveme
> #class B(object):
> #    def __init__(self, id):
> #        print "B::__init__()"
> #        self.id = id
>
>
> def main():
>     a1 = A(id="A1")
> #    b1 = B(id="B1")
>
> if __name__ == "__main__":
>     main()
>
>
> When executed the above, I ran in to the following:
>
> saveme::__init__()
> saveme::__call__()
> A::__init__()
> Traceback (most recent call last):
>   File "1.py", line 54, in <module>
>     main()
>   File "1.py", line 50, in main
>     a1 = A(id="A1")
>   File "1.py", line 10, in __call__
>     obj = self._klass(*args, **kwargs)
>   File "1.py", line 39, in __init__
>     super(A, self).__init__()
> TypeError: must be type, not saveme
> saveme::__del__()
>
>
> When I commented "super(A, self).__init__()" in the class A :: __init__()
> method, it returned an object of type A and I was able to see the prints in
> the __call__ and __del__ methods but the __init__() methods of the base
> classes (Parent1 & Parent2) were not called!
>
> From the error message, what I could understand is - the object returned
> by saveme::__call__() is not of type A but of type saveme. But when I put a
> print in the saveme::__call__() I could see it returns an object of type A
> and not saveme.
>
> Now the question is - with this approach to capture the initiation and
> deletion events of an object, how do I initialise the base classes using
> super()?
>
> Or, is there any other better way to capture the __call__ and __del__
>  events for an object of a certain class - if so, how?!
>
> Thank you,
>
> Sangeeth
>
>
> PS:
> http://stackoverflow.com/questions/21826854/typeerror-when-using-super-method-with-class-decorator-for-a-derived-class
>
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> https://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chennaipy/attachments/20140224/d3d37c76/attachment-0001.html>

From david at bitcasa.com  Tue Feb 25 04:46:07 2014
From: david at bitcasa.com (David Lawrence)
Date: Mon, 24 Feb 2014 19:46:07 -0800
Subject: [Chennaipy] [Baypiggies] Class decorator to capture the
 creation and deletion of objects
In-Reply-To: <CAE46Be9Ght7zj3rk=40=fKNmASq_1ER96Xp4PaPXLuiyMmbD1A@mail.gmail.com>
References: <CAPbKEUp_OS_PukUz2KObOSLQzjwGehPOfG4C-3Gq9qq=RaASgQ@mail.gmail.com>
 <CAE46Be9Ght7zj3rk=40=fKNmASq_1ER96Xp4PaPXLuiyMmbD1A@mail.gmail.com>
Message-ID: <CAHGToM+kWkqCVsK-UkL5MBMjdh6h9CAiz69r+KDsDm5D491-EQ@mail.gmail.com>

If as according to the docs, there is no guarantee of __del__ being called,
anything that relies on that seems unsafe (depending on how robust one
needs the solutions to be).  Solutions I've seen elsewhere suggest creating
something like a *release()* method on your objects and calling it
explicitly before calling *del my_obj *(if you even call del, rather than
just relying on GC).

Alternatively, if it suits the scenario, use a context manager.

All suggestions lifted from (a SO that informed me in the past):
http://stackoverflow.com/questions/6104535/i-dont-understand-this-python-del-behaviour


On Mon, Feb 24, 2014 at 6:24 PM, Alex Martelli <aleax at google.com> wrote:

> Off the cuff, I'd make saveme into a function, not a class;
> the saveme function would alter the class passed in as its only argument
> (saving __init__ and/or __del__ methods it may have and replacing them with
> other -- nested -- functions that call them and do the rest of the job) and
> return the same class object it received.
>
> No time to actually write the code but this seems a much sounder
> architecture.
>
>
> Alex
>
>
>
> On Mon, Feb 24, 2014 at 4:49 PM, Sangeeth Saravanaraj <
> sangeeth.saravanaraj at gmail.com> wrote:
>
>> This question was initially asked in tutor at python.org; Now I am widening
>> the audience to gain attention.
>>
>> I want to create a decorator which should do the following things:
>>  => When an object of the decorated class is created, the objects name
>> (say the value of the incoming "id" argument) should be stored as a record
>> in a table in a database.
>>  => When an object of the decorated class is deleted, the record with
>> this deleted objects name (i.e. object.id) should be removed from the
>> table.
>>
>> Now, for example - consider the following snippet:
>>
>> @saveme
>> class A(object):
>>     def __init__(self, id):
>>         self.id = id
>>
>> @saveme
>> class B(object):
>>     def __init__(self, id):
>>         self.id = id
>>
>> "saveme" should do what I have explained earlier.
>>
>> a1 = A("A1")
>> a2 = A("A2")
>> a3 = A("A3")
>> b1 = B("B1")
>> b2 = B("B2")
>>
>> At this point if I query and print all the records in a table, I should
>> get the following output:
>> ["A1", "A2", "A3", "B1", "B2"]
>>
>> del a1
>> del a2
>> del a3
>> del b1
>> del b2
>>
>> At this point, all entries in the table should be deleted; query should
>> return an empty list!
>>
>> And, I want to highlight that the classes that are being decorated with
>> "saveme" can de derived classes too [which initialises its base classes
>> using super() method]!
>>
>> Now the following is what I have tried:
>>
>> class saveme(object):
>>     def __init__(self, klass):
>>         print "saveme::__init__()"
>>         self._klass = klass
>>
>>     def __call__(self, *args, **kwargs):
>>         print "saveme::__call__()"
>>         obj = self._klass(*args, **kwargs)
>>         # creation of DB record will happen here!
>>         # i.e. something like add_to_db(kwargs.get("id"))
>>         return obj
>>
>>     def __del__(self):
>>         # deletion of DB record will happen here!
>>         # i.e. something like remove_from_db(id)
>>         # TODO: how to retrieve the "id" here?!
>>         print "saveme::__del__()"
>>
>>
>> class Parent1(object):
>>     def __init__(self):
>>         print "Parent1:: __init__()"
>>         super(Parent1, self).__init__()
>>
>>
>> class Parent2(object):
>>     def __init__(self):
>>         print "Parent2:: __init__()"
>>         super(Parent2, self).__init__()
>>
>>
>> @saveme
>> class A(Parent1, Parent2):
>>     def __init__(self, id):
>>         print "A::__init__()"
>>         self.id = id
>>         #super(A, self).__init__()
>>
>>
>> #@saveme
>> #class B(object):
>> #    def __init__(self, id):
>> #        print "B::__init__()"
>> #        self.id = id
>>
>>
>> def main():
>>     a1 = A(id="A1")
>> #    b1 = B(id="B1")
>>
>> if __name__ == "__main__":
>>     main()
>>
>>
>> When executed the above, I ran in to the following:
>>
>> saveme::__init__()
>> saveme::__call__()
>> A::__init__()
>> Traceback (most recent call last):
>>   File "1.py", line 54, in <module>
>>     main()
>>   File "1.py", line 50, in main
>>     a1 = A(id="A1")
>>   File "1.py", line 10, in __call__
>>     obj = self._klass(*args, **kwargs)
>>   File "1.py", line 39, in __init__
>>     super(A, self).__init__()
>> TypeError: must be type, not saveme
>> saveme::__del__()
>>
>>
>> When I commented "super(A, self).__init__()" in the class A :: __init__()
>> method, it returned an object of type A and I was able to see the prints in
>> the __call__ and __del__ methods but the __init__() methods of the base
>> classes (Parent1 & Parent2) were not called!
>>
>> From the error message, what I could understand is - the object returned
>> by saveme::__call__() is not of type A but of type saveme. But when I put a
>> print in the saveme::__call__() I could see it returns an object of type A
>> and not saveme.
>>
>> Now the question is - with this approach to capture the initiation and
>> deletion events of an object, how do I initialise the base classes using
>> super()?
>>
>> Or, is there any other better way to capture the __call__ and __del__
>>  events for an object of a certain class - if so, how?!
>>
>> Thank you,
>>
>> Sangeeth
>>
>>
>> PS:
>> http://stackoverflow.com/questions/21826854/typeerror-when-using-super-method-with-class-decorator-for-a-derived-class
>>
>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> https://mail.python.org/mailman/listinfo/baypiggies
>>
>
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> https://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chennaipy/attachments/20140224/c8eef07d/attachment-0001.html>

From shakefu at gmail.com  Tue Feb 25 05:55:32 2014
From: shakefu at gmail.com (Jacob Alheid)
Date: Mon, 24 Feb 2014 20:55:32 -0800 (PST)
Subject: [Chennaipy] [Baypiggies] Class decorator to capture the
 creation and deletion of objects
In-Reply-To: <CAHGToM+kWkqCVsK-UkL5MBMjdh6h9CAiz69r+KDsDm5D491-EQ@mail.gmail.com>
References: <CAHGToM+kWkqCVsK-UkL5MBMjdh6h9CAiz69r+KDsDm5D491-EQ@mail.gmail.com>
Message-ID: <1393304131851.7914595c@Nodemailer>

?
Sent from Mailbox for iPad

On Mon, Feb 24, 2014 at 8:49 PM, David Lawrence <david at bitcasa.com> wrote:

> If as according to the docs, there is no guarantee of __del__ being called,
> anything that relies on that seems unsafe (depending on how robust one
> needs the solutions to be).  Solutions I've seen elsewhere suggest creating
> something like a *release()* method on your objects and calling it
> explicitly before calling *del my_obj *(if you even call del, rather than
> just relying on GC).
> Alternatively, if it suits the scenario, use a context manager.
> All suggestions lifted from (a SO that informed me in the past):
> http://stackoverflow.com/questions/6104535/i-dont-understand-this-python-del-behaviour
> On Mon, Feb 24, 2014 at 6:24 PM, Alex Martelli <aleax at google.com> wrote:
>> Off the cuff, I'd make saveme into a function, not a class;
>> the saveme function would alter the class passed in as its only argument
>> (saving __init__ and/or __del__ methods it may have and replacing them with
>> other -- nested -- functions that call them and do the rest of the job) and
>> return the same class object it received.
>>
>> No time to actually write the code but this seems a much sounder
>> architecture.
>>
>>
>> Alex
>>
>>
>>
>> On Mon, Feb 24, 2014 at 4:49 PM, Sangeeth Saravanaraj <
>> sangeeth.saravanaraj at gmail.com> wrote:
>>
>>> This question was initially asked in tutor at python.org; Now I am widening
>>> the audience to gain attention.
>>>
>>> I want to create a decorator which should do the following things:
>>>  => When an object of the decorated class is created, the objects name
>>> (say the value of the incoming "id" argument) should be stored as a record
>>> in a table in a database.
>>>  => When an object of the decorated class is deleted, the record with
>>> this deleted objects name (i.e. object.id) should be removed from the
>>> table.
>>>
>>> Now, for example - consider the following snippet:
>>>
>>> @saveme
>>> class A(object):
>>>     def __init__(self, id):
>>>         self.id = id
>>>
>>> @saveme
>>> class B(object):
>>>     def __init__(self, id):
>>>         self.id = id
>>>
>>> "saveme" should do what I have explained earlier.
>>>
>>> a1 = A("A1")
>>> a2 = A("A2")
>>> a3 = A("A3")
>>> b1 = B("B1")
>>> b2 = B("B2")
>>>
>>> At this point if I query and print all the records in a table, I should
>>> get the following output:
>>> ["A1", "A2", "A3", "B1", "B2"]
>>>
>>> del a1
>>> del a2
>>> del a3
>>> del b1
>>> del b2
>>>
>>> At this point, all entries in the table should be deleted; query should
>>> return an empty list!
>>>
>>> And, I want to highlight that the classes that are being decorated with
>>> "saveme" can de derived classes too [which initialises its base classes
>>> using super() method]!
>>>
>>> Now the following is what I have tried:
>>>
>>> class saveme(object):
>>>     def __init__(self, klass):
>>>         print "saveme::__init__()"
>>>         self._klass = klass
>>>
>>>     def __call__(self, *args, **kwargs):
>>>         print "saveme::__call__()"
>>>         obj = self._klass(*args, **kwargs)
>>>         # creation of DB record will happen here!
>>>         # i.e. something like add_to_db(kwargs.get("id"))
>>>         return obj
>>>
>>>     def __del__(self):
>>>         # deletion of DB record will happen here!
>>>         # i.e. something like remove_from_db(id)
>>>         # TODO: how to retrieve the "id" here?!
>>>         print "saveme::__del__()"
>>>
>>>
>>> class Parent1(object):
>>>     def __init__(self):
>>>         print "Parent1:: __init__()"
>>>         super(Parent1, self).__init__()
>>>
>>>
>>> class Parent2(object):
>>>     def __init__(self):
>>>         print "Parent2:: __init__()"
>>>         super(Parent2, self).__init__()
>>>
>>>
>>> @saveme
>>> class A(Parent1, Parent2):
>>>     def __init__(self, id):
>>>         print "A::__init__()"
>>>         self.id = id
>>>         #super(A, self).__init__()
>>>
>>>
>>> #@saveme
>>> #class B(object):
>>> #    def __init__(self, id):
>>> #        print "B::__init__()"
>>> #        self.id = id
>>>
>>>
>>> def main():
>>>     a1 = A(id="A1")
>>> #    b1 = B(id="B1")
>>>
>>> if __name__ == "__main__":
>>>     main()
>>>
>>>
>>> When executed the above, I ran in to the following:
>>>
>>> saveme::__init__()
>>> saveme::__call__()
>>> A::__init__()
>>> Traceback (most recent call last):
>>>   File "1.py", line 54, in <module>
>>>     main()
>>>   File "1.py", line 50, in main
>>>     a1 = A(id="A1")
>>>   File "1.py", line 10, in __call__
>>>     obj = self._klass(*args, **kwargs)
>>>   File "1.py", line 39, in __init__
>>>     super(A, self).__init__()
>>> TypeError: must be type, not saveme
>>> saveme::__del__()
>>>
>>>
>>> When I commented "super(A, self).__init__()" in the class A :: __init__()
>>> method, it returned an object of type A and I was able to see the prints in
>>> the __call__ and __del__ methods but the __init__() methods of the base
>>> classes (Parent1 & Parent2) were not called!
>>>
>>> From the error message, what I could understand is - the object returned
>>> by saveme::__call__() is not of type A but of type saveme. But when I put a
>>> print in the saveme::__call__() I could see it returns an object of type A
>>> and not saveme.
>>>
>>> Now the question is - with this approach to capture the initiation and
>>> deletion events of an object, how do I initialise the base classes using
>>> super()?
>>>
>>> Or, is there any other better way to capture the __call__ and __del__
>>>  events for an object of a certain class - if so, how?!
>>>
>>> Thank you,
>>>
>>> Sangeeth
>>>
>>>
>>> PS:
>>> http://stackoverflow.com/questions/21826854/typeerror-when-using-super-method-with-class-decorator-for-a-derived-class
>>>
>>>
>>> _______________________________________________
>>> Baypiggies mailing list
>>> Baypiggies at python.org
>>> To change your subscription options or unsubscribe:
>>> https://mail.python.org/mailman/listinfo/baypiggies
>>>
>>
>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> https://mail.python.org/mailman/listinfo/baypiggies
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chennaipy/attachments/20140224/f1144d12/attachment-0001.html>

From aleax at google.com  Tue Feb 25 18:44:08 2014
From: aleax at google.com (Alex Martelli)
Date: Tue, 25 Feb 2014 09:44:08 -0800
Subject: [Chennaipy] [Baypiggies] Class decorator to capture the
 creation and deletion of objects
In-Reply-To: <CAHGToM+kWkqCVsK-UkL5MBMjdh6h9CAiz69r+KDsDm5D491-EQ@mail.gmail.com>
References: <CAPbKEUp_OS_PukUz2KObOSLQzjwGehPOfG4C-3Gq9qq=RaASgQ@mail.gmail.com>
 <CAE46Be9Ght7zj3rk=40=fKNmASq_1ER96Xp4PaPXLuiyMmbD1A@mail.gmail.com>
 <CAHGToM+kWkqCVsK-UkL5MBMjdh6h9CAiz69r+KDsDm5D491-EQ@mail.gmail.com>
Message-ID: <CAE46Be8=evUSP3RDXPstcPqr6QR2muKdU1RuvLP5k28R7z0q+w@mail.gmail.com>

The best way to avoid relying on __del__ in this particular case may be to
hold, rather than a plain list of the IDs, a list of weak references to
instances.  When the "list of IDs" is asked for, it goes through a property
that cleans up those weak refs that correspond to now-disappeared
instances, before returning the requested list of IDs.  Now __del__ can
usefully be removed (as its existence may interfere with GC of cyclical
garbage), yet the list of IDs is guaranteed to return the list of
still-existing instances' IDs, no matter what constructs or idioms have
been used to create and remove instances.

This avoid relying on creators/destroyers of instances properly calling
release and/or using the appropriate context manager; such reliance is
sometimes inevitable, but for this particular spec it does not appear to
be, thus, it might best be avoided.


Alex



On Mon, Feb 24, 2014 at 7:46 PM, David Lawrence <david at bitcasa.com> wrote:

> If as according to the docs, there is no guarantee of __del__ being
> called, anything that relies on that seems unsafe (depending on how robust
> one needs the solutions to be).  Solutions I've seen elsewhere suggest
> creating something like a *release()* method on your objects and calling
> it explicitly before calling *del my_obj *(if you even call del, rather
> than just relying on GC).
>
> Alternatively, if it suits the scenario, use a context manager.
>
> All suggestions lifted from (a SO that informed me in the past):
> http://stackoverflow.com/questions/6104535/i-dont-understand-this-python-del-behaviour
>
>
> On Mon, Feb 24, 2014 at 6:24 PM, Alex Martelli <aleax at google.com> wrote:
>
>> Off the cuff, I'd make saveme into a function, not a class;
>> the saveme function would alter the class passed in as its only argument
>> (saving __init__ and/or __del__ methods it may have and replacing them with
>> other -- nested -- functions that call them and do the rest of the job) and
>> return the same class object it received.
>>
>> No time to actually write the code but this seems a much sounder
>> architecture.
>>
>>
>> Alex
>>
>>
>>
>>  On Mon, Feb 24, 2014 at 4:49 PM, Sangeeth Saravanaraj <
>> sangeeth.saravanaraj at gmail.com> wrote:
>>
>>>  This question was initially asked in tutor at python.org; Now I am
>>> widening the audience to gain attention.
>>>
>>> I want to create a decorator which should do the following things:
>>>  => When an object of the decorated class is created, the objects name
>>> (say the value of the incoming "id" argument) should be stored as a record
>>> in a table in a database.
>>>  => When an object of the decorated class is deleted, the record with
>>> this deleted objects name (i.e. object.id) should be removed from the
>>> table.
>>>
>>> Now, for example - consider the following snippet:
>>>
>>> @saveme
>>> class A(object):
>>>     def __init__(self, id):
>>>         self.id = id
>>>
>>> @saveme
>>> class B(object):
>>>     def __init__(self, id):
>>>         self.id = id
>>>
>>> "saveme" should do what I have explained earlier.
>>>
>>> a1 = A("A1")
>>> a2 = A("A2")
>>> a3 = A("A3")
>>> b1 = B("B1")
>>> b2 = B("B2")
>>>
>>> At this point if I query and print all the records in a table, I should
>>> get the following output:
>>> ["A1", "A2", "A3", "B1", "B2"]
>>>
>>> del a1
>>> del a2
>>> del a3
>>> del b1
>>> del b2
>>>
>>> At this point, all entries in the table should be deleted; query should
>>> return an empty list!
>>>
>>> And, I want to highlight that the classes that are being decorated with
>>> "saveme" can de derived classes too [which initialises its base classes
>>> using super() method]!
>>>
>>> Now the following is what I have tried:
>>>
>>> class saveme(object):
>>>     def __init__(self, klass):
>>>         print "saveme::__init__()"
>>>         self._klass = klass
>>>
>>>     def __call__(self, *args, **kwargs):
>>>         print "saveme::__call__()"
>>>         obj = self._klass(*args, **kwargs)
>>>         # creation of DB record will happen here!
>>>         # i.e. something like add_to_db(kwargs.get("id"))
>>>         return obj
>>>
>>>     def __del__(self):
>>>         # deletion of DB record will happen here!
>>>         # i.e. something like remove_from_db(id)
>>>         # TODO: how to retrieve the "id" here?!
>>>         print "saveme::__del__()"
>>>
>>>
>>> class Parent1(object):
>>>     def __init__(self):
>>>         print "Parent1:: __init__()"
>>>         super(Parent1, self).__init__()
>>>
>>>
>>> class Parent2(object):
>>>     def __init__(self):
>>>         print "Parent2:: __init__()"
>>>         super(Parent2, self).__init__()
>>>
>>>
>>> @saveme
>>> class A(Parent1, Parent2):
>>>     def __init__(self, id):
>>>         print "A::__init__()"
>>>         self.id = id
>>>         #super(A, self).__init__()
>>>
>>>
>>> #@saveme
>>> #class B(object):
>>> #    def __init__(self, id):
>>> #        print "B::__init__()"
>>> #        self.id = id
>>>
>>>
>>> def main():
>>>     a1 = A(id="A1")
>>> #    b1 = B(id="B1")
>>>
>>> if __name__ == "__main__":
>>>     main()
>>>
>>>
>>> When executed the above, I ran in to the following:
>>>
>>> saveme::__init__()
>>> saveme::__call__()
>>> A::__init__()
>>> Traceback (most recent call last):
>>>   File "1.py", line 54, in <module>
>>>     main()
>>>   File "1.py", line 50, in main
>>>     a1 = A(id="A1")
>>>   File "1.py", line 10, in __call__
>>>     obj = self._klass(*args, **kwargs)
>>>   File "1.py", line 39, in __init__
>>>     super(A, self).__init__()
>>> TypeError: must be type, not saveme
>>> saveme::__del__()
>>>
>>>
>>> When I commented "super(A, self).__init__()" in the class A ::
>>> __init__() method, it returned an object of type A and I was able to see
>>> the prints in the __call__ and __del__ methods but the __init__() methods
>>> of the base classes (Parent1 & Parent2) were not called!
>>>
>>> From the error message, what I could understand is - the object returned
>>> by saveme::__call__() is not of type A but of type saveme. But when I put a
>>> print in the saveme::__call__() I could see it returns an object of type A
>>> and not saveme.
>>>
>>> Now the question is - with this approach to capture the initiation and
>>> deletion events of an object, how do I initialise the base classes using
>>> super()?
>>>
>>> Or, is there any other better way to capture the __call__ and __del__
>>>  events for an object of a certain class - if so, how?!
>>>
>>> Thank you,
>>>
>>> Sangeeth
>>>
>>>
>>> PS:
>>> http://stackoverflow.com/questions/21826854/typeerror-when-using-super-method-with-class-decorator-for-a-derived-class
>>>
>>>
>>> _______________________________________________
>>> Baypiggies mailing list
>>> Baypiggies at python.org
>>> To change your subscription options or unsubscribe:
>>> https://mail.python.org/mailman/listinfo/baypiggies
>>>
>>
>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> https://mail.python.org/mailman/listinfo/baypiggies
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chennaipy/attachments/20140225/7bc9e060/attachment.html>