RE: [Zope3-Users] Re: How can I get a viewlet's docstring from within aviewlet manager?
Thanks, that solved my problem. Now I can get hold of the docstring I want with "viewlet.__class__.__base__.__doc__" Andreas > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Philipp > von Weitershausen > Sent: 14. juni 2008 11:22 > To: zope3-users@zope.org > Subject: [Zope3-Users] Re: How can I get a viewlet's > docstring from within aviewlet manager? > > Andreas Johnsen wrote: > > Let's say I have defined 'class MyViewlet(viewlet.ViewletBase)' and > > registered it with the directive. The class > > 'MyViewlet' has a docstring. How can I get this docstring from the > > render() method in a viewlet manager? > > > > In the viewlet manager the viewlet instance is an instance of > > 'zope.viewlet.metaconfigure.MyViewlet' and not my class 'MyViewlet'. > > Yeah. Dynamic class generation sucks. For some reason, the > bad example led by browser:page et.al. has caught on and now > nearly all browser-related ZCML directives do it. > > > Is there a path from 'zope.viewlet.metaconfigure.MyViewlet' to the > > class 'MyViewlet' or any other suggestions on how to get > the docstring > > defined in my class from a viewlet manager? > > You could get the right base class from __bases__ and look at > that class's __doc__. > > ___ > Zope3-users mailing list > Zope3-users@zope.org > http://mail.zope.org/mailman/listinfo/zope3-users > ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Zopeproject-generated app - problem with temporary paths to egg packages
Hello, For some mysterious reason my app (generated by zopeproject) uses eggs from some temporary path, even when the original egg is not zipped. This makes impossible to set breakpoint somewhere in egg code, or to quickly navigate to exception point in eclipse pydev. Is there a simple way to get rid of this? In grokproject app I haven't observed such an effect - eggs were used just where they exist. Example below. Both eggs are not zipped and exist in c:\documents and settings\aleksk\buildout-eggs\, while when the app is run - they seem to be copied to temporary path: Traceback (most recent call last): File "c:\documents and settings\aleksk\buildout-eggs\tmpzotmjy\zope.publisher-3.5.2-py2.5.egg\zope\publisher\publish.py", line 130, in publish File "c:\documents and settings\aleksk\buildout-eggs\tmpzotmjy\zope.publisher-3.5.2-py2.5.egg\zope\publisher\http.py", line 456, in traverse File "c:\documents and settings\aleksk\buildout-eggs\tmpzotmjy\zope.publisher-3.5.2-py2.5.egg\zope\publisher\base.py", line 263, in traverse File "c:\documents and settings\aleksk\buildout-eggs\tmpbu3h57\zope.app.publication-3.4.3-py2.5.egg\zope\app\publication\publicationtraverse.py", line 61, in traverseName File "c:\documents and settings\aleksk\buildout-eggs\tmpbu3h57\zope.app.publication-3.4.3-py2.5.egg\zope\app\publication\traversers.py", line 44, in publishTraverse Warm regards, Alek ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Zopeproject-generated app - problem with temporary paths to egg packages
Alek wrote: Hello, For some mysterious reason my app (generated by zopeproject) uses eggs from some temporary path, even when the original egg is not zipped. This is a known setuptools problem. It compiles .py modules to .pyc files in a temporary location, thus the .pyc files contain references to the wrong path. This makes impossible to set breakpoint somewhere in egg code, or to quickly navigate to exception point in eclipse pydev. Is there a simple way to get rid of this? Delete all .pyc files from your egg directory, e.g.: find . -name "*.pyc" | xargs rm In grokproject app I haven't observed such an effect - eggs were used just where they exist. grokproject should suffer from the same problem. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zopeproject-generated app - problem with temporary paths to egg packages
On Thu, Jun 19, 2008 at 7:29 AM, Alek <[EMAIL PROTECTED]> wrote: > Hello, > For some mysterious reason my app (generated by zopeproject) uses eggs from > some temporary path, even when the original egg is not zipped. This is a known problem with setuptools. The easiest way around it is to remove the egg's .pyc files. They will be regenerated with correct path info. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Python Package Construction
Hi All, I would like feedback on the proper/best 'Pythonic' approach. This is a rather subjective question. Where is the trade-off between package name lengths and faithfulness to the specifications? [Discussion follows] I am implementing a set of specifications for healthcare IT for Python programmers to be able to develop interoperable healthcare applications. I am using ZCA (aka.Zope3) extensively. My desire is to implement the specs as faithfully as possible for two reasons: 1) teachability - how easy/difficult is it to teach the framework and specifications to new developers? 2) maintainability - which approach, if either, will make it easier to maintain the framework if/when the specifications change? My first pass was to develop a skeleton of the specs using Interfaces from the ZCA approach and then the implementations following the document structure of the specs. The specs are available via SVN at: http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/ It is best to probably use real examples. Following the document structure for packaging AND using the ZCA convention of having a sub-directory for interfaces caused massive circular import issues due to some classes being used in the interface definition of classes inside the same interface file being imported into the implementation file. If that sounds confusing; it is. It was confusing to write too. :-) If anyone has questions I'll try to expand. It is best to probably use specific, real examples. http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/data_types_im.pdf (note class names are converted from the upper case, underscore separated style to CamelCase) The package openehr.rm.datatypes.text defines the implementation class CodePhrase. The associated interface file openehr.rm.datatypes.interfaces.text needed CodePhrase as an attribute type in DvCodedText and TermMapping needs both CodePhrase and DvCodedText. This quickly got out of control. So my solution to solving the circular imports is to take each interface and implementation and put them into one file. Research tells me that this is probably the second mostly popular ZCA approach. So, ICodePhrase and CodePhrase are now in openehr/rm/datatypes/codephrase.py, DvCodeText and IDvCodedText in openehr/rm/datatypes/dvcodedtext.py, etc. But wait, now I don't have a 'text package'. So if codephrase.py and dvcodedtext.py were in openehr/rm/datatypes/text/ that would solve the problem. BUT! Throughout the specs many of the names are VERY long already. Adding another package name that is from 4 - 15 (or more) characters long adds to the length of already long import statements, i.e. (sorry for the email line wraps) from openehr.am.archetype.creferenceobject import ICReferenceObject,CReferenceObject should really be from openehr.am.archetype.constraintmodel.creferenceobject import ICReferenceObject,CReferenceObject Thoughts, opinions and jeers all gratefully accepted. :-) --Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
AW: [Zope3-Users] Python Package Construction
Hi Tim > Betreff: [Zope3-Users] Python Package Construction > > Hi All, > > I would like feedback on the proper/best 'Pythonic' approach. > > This is a rather subjective question. Where is the trade-off > between package name lengths and faithfulness to the specifications? > > [Discussion follows] > > I am implementing a set of specifications for healthcare IT > for Python programmers to be able to develop interoperable > healthcare applications. > I am using ZCA (aka.Zope3) extensively. > > My desire is to implement the specs as faithfully as possible for two > reasons: > 1) teachability - how easy/difficult is it to teach the > framework and specifications to new developers? > 2) maintainability - which approach, if either, will make it > easier to maintain the framework if/when the specifications change? > > My first pass was to develop a skeleton of the specs using > Interfaces from the ZCA approach and then the implementations > following the document structure of the specs. > > The specs are available via SVN at: > http://www.openehr.org/svn/specification/TRUNK/publishing/arch > itecture/ > > It is best to probably use real examples. Following the > document structure for packaging AND using the ZCA convention > of having a sub-directory for interfaces caused massive > circular import issues due to some classes being used in the > interface definition of classes inside the same interface > file being imported into the implementation file. If that > sounds confusing; it is. It was confusing to write too. :-) > If anyone has questions I'll try to expand. > > It is best to probably use specific, real examples. > http://www.openehr.org/svn/specification/TRUNK/publishing/arch > itecture/rm/data_types_im.pdf > > (note class names are converted from the upper case, > underscore separated style to CamelCase) > > The package openehr.rm.datatypes.text defines the > implementation class CodePhrase. The associated interface > file openehr.rm.datatypes.interfaces.text needed CodePhrase > as an attribute type in DvCodedText and TermMapping needs > both CodePhrase and DvCodedText. This quickly got out of control. > > So my solution to solving the circular imports is to take > each interface and implementation and put them into one file. > Research tells me that this is probably the second mostly > popular ZCA approach. So, ICodePhrase and CodePhrase are now > in openehr/rm/datatypes/codephrase.py, DvCodeText and > IDvCodedText in openehr/rm/datatypes/dvcodedtext.py, etc. > > But wait, now I don't have a 'text package'. So if > codephrase.py and dvcodedtext.py were in > openehr/rm/datatypes/text/ that would solve the problem. > BUT! Throughout the specs many of the names are VERY long > already. Adding another package name that is from 4 - 15 (or > more) characters long adds to the length of already long > import statements, i.e. > > (sorry for the email line wraps) > > from openehr.am.archetype.creferenceobject import > ICReferenceObject,CReferenceObject > > should really be > > from openehr.am.archetype.constraintmodel.creferenceobject > import ICReferenceObject,CReferenceObject > > Thoughts, opinions and jeers all gratefully accepted. :-) For a usecase like this, I personaly recommend to defina all interfaces in one module which probably is a namespace if you need alot of interfaces to define. e.g. openehr.interfaces.foobar.IFooBar the reason why: - spearate interface from implementation. That's an important aspect in a component architecture. If you define your implementation and interfaces in one file, then you don't need a component architecture. - interfaces are separated in a well know place. This means if you define a module and you like to import an interface you can import just one line: from openehr import interfaces Which makes it very simple. Regards Roger Ineichen > --Tim > > > > > > > > > > -- > Timothy Cook, MSc > Health Informatics Research & Development Services LinkedIn > Profile:http://www.linkedin.com/in/timothywaynecook > Skype ID == timothy.cook > ** > *You may get my Public GPG key from popular keyservers or * > *from this link http://timothywayne.cook.googlepages.com/home* > ** > ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
