CONSTRUCT - Module Attributes and Execution Environment
I would like to change the construct: if __name__ == '__main__': to something like: if exec.isMain(): My (OO thought) is to place a class in an separate code module and to instantiate an singleton instance which would keep th something like this: class ExecutionEnv: def isMain(self) if CALLING_MODULE.__name__ == '__main__': return true else return false exec = ExecutionEnv() How to I get access to the CALLING_MODULE ? - Are ther alternative constructs/mechanism available, which could be used to add this functionality possiby directly to a code-module? -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT - Module Attributes and Execution Environment
Fuzzyman wrote: > lazaridis_com wrote: > > I would like to change the construct: > > > > if __name__ == '__main__': > > > > to something like: > > > > if exec.isMain(): > > > > My (OO thought) is to place a class in an separate code module and to > > instantiate an singleton instance which would keep th something like > > this: > > > > class ExecutionEnv: > > def isMain(self) > > if CALLING_MODULE.__name__ == '__main__': > > return true > > else > > return false > > > > exec = ExecutionEnv() > > > > How to I get access to the CALLING_MODULE ? > > sys._getframe(1).f_globals['__name__'] very nice! This seems to do the work. Btw: I forgot to mention the use-case: http://case.lazaridis.com/browser/lang/python/talker.py?rev=44 > All the best, > > Fuzzyman > http://www.voidspace.org.uk/python/index.shtml -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT - Module Attributes and Execution Environment
Duncan Booth wrote: > lazaridis_com wrote: > > > Are ther alternative constructs/mechanism available, which could be > > used to add this functionality possiby directly to a code-module? > > How about something along these lines: > > -- auto.py - > import sys, atexit > > def main_body(f): > if f.func_globals['__name__']=='__main__': > atexit.register(f, sys.argv) > return f > > @main_body > def auto(args): > print "auto run", args > > > If you run auto.py as a script then the decorated function executes. If you > import it then the decorated function doesn't execute. In your own script > you just need an import statement and to put the decorator on your main > function. This construct looks very promising ! Are function decorators available in Ruby / Java / C++ ? -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT - Module Attributes and Execution Environment
Larry Bates wrote: > lazaridis_com wrote: > > I would like to change the construct: > > > > if __name__ == '__main__': > > > > to something like: > > > > if exec.isMain(): > > > > My (OO thought) is to place a class in an separate code module and to > > instantiate an singleton instance which would keep th something like > > this: > > > > class ExecutionEnv: > > def isMain(self) > > if CALLING_MODULE.__name__ == '__main__': > > return true > > else > > return false > > > > exec = ExecutionEnv() > > > > How to I get access to the CALLING_MODULE ? > > > > - > > > > Are ther alternative constructs/mechanism available, which could be > > used to add this functionality possiby directly to a code-module? > > > Two thoughts: > > 1) Don't call a class instance exec, it will mask the built-in > exec statement. ok, I understand. > 2) IMHO all the suggestions are way more complicated than > if __name__ == "__main__" and are not SOP for most pythoneers. > I know what the former construct means/does. I have to > decipher your class to figure our what the latter does and it > doesn't really save you any code or provide a performance > enhancement. "Clarity for Pythoneers" is not a main requirement of the project. The main requirements (The network of requirements is not yet fully documented): http://case.lazaridis.com/wiki/Code The related issue: http://case.lazaridis.com/ticket/5 > -Larry -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT - Module Attributes and Execution Environment
lazaridis_com wrote: > I would like to change the construct: > > if __name__ == '__main__': ... Is there a standard way / naming to wrap "__name__" and other similar attributes to an encapsulating class? Something like e.g.: if mod.name ... or if gbl.name ... - "gbl.newAttribute = value" would create __newAttribute__ This should become available whereever such occour. (I assume this should be implementable with e.g. metaclasses) -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLObject or SQLAlchemy?
John Salerno wrote: > Are there any major differences between these two? It seems they can > both be used with TurboGears, and SQLAlchemy with Django. I'm just > wondering what everyone's preference is, and why, and if there are even > more choices for ORM. > > Thanks. You can review the Persit Case, which will shortly evaluate the stated ORM's: http://case.lazaridis.com/wiki/Persist It is possibly of importance to remember some requirements which should be relevant for an persistency mechanism targetting an OO language: Requirements * Uses standard OO Terminology on the API side o free of SQL/Relational terminology for ORM Tools * Transparency (minimal or no difference to standard objects of the language) o Inheritance * Includes Automated Schema Evolution Support o Development Schema Evolution (focusing on simplicity and conveniency etc.) o Production Schema Evolution (focusing on integrity, stability etc.) * Support Standard ODBMS API's * Support of Standards within the language-domain (e.g. Python) -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLObject or SQLAlchemy?
Ο/Η Bruno Desthuilliers έγραψε: > lazaridis_com wrote: > > John Salerno wrote: > >> Are there any major differences between these two? It seems they can > >> both be used with TurboGears, and SQLAlchemy with Django. I'm just > >> wondering what everyone's preference is, and why, and if there are even > >> more choices for ORM. > >> > >> Thanks. > > > > You can review the Persit Case, which will shortly evaluate the stated > > ORM's: > > > > http://case.lazaridis.com/wiki/Persist > > > > It is possibly of importance to remember some requirements which should > > be relevant for an persistency mechanism targetting an OO language: > > RDBMS are not "persistency mechanism", they are data management tools. possibly. but this is not relevant, as the "Persist" case does not deal with RDBMS. -- http://mail.python.org/mailman/listinfo/python-list
CONSTRUCT -
I would like to fulfill the following task: The construct: if __name__ == '__main__': should be changed to something like: if identifier.name == '__main__': The term "identifier" should be selected based on the meaning of the __double-underscore-enclosure__ of the entities. - What I would need to know is: a) what would be the correct term for "identifier"? b) is there a standard way to implement such an access mechanism in an generic way? c) is there an advanced mechanism available, which would allow to implement a prefix (e.g. %name) - Context: http://case.lazaridis.com/wiki/Lang http://case.lazaridis.com/ticket/6 -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT -
Georg Brandl wrote: > lazaridis_com wrote: > > I would like to fulfill the following task: > > > > The construct: > > > > if __name__ == '__main__': > > > > should be changed to something like: > > > > if identifier.name == '__main__': > > > > The term "identifier" should be selected based on the meaning of the > > __double-underscore-enclosure__ of the entities. ... > import sys > class _identifier: > def __getattr__(self, name): > return sys._getframe(1).f_globals['__%s__' % name] > identifier = _identifier() ok, I understand. this one would work with modules. but how would look a more general solution, which would work with objects too? . -- http://lazaridis.com -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT - Module Attributes and Execution Environment
lazaridis_com wrote: > lazaridis_com wrote: > > I would like to change the construct: > > > > if __name__ == '__main__': > ... > > Is there a standard way / naming to wrap "__name__" and other similar > attributes to an encapsulating class? ... see follow-up thread: http://groups.google.com/group/comp.lang.python/browse_thread/thread/37905d66ae0e37c4 -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT -
Simon Forman wrote: > lazaridis_com wrote: > > I would like to fulfill the following task: > > > > The construct: > > > > if __name__ == '__main__': > > > > should be changed to something like: > > > > if identifier.name == '__main__': ... > > Context: > > http://case.lazaridis.com/wiki/Lang > > http://case.lazaridis.com/ticket/6 > > I'm sorry, you post makes very little sense. If all you want to do is > implement a less "ugly" verision of "if __name__ == '__main__':", a > quick search on google should turn up several ways. this happend already within another thread/ticket: http://case.lazaridis.com/changeset/45 this here is aboute the underscores in "__name__". - search engines are full of information, but when looking for standard constructs and ways to do something, I rely on feedback from domain experts. some search-engine hits: http://aspn.activestate.com/ASPN/Mail/Message/python-list/830424 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496930 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496920 -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT -
Georg Brandl wrote: > lazaridis_com wrote: > > Georg Brandl wrote: > >> lazaridis_com wrote: > >> > I would like to fulfill the following task: > >> > > >> > The construct: > >> > > >> > if __name__ == '__main__': > >> > > >> > should be changed to something like: > >> > > >> > if identifier.name == '__main__': > >> > > >> > The term "identifier" should be selected based on the meaning of the > >> > __double-underscore-enclosure__ of the entities. > > ... > > > >> import sys > >> class _identifier: > >> def __getattr__(self, name): > >> return sys._getframe(1).f_globals['__%s__' % name] > >> identifier = _identifier() > > > > ok, I understand. > > > > this one would work with modules. > > > > but how would look a more general solution, which would work with > > objects too? > > Why can't you try to come up with something yourself? You should have > had enough exposure to the Python language by now. > > Georg I am not a (python) domain expert. Thus I am asking here for available standard-solutions, before I implement an own solution. -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLObject or SQLAlchemy?
Bruno Desthuilliers wrote: > lazaridis_com wrote: > > Ο/Η Bruno Desthuilliers έγραψε: > >> lazaridis_com wrote: > >>> John Salerno wrote: > >>>> Are there any major differences between these two? It seems they can > >>>> both be used with TurboGears, and SQLAlchemy with Django. I'm just > >>>> wondering what everyone's preference is, and why, and if there are even > >>>> more choices for ORM. > >>>> > >>>> Thanks. > >>> You can review the Persit Case, which will shortly evaluate the stated > >>> ORM's: > >>> > >>> http://case.lazaridis.com/wiki/Persist > >>> > >>> It is possibly of importance to remember some requirements which should > >>> be relevant for an persistency mechanism targetting an OO language: > >> RDBMS are not "persistency mechanism", they are data management tools. > > > > possibly. > > > > but this is not relevant, as the "Persist" case does not deal with > > RDBMS. > > > Then your post is irrelevant since there's a clear indication that the > OP question was about RDBMS integration in Python (hint: SQLObject and > SQLAlchemy both start with 'SQL'). ... Of course it's relevant. "I'm just wondering what everyone's preference is, and why, and if there are even more choices for ORM." The "persist case" evaluates python persistency systems (or mechanisms), and will show my personal preference: "Object Oriented Persistency Systems (this includes OODBMS, Object-Relational-Mappers, and others)." http://case.lazaridis.com/wiki/Persist . -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLObject or SQLAlchemy?
alex23 wrote: > lazaridis_com wrote: > > The "persist case" evaluates python persistency systems (or > > mechanisms), and will show my personal preference: > > Do you feel that evaluating-for-evaluation's-sake produces a more > measured understanding of the value of a product than that taken from > its use in, say, actual development? I don't evaluate for "evaluating-for-evaluation's-sake", see the home page of the project: "The project selects Open Source Subsystems for integration into a Coherent Software Production System. " http://case.lazaridis.com/wiki . -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLObject or SQLAlchemy?
Bruno Desthuilliers wrote: > lazaridis_com wrote: > > Bruno Desthuilliers wrote: > >> lazaridis_com wrote: > >>> Ο/Η Bruno Desthuilliers έγραψε: > >>>> lazaridis_com wrote: > >>>>> John Salerno wrote: > >>>>>> Are there any major differences between these two? It seems they can > >>>>>> both be used with TurboGears, and SQLAlchemy with Django. I'm just > >>>>>> wondering what everyone's preference is, and why, and if there are even > >>>>>> more choices for ORM. > >>>>>> > >>>>>> Thanks. > >>>>> You can review the Persit Case, which will shortly evaluate the stated > >>>>> ORM's: > >>>>> > >>>>> http://case.lazaridis.com/wiki/Persist > >>>>> > >>>>> It is possibly of importance to remember some requirements which should > >>>>> be relevant for an persistency mechanism targetting an OO language: > >>>> RDBMS are not "persistency mechanism", they are data management tools. > >>> possibly. > >>> > >>> but this is not relevant, as the "Persist" case does not deal with > >>> RDBMS. > >>> > >> Then your post is irrelevant since there's a clear indication that the > >> OP question was about RDBMS integration in Python (hint: SQLObject and > >> SQLAlchemy both start with 'SQL'). > > ... > > > > Of course it's relevant. > > Of course not. You are right. It's not relevant for _you_. > > "I'm just wondering what everyone's preference is, and why, and if > > there are even more choices for ORM." > > You may not know it but the R in ORM stands for Relational, which > actually implies a RDBMS. ...which is completely irrelevant to _me_. Thus I'm looking for an ORM which decouples the "R" part nicely. > > The "persist case" evaluates python persistency > > Once again, it has nothing to do with persistency. I can use an ORM > connected to an in-memory SQLite db. What _you_ do is not _my_ use case. > > systems (or mechanisms), and will show my personal preference: > > I don't give a damn about your "personal preferences". _You_ are not the central part of this topic. _I_ am not the central part of this topic. The OP asked for "personal preferences": "I'm just wondering what everyone's preference is, and why, and if there are even more choices for ORM." I present my personal preferences here: http://case.lazaridis.com/wiki/Persist nothing special. . -- http://mail.python.org/mailman/listinfo/python-list
Re: CONSTRUCT -
Steve Holden wrote: > lazaridis_com wrote: > > Georg Brandl wrote: > >>lazaridis_com wrote: > >>>Georg Brandl wrote: > >>>>lazaridis_com wrote: > >>>> > >>>>>I would like to fulfill the following task: > >>>>> > >>>>>The construct: > >>>>> > >>>>>if __name__ == '__main__': > >>>>> > >>>>>should be changed to something like: > >>>>> > >>>>>if identifier.name == '__main__': > >>>>> > >>>>>The term "identifier" should be selected based on the meaning of the > >>>>>__double-underscore-enclosure__ of the entities. > >>> > >>>>import sys > >>>>class _identifier: > >>>>def __getattr__(self, name): > >>>>return sys._getframe(1).f_globals['__%s__' % name] > >>>>identifier = _identifier() > >>> > >>>ok, I understand. > >>> > >>>this one would work with modules. > >>> > >>>but how would look a more general solution, which would work with > >>>objects too? > >> > >>Why can't you try to come up with something yourself? You should have > >>had enough exposure to the Python language by now. > > > > I am not a (python) domain expert. > > > > Thus I am asking here for available standard-solutions, before I > > implement an own solution. > > > There is no standard solution for the problem you mention. I see. Can one point me to the relevant documentation? Or at least give me the relevant key-words / Search Phrases? I remember to have located a relevant PEP, but I cannot find it again. . -- http://mail.python.org/mailman/listinfo/python-list
[HOST] - Flexible Project Hosting with Python (similar to Assembla Breakout)
For a larger scale project, a collaboration infrastructure and toolset should be selected. More information about the overall project: http://lazaridis.com/pj The actually active system is a Dedicated Server (with Trac & SVN). A Project Host Candidate which comes close to the needed system is Assembla ( http://assembla.com ), but currently it does not comply fully to the Basic Requirements. You can find the actual selection case here: http://case.lazaridis.com/host Are there any other Python-Centric Project Hosts available (which could comply to the stated requirements)? Any suggestions are very welcome. -- http://mail.python.org/mailman/listinfo/python-list
PUDGE - Colored Code Blocks / Mailing List Access
Colored Code Blocks Pudge generated documentation can contain colored code blocks, using the rst directive "..code-block:: Python" (an other languages supported by SilverCity). http://pudge.lesscode.org/trac/ticket/21 http://pudge.lesscode.org/trac/changeset/126 - Mailing List The Pudge Mailing List seems to be down since the change of the server: http://news.gmane.org/gmane.comp.python.pudge.general Possibly someone can notify some of the project admins. -- http://mail.python.org/mailman/listinfo/python-list
PUDGE - Colored Code Blocks / Mailing List Access
Colored Code Blocks Pudge generated documentation can contain colored code blocks, using the rst directive "..code-block:: Python" (an other languages supported by SilverCity). http://pudge.lesscode.org/trac/ticket/21 http://pudge.lesscode.org/trac/changeset/126 - Mailing List The Pudge Mailing List seems to be down since the change of the server: http://news.gmane.org/gmane.comp.python.pudge.general Possibly someone can notify some of the project admins. -- http://lazaridis.com -- http://mail.python.org/mailman/listinfo/python-list
