Re: [BangPypers] Adding mixing at run-time

[venkatakrishnan g]

I think this is a very nice approach. I disagree that that you could
decorate a class as @Place.mixin by mistake,
In fact i think the decorator actually makes it absolutely clear its
purpose. However, the Place.mixin should return
the mixin class.

 @classmethod
def mixin(cls, mixin):
"""Decorator to add a mixin to the class runtime.
"""
cls.__bases__ = cls.__bases__ + (mixin,)

return mixin


This:

1. Allows the class to be mixed-in into other classes if there's need for it
2. Class decorators should return classes, else LinksMixin evaluates to None



On 9 October 2014 11:30, kracekumar ramaraju 
wrote:

> On Wed, Oct 8, 2014 at 4:19 PM, Anand Chitipothu 
> wrote:
>
> > Hi,
> >
> > I'm working on a slightly large application and I'm trying to model it
> as a
> > some kind of plugin architecture so that it modular and I can enable or
> > take out features without lot of code changes.
> >
> > One of the issues I faced was that the wanted to add some methods to a
> > class only when a feature/plugin is enabled.
> >
> > Here is a simplified version of what I have:
> >
> > class Place(Mixable):
> > def __init__(self, name):
> > self.name = name
> >
> > def get_users(self):
> > return "users-of-{}".format(self.name)
> >
> > def get_links(self):
> > return "links-of-{}".format(self.name)
> >
> > There are couple of issues with this.
> >
> > 1. The logic for computing users or links doesn't really belong to this
> > file. I wanted to that in a separate module for modularity.
> >
> > 2. The Place class will become too large to manage over time.
> >
> > So, I came up with the following approach to address these issues.
> >
> > # place.py
> >
> > class Mixable(object):
> > """Magic class to allow adding mixins to the class at run-time.
> > """
> > @classmethod
> > def mixin(cls, mixin):
> > """Decorator to add a mixin to the class runtime.
> > """
> > cls.__bases__ = cls.__bases__ + (mixin,)
> >
> > class Place(Mixable):
> > def __init__(self, name):
> > self.name = name
> >
> > # users.py
> > @Place.mixin
> > class UsersMixin(object):
> > def get_users(self):
> > return "users-of-{}".format(self.name)
> >
> >
> Is there any specific reason for using decorators ?
>
>
>
> > # links.py
> > @Place.mixin
> > class LinksMixin(object):
> > def get_links(self):
> > return "links-of-{}".format(self.name)
> >
> > p = Place('bangalore')
> > print(p.get_users())
> > print(p.get_links())
> >
> >
>
> I somehow feel this can lead to unexpected behaviour since Mixable classes
> are added at various files.
> This pattern looks like global variable argument (global variables are
> bad). Say if Idecorate Foo with @Place.mixin by mistake, behaviour of the
> Foo will be available in Place class and leads to side effect.
>
> How about
>
> #dispatcher.py
> # import all the classes
>
> def get_place_class():
>   # Check for features
>   for cls in classes:
>Place.__bases__ = Place.__bases__ + (cls,)
>   return Place
>
>
>
> > With this I was able to split the class into 3 files and now I have
> > flexibility of deciding which features enable from a config file.
> >
> > What do you guys think of this approach?
> >
>
> My only concern base classes are added in different files and difficult to
> remember.
>
> Is this a good practice?
> > Are there any know flaws in this approach?
>
> How did you solve that issue when you faced similar situation?
> >
> >
> Did I understand the problem correctly ?
>
>
> > Anand
> > ___
> > BangPypers mailing list
> > BangPypers@python.org
> > https://mail.python.org/mailman/listinfo/bangpypers
> >
>
>
>
> --
>
> *Thanks & Regardskracekumar"Talk is cheap, show me the code" -- Linus
> Torvaldshttp://kracekumar.com *
> ___
> BangPypers mailing list
> BangPypers@python.org
> https://mail.python.org/mailman/listinfo/bangpypers
>
___
BangPypers mailing list
BangPypers@python.org
https://mail.python.org/mailman/listinfo/bangpypers

Re: [BangPypers] Python packages and modules (was: Favorite tips/techniques)

[venkatakrishnan g]

Oh, dexterous just blew my head! I'll stick it back together and run
through this again.


On 13 September 2013 15:58, Saager Mhatre  wrote:

> On Fri, Sep 13, 2013 at 1:10 PM, Saju M  wrote:
>
> > Saager,
> >
> > As per python module-import semantics, sub-modules don't end up as names
> > in the
> > package-module[*] unless explicitly added.
> >
> > I didn't get it, what you mean by package-module[*] ?.
> >
>
> Ah, there it is... the sound of your head exploding! :P
>
> Buckle up, this is going to be a fast, but rough ride!
>
> Basically...
> 
> * A module is a dict-like object that binds names to values.
> * A package is a namespace that can contain (only) other modules (which
> could, in turn, be package-modules themselves).
> * A package-module[1] would be a module that also serves as a package.
>
> I guess it'd be easier to explain with with an example.
>
> Semantically...
> ---
> * Lets stick to json.tool. In this case, json is a module and tool is a
> sub-module of the json module.
> * They are both modules in that each can contain bindings to names =>
> json.dump and tool.main.
> * But, json is also a package in that it contains the tool module =>
> json.tool
> * The sub-module relationship is mostly evident from the fact that the tool
> module is referenced by prefixing 'json.' to it => import json.tool;
> * Or providing 'json' as the package to look for the module => from json
> import tool
>
> Physically...
> ---
> * Any .py file can be loaded as a module.
> * Any directory with an __init__.py file can be treated as a package.
> * The __init__.py file itself serves as the package-module, i.e., the
> module with same name as the package
> * Any .py files inside the directory (except __init__.py, of course) can be
> loaded as sub-modules of the above package.
> * Any sub-directories inside the directory (containing __init__.py, of
> course) can be loaded as sub-packages of the above package.
> * Turtles all the way...
>
> Funda-mentally...
> ---
> * The confusion basically stems from the fact that Python chose to conflate
> physical storage and namespacing with just enough overlap to be
> inconsistent.
> * They are conflated in that package/module naming and their lookup
> (finding the code for a module) is tied to the physical storage hierarchy.
> * They are inconsistent that module loading is transitive only upwards in
> the hierarchy, i.e., when you load a module, all packages above it in the
> hierarchy are automatically loaded.[2]
> * However, sub-modules are not loaded even though the physical hierarchy
> evidences it.
> * The conflation extends further as we look as modules as namespaces,
> because sub-modules do not end up as names in package-modules until they
> are loaded; see below
> Python 2.7.4 (default, Apr 19 2013, 18:28:01)
> [GCC 4.7.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> *>>> json*
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'json' is not defined
> *>>> import json*
> *>>> json*
> 
> *>>> json.tool*
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'module' object has no attribute 'tool'
> *>>> from json import tool*
> *>>> json*
> 
> *>>> tool*
> 
> *>>> json.tool*
> 
> *>>> *
>
> Finally...
> ---
> On a closing note, it goes without saying that these packages are not to be
> confused with packages as published on package indexes such as
> https://pypi.python.org.[3]
>
> (steps behind transparent blast shield to calmly enjoy the sight of more
> exploding heads)
> - d
>
> [1] I don't believe it would be entirely in the best interest of either of
> our healths to use this term outside of this thread!
> [2] IIRC, this was not true for python <2.5 (I think); I recall hitting
> some really weird import errors when running newer code on a really old
> interpreter when it suddenly couldn't reference the packages that a loaded
> module belonged to until they were explicitly loaded.
> [3] To those in the know, I would be tremendously obliged if you could tell
> me what brand of blow they were using when they came up with this
> byzantine, labyrinthine nomenclature and related implementation. I bet it
> was, as they say, "like, totally radical dude!"
> ___
> BangPypers mailing list
> BangPypers@python.org
> https://mail.python.org/mailman/listinfo/bangpypers
>
___
BangPypers mailing list
BangPypers@python.org
https://mail.python.org/mailman/listinfo/bangpypers

Re: [BangPypers] How to run a block of code just before the interpreter is being exited like END{} in perl ??

[venkatakrishnan g]

import atexit

def callback():
  print "about to exit!"

atexit.register( callback )


On 2 September 2013 20:00, babmis  wrote:

>
> __**_
> BangPypers mailing list
> BangPypers@python.org
> http://mail.python.org/**mailman/listinfo/bangpypers
>
___
BangPypers mailing list
BangPypers@python.org
http://mail.python.org/mailman/listinfo/bangpypers

Re: [BangPypers] Announcing Bangalore::Hack 2013

[venkatakrishnan g]

while you're at it, read the last line too. The one you point out seems
perfectly reasonable. Not this last one.

"chief guest responsible for the invention of C/C++/Unix"


On 30 August 2013 12:15, ashish makani  wrote:

> reply inline below :
>
>
> On Fri, Aug 30, 2013 at 12:02 PM, L Radhakrishna Rao <
> satishsaga...@gmail.com> wrote:
>
> > Going by his profile, it appears that he is more towards business side, I
> >> don't know how come he is being claimed as the inventor of C/C++/UNIX.
> >
> >
> read, people read !
>
> from the email :
>
> Bill was Vice President of the Center that invented C / C++ / UNIX in Bell
> > Labs.
>
>
>
> cheers
> ashish
>
>
>
> >
> > On Fri, Aug 30, 2013 at 12:00 PM, venkatakrishnan g
> > wrote:
> >
> > > "responsible for the invention of C/C++/Unix" is a bit over the line,
> not
> > > entirely sure about "he proposed the idea"
> > >
> > >
> > > On 30 August 2013 10:42, L Radhakrishna Rao 
> > > wrote:
> > >
> > > > @aditya:
> > > >
> > > > It does not mean that he had done it manually or mechanically, he had
> > > > proposed the idea. :)
> > > >
> > > >
> > > > On Fri, Aug 30, 2013 at 10:14 AM, Aditya Laghate <
> > > adi...@thinrhino.net.in
> > > > >wrote:
> > > >
> > > > >
> > > > > On Fri, Aug 30, 2013 at 09:33:20AM +0530, Ashish Agrawal wrote:
> > > > > |
> > > > > |TL;DR; great mentors, chief guest responsible for the invention of
> > > > > C/C++/Unix.
> > > > >
> > > > > I read that line and decided to read the entire mail. I was
> wondering
> > > > > who was this one guy who invented all the three and had the
> patience
> > to
> > > > > work with Google, when they made (or shall I say 'invented')
> Chrome!!
> > > > >
> > > > > Bloody waste of time!
> > > > >
> > > > > Regards
> > > > > Aditya
> > > > > ___
> > > > > BangPypers mailing list
> > > > > BangPypers@python.org
> > > > > http://mail.python.org/mailman/listinfo/bangpypers
> > > > >
> > > > ___
> > > > BangPypers mailing list
> > > > BangPypers@python.org
> > > > http://mail.python.org/mailman/listinfo/bangpypers
> > > >
> > > ___
> > > BangPypers mailing list
> > > BangPypers@python.org
> > > http://mail.python.org/mailman/listinfo/bangpypers
> > >
> > ___
> > BangPypers mailing list
> > BangPypers@python.org
> > http://mail.python.org/mailman/listinfo/bangpypers
> >
>
>
>
>
> *The only way to do great work is to love what you do. If you haven’t found
> it yet, keep looking. Don’t settle. As with all matters of the heart,
> you’ll know when you find it.” - Steve Jobs (1955 - 2011)*
> ___
> BangPypers mailing list
> BangPypers@python.org
> http://mail.python.org/mailman/listinfo/bangpypers
>
___
BangPypers mailing list
BangPypers@python.org
http://mail.python.org/mailman/listinfo/bangpypers

Re: [BangPypers] Announcing Bangalore::Hack 2013

[venkatakrishnan g]

"responsible for the invention of C/C++/Unix" is a bit over the line, not
entirely sure about "he proposed the idea"


On 30 August 2013 10:42, L Radhakrishna Rao  wrote:

> @aditya:
>
> It does not mean that he had done it manually or mechanically, he had
> proposed the idea. :)
>
>
> On Fri, Aug 30, 2013 at 10:14 AM, Aditya Laghate  >wrote:
>
> >
> > On Fri, Aug 30, 2013 at 09:33:20AM +0530, Ashish Agrawal wrote:
> > |
> > |TL;DR; great mentors, chief guest responsible for the invention of
> > C/C++/Unix.
> >
> > I read that line and decided to read the entire mail. I was wondering
> > who was this one guy who invented all the three and had the patience to
> > work with Google, when they made (or shall I say 'invented') Chrome!!
> >
> > Bloody waste of time!
> >
> > Regards
> > Aditya
> > ___
> > BangPypers mailing list
> > BangPypers@python.org
> > http://mail.python.org/mailman/listinfo/bangpypers
> >
> ___
> BangPypers mailing list
> BangPypers@python.org
> http://mail.python.org/mailman/listinfo/bangpypers
>
___
BangPypers mailing list
BangPypers@python.org
http://mail.python.org/mailman/listinfo/bangpypers