At 09:34 AM 5/28/2005 -0700, Dave Peticolas wrote: >Here is a possible patch for peak.running.commands. > >It allows you to use sys.exit() without an argument >and still get the default return value of 0 (the >default specified for sys.exit in the python docs). I've now implemented a similar feature in the CVS version. Thanks for the suggestion.
Hi, pje, all. > Here are some preliminary thoughts on how the breakup might go. Just as a data point for you, the packages I'm using directly are binding, naming, config, model, protocols, and storage. > My initial feeling about this list is that it's both too coarse and > too fine-grained at the same time. It's too coarse because for > example both peak.util and peak.running are umbrella packages > containing many things that could quite reasonably be split out > individually. I'd worry less about trying to normalize the structure of PEAK as if it were a DB and more about the interaction with users' brains. I think the breakdown you suggested—3 clumps of about 5 packages each—is good; it fits ESR's definition of compactness (http://www.catb.org/~esr/writings/taoup/html/ ch04s02.html#compactness), and each clump even fits in the 5-plus-or-minus-2 size of human working memory. If you break things down further, I think new users will again descend into panic, saying "I have no idea what this thing does; there are 500 pieces!" > I'm also uneasy because keeping track of versioning and release > information for *fifteen* packages (versus two now) seems a little > overwhelming. That is going to be hard, and there's little way around it. However, it's also one of the most useful things you could do for someone in my position two months ago. I had significant trouble getting PEAK(Continue reading)
Lets have some simple PWT template "repr.pwt":
<html this:is="page">
<div content:replace="."/>
</html>
It correctly shows repr() of the underlying object. Everything is OK untill
we try to use some layout:
repr.pwt:
<html with:page-layout=" <at> <at> layout">
<div this:is='body' content:replace="."/>
</html>
layout.pwt:
<html this:is="page">
<div this:replace="/params/body"/>
</html>
Then we end in infinite recursion, because current object in repr.pwt
is not underlying object but parsed layout.pwt template. Workaround
is to use ``content:replace=".."'' in repr.pwt but I am almost sure
that this is not intended behaviour. Following patch solve the problem
but may have some undesired side effects that I am not aware of now.
Index: templates.py
===================================================================
--- templates.py (revision 53)
(Continue reading)
At 04:45 PM 6/6/2005 +0200, Radek Kanovsky wrote: >Lets have some simple PWT template "repr.pwt": > > <html this:is="page"> > <div content:replace="."/> > </html> > >It correctly shows repr() of the underlying object. Everything is OK untill >we try to use some layout: > > repr.pwt: > > <html with:page-layout=" <at> <at> layout"> > <div this:is='body' content:replace="."/> > </html> > > layout.pwt: > > <html this:is="page"> > <div this:replace="/params/body"/> > </html> > >Then we end in infinite recursion, because current object in repr.pwt >is not underlying object but parsed layout.pwt template. Workaround >is to use ``content:replace=".."'' in repr.pwt but I am almost sure >that this is not intended behaviour. Hi Radek. I'm unable to reproduce this behavior. I just checked in a new test that does this using the HTML straight from your examples above. See peak.web.tests.test_resources.IntegrationTests.testLayout. Can you tell me(Continue reading)
On Mon, Jun 06, 2005 at 12:02:58PM -0400, Phillip J. Eby wrote: > Hi Radek. I'm unable to reproduce this behavior. I just checked in a new > test that does this using the HTML straight from your examples above. See > peak.web.tests.test_resources.IntegrationTests.testLayout. Can you tell me > more about how to reproduce this behavior? The system already has code > that should make layouts work the way you want them to, so I'm surprised > that you're having a problem. > > Could it be that you are not rendering the top-level page via handle_http, > but instead are using a manually-created start context and renderFor()? Sorry for confusion. I saw error clearly in sources but there were not any there. My configuration had modifications in pwt-schema.ini that I didn't notice. Thanks to work on this problem, things are more clear for me. Especially parameter wrapping in templates.Replace with DOMletMethod. It does what I think it doesn'tRadekK
At 09:30 AM 6/6/2005 -0400, Erik Rose wrote: >I'd worry less about trying to normalize the structure of PEAK as if it >were a DB and more about the interaction with users' brains. I think >the breakdown you suggested3 clumps of about 5 packages eachis good; >it fits ESR's definition of compactness >(http://www.catb.org/~esr/writings/taoup/html/ ch04s02.html#compactness), >and each clump even fits in the >5-plus-or-minus-2 size of human working memory. If you break things >down further, I think new users will again descend into panic, saying >"I have no idea what this thing does; there are 500 pieces!" That's just it, though; if things can stand on their own, they can stand on their own. For example, there is an assortment of testing utilities in peak.util: mockdb, mockets, and unittrace. The odds that anybody will do much of anything with them in peak.util is pretty much nil, but if I bundled them as a mini-project (perhaps called "MockTesting"), it'd probably get some interest from TDD-oriented folks. Similarly, nobody's going to install PEAK just to get peak.util.uuid and friends, but as a "PyUUID" package that provides a cross-platform API for the draft UUID/GUID spec, and that's another thing people would download. Neither MockTesting nor PyUUID would have the same audience as the rest of PEAK, and there's absolutely no connotation that you have to learn these packages in order to "learn PEAK". There are many other use-case oriented groupings of PEAK's contents that could be spun off to live as semi-independent packages. The purpose here isn't to "normalize" PEAK, but rather to make its functionality accessible to a wider audience (in the overall sense) by having individual packages be(Continue reading)
I've managed to get setuptools to a good enough place to allow automatic dependency installation in a sane way, so I'm starting to plan the first breakups of the PEAK ouevre. I was originally going to convert our CVS repository to subversion before doing any breakups, but I've found through attempts at converting it, that cvs2svn doesn't like the repository symlinks we're using to share stuff between projects. That's a bit of a problem, since we share a *lot* of stuff between projects. So it looks like we'd probably be better off eliminating the sharing *before* even considering moving anything to subversion. I think the first step is going to be to get rid of PEAK's embedded versions of setuptools, by migrating to the current Python CVS sandbox version that I've been developing on. This will be accomplished by adding the 'ez_setup.py' script to each of the projects (PEAK, PyProtocols, wsgiref) that uses it. After that, I'll delete the source of setuptools from the CVS HEAD as a normal revisioned delete. The only tricky bit about that is that there will be a period between some of the commits where an intermediate checkout wouldn't work correctly due to conflicts between ez_setup and setuptools. But at the end everything should be fine and the history intact. The next thing that's shared across a bunch of products is the src/setup/common.py file. However, I only use the stuff that's in it to generate online documentation, and documentation for the "source+doc" distribution variants. Does anybody use it for anything else? I'm actually leaning towards getting rid of the "source+doc" distribution format anyway, in favor of just generating and distributing the documentation separately. But I'm open to feedback on all this. Anyway, my current thought is just to nix src/setup/common.py and update my(Continue reading)
After more investigation, it seems like it's going to be easier to just move to Subversion than to do all the CVS repository munging I described last night. So much easier, in fact, that I've already done a prototype migration: ViewCVS: http://svn.eby-sarna.com/ Anonymous SVN: svn://svn.eby-sarna.com/svnroot/wsgiref svn://svn.eby-sarna.com/svnroot/PEAK svn://svn.eby-sarna.com/svnroot/PyProtocols If you have a login to the box (i.e., if you're Ty ;) ), you can use svn+ssh: URLs instead of svn: URLs to get write access, although you may have to modify your .bashrc to set a path that includes svnserve. (I had to.) I don't have commit messages implemented yet, although if you're on the source-changes mailing list you might think otherwise with all the test mails flying by. Those are actually being generated by svn2cvs, which is a reverse migration script that copies Subversion changes back into CVS. This will be what we'll use as our safety line in case we have to abort the migration and don't want to redo commits. It also means that I won't have to write a script to send commit messages right away, because the CVS commit scripts take care of that, although they generate links to the CVS revisions, not the SVN ones. But, I'll want to switch that over to Subversion-specific commit messages pretty soon. Finally, it also means that I'll be able to leave all the current CVS infrastructure in place for people who aren't quite ready to make the switch.(Continue reading)
Hi, I'd like to use pyprotocols to adapt objects returned by a third party library to a set of interfaces specified in my system. The external library returns instances of type Accessible via a number of methods. The Accessible object is a client side proxy for some server side object. The Accessible object is a generic interface to a slew of different server side objects. The Role attribute of the accessible object says exactly what kind of object it is representing on the server side and, thus, what its various values mean. For instance, the Value property of an Accessible object with a Role of 'list' is the length of the list while the Value property of an Accessible object with a Role of 'tree' is the number of levels in the tree. What's I'd like to do is adapt instances of the generic Accessible objects to more specific interfaces based on the Role attribute. For example, I'd like to have IList protocol with a method of getLength. Then I'd like to have an adapters like AccessibleListViewAsList and AccessibleComboboxAsList that implement the IList interface for various list-like objects.(Continue reading)
At 07:12 AM 6/29/2005 -0400, Peter Parente wrote:
>I'm guessing what I really need is an adapter factory that does something
>like the following pseudocode:
>
>def accessibleAdapterFactory(obj):
> # get object role
> role = obj.Role
> # look for adapters for given role and type
> return protocol.registry.findAdapterFor(role=role, type=type(obj))
>
>Is such a thing possible with pyprotocols?
Yes. One way is to define the adapter function as a generic function
(using the current CVS HEAD of PyProtocols):
import dispatch
<at> dispatch.generic()
def createIList(obj):
"""Generic function for adapting Accessible"""
<at> createIList.when("obj.Role==ComboBox")
def createComboBoxAsList(obj):
return AccessibleComboboxAsList(obj)
>Is there another solution?
Yes; instead of adapting, you can use generic functions to perform
operations like getLength() directly, e.g.:
(Continue reading)
RSS Feed11 | |
|---|---|
3 | |
2 | |
7 | |
3 | |
6 | |
18 | |
14 | |
1 | |
7 | |
2 | |
15 | |
2 | |
1 | |
2 | |
35 | |
1 | |
22 | |
24 | |
2 | |
1 | |
7 | |
4 | |
6 | |
32 | |
32 | |
1 | |
25 | |
13 | |
11 | |
12 | |
10 | |
51 | |
68 | |
12 | |
7 | |
30 | |
44 | |
9 | |
24 | |
35 | |
53 | |
7 | |
12 | |
14 | |
12 | |
3 | |
21 | |
50 | |
8 | |
9 | |
8 | |
14 | |
4 | |
8 | |
7 | |
7 | |
11 | |
20 | |
9 | |
15 | |
39 | |
29 | |
9 | |
44 | |
21 | |
12 | |
35 | |
5 | |
21 | |
21 | |
7 | |
34 | |
12 | |
23 | |
62 | |
51 | |
43 | |
60 | |
94 | |
78 | |
81 | |
86 | |
40 | |
130 | |
68 | |
28 | |
93 | |
43 | |
123 | |
132 | |
128 | |
82 |
