Mailman 3 September 2002 - Twisted

Re: [Twisted-Python] Is X.25 supported?
by Eric C. Newton Sept. 17, 2002

Sept. 17, 2002

Twisted does prevent it, but there is no built-in support. This is not suprising since X.25 APIs are different on nearly every platform. I tried re-patching my changes back in recently and had little success. I may come back to this in a couple of months. -Eric On Tue, Sep 17, 2002 at 06:51:26PM +0200, Sergio Lobo wrote: > Hello, > > I just found the article below on the web. Would anybody please let me know if > Twisted-Python provides any support for the X.25 protocol? > … [View More]

1 0

[Twisted-Python] Is X.25 supported?
by Sergio Lobo Sept. 17, 2002

Sept. 17, 2002

Hello, I just found the article below on the web. Would anybody please let me know if Twisted-Python provides any support for the X.25 protocol? Kind regards Sergio Lobo [Twisted-Python] adding a new connection type Eric C. Newton twisted-python(a)twistedmatrix.com Sun, 26 May 2002 22:30:45 -0400 * Previous message: [Twisted-Python] adding a new connection type * Next message: [Twisted-Python] adding a new connection type * Messages sorted by: [ date ] [ thread ] [ subject ] [ … [View More]

2 1

[Twisted-Python] X.25 for Python
by Sergio Lobo Sept. 17, 2002

Sept. 17, 2002

Hello Eric, I just found the article below on the web. Would you please let me know if Twisted-Python provides support for X.25? Kind regards Sergio Lobo [Twisted-Python] adding a new connection type Eric C. Newton twisted-python(a)twistedmatrix.com Sun, 26 May 2002 22:30:45 -0400 * Previous message: [Twisted-Python] adding a new connection type * Next message: [Twisted-Python] adding a new connection type * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] … [View More]

1 0

[Twisted-Python] serial datatype in t.e.row
by Sean Riley Sept. 16, 2002

Sept. 16, 2002

I have been looking at adding support for "serial" columns into twisted.enterprise.row and it appears to be harder than i originally thought. Serial columns auto-increment when a row is inserted so that the application doesnt have to manage the value of the index manually. So: CREATE TABLE mytable ( column1 serial, column2 int ); INSERT INTO mytable (column2) VALUES (33); will actually auto-increment the sequence for "column1" and use the next value. But.. using twisted … [View More]

4 5

Re: [Twisted-Python] persistence interface
by Laura Creighton Sept. 16, 2002

Sept. 16, 2002

There is a new persistence-SIG mailing list on python.org discussing things like this, er, not right now but last month (things have become fairly quiet). If you've ever thought -- Persistence would be so much easier if only Python had capability XYZ -- now is the time to mention it, when GvR wants to make changes to support persistence. Laura

1 0

[Twisted-Python] persistence interface
by Sean Riley Sept. 15, 2002

Sept. 15, 2002

Glyph and I talked about persistence interface for use in twisted.enterprise initially but with possibly broader implications: class IPersistence(Interface): """I can generate data to persist my current state. The persistent data must be composed of basic types that can be handled by common data storage systems (relational data bases, XML, etc). The data returned shouldn't contain other complex python objects, lists or dictionaries. """ def getStateToPersist(self): """Return a … [View More]

4 3

RE: [Twisted-Python] Perspective vs. Identity question
by Brian Warner Sept. 15, 2002

Sept. 15, 2002

> sounds like you are on the right track. For another example, take a look at > twisted.enterprise.dbcred. It has two authorizers that create perspective > and identities from a relational database and a "reflector" which is another > type of data source. Thanks for the confirmation. This stuff is finally starting to make sense. You're right, dbcred is a good example. SQL is still pretty foreign to me, but somehow seeing the SQL tables and the way dbcred is accessing them helps me … [View More]grok the identity/perspective stuff better. The fact that it's a different style (building Identities on the fly rather than having them pre-built) helps a lot. So.. the Identity doesn't really have to exist before the call to .getIdentityRequest().. it might be pre-made, or pulled out of a database by name (or other persistent structure), or created with data retrieved from a third party, or just faked altogether (like a chat service that lets anybody log in, .getIdentityRequest() could just make a new Identity for every caller, maybe enforcing unique names). And the same is true for the Perspectives? .getPerspectiveRequest() could retrieve an existing Perspective or create a new one on demand? I guess if the perspective is supposed to hang around (like, um, say a chat service that remembers user state between logins) then it shouldn't get deleted from the service when the .detach() method is called. Ah, but it could get saved to disk and then dropped from memory. And then reloaded when they log in again. Hence .cachePerspective() and friend. Enlightenment dawns. I keep coming up with more questions, but the process of phrasing the question in a concrete manner is letting me figure out the answer without asking it. Interesting. I think that means I'm past some inflection point. Last rhetorical question (which I ask so that someone can tell me if I'm wrong). There should be a roughly one-to-one correspondence between perspective subclasses and service subclasses, right? Each service's .getPerspectiveNamed method will create arbitrarily many Perspective objects, with different names, for different Identities, but (generally) always of the same class? MyFooService will have a bunch of instances of MyFooPerspective, etc? The hierarchy looks something like: Application Authorizer Identity[0] username, password servicenameA,perspectivenameA servicenameB,perspectivenameB ... Identity[1]... ServiceA servicename="A" PerspectiveA[0] name otherdata PerspectiveA[1].. ServiceB servicename="B" PerspectiveB[0] PerspectiveB[1].. If that were a graph, there'd also be arrows from Identity[0] to both PerspectiveA[0] and PerspectiveB[0]. Ok, that's as much enlightenment as I can take for one day. Somebody tell me if I got it confused. I'll try to write this up somehow so it might help someone else. thanks, -Brian [View Less]

1 0

[Twisted-Python] More DOMTemplate/WebMVC examples
by Donovan Preston Sept. 14, 2002

Sept. 14, 2002

I recently gave a talk about Twisted, DOMTemplate, and WebMVC at the BayPIGgies Python Interest Group meeting in Palo Alto. For the meeting, I created some simple examples that are hopefully self-explanatory. I thought I would post them for anyone who is interested to look at. I also fixed a few bugs while creating these examples (related to error handling) so they will probably work best with CVS head of Twisted. Donovan

1 0

[Twisted-Python] domtemplate examples
by Bruce Mitchener Sept. 14, 2002

Sept. 14, 2002

Hey all, Does anyone have more involved examples (even ones they can only share privately for now) of using DOMTemplate than the one in doc/howto? Examples of form integration and DB integration like outputting lists of things from a result set of a query would all be welcome. - Bruce

2 2

[Twisted-Python] Perspective vs. Identity question
by Brian Warner Sept. 14, 2002

Sept. 14, 2002

So I'm trying to figure out the whole PB thing; I smell a lot of potential there but haven't figured out enough to actually use it yet. I figured a question here might start to clear up my confusion. I'll start with what I think I know so that if I'm wrong someone can correct my understanding. I intend to turn this into some kind of documentation so that my ignorance can be used towards some greater good :). I think I get the PB remote-method scheme up to the level demonstrated in docs/… [View More]examples/pbsimple.py (using pb.connect and remote_* methods). In trying to figure out the Perspective/Identity layer (as in pbecho.py), what I've figured out so far is: Application instances hold an Authorizer, usually a DefaultAuthorizer. A DefaultAuthorizer has a collection of Identity objects, each with a unique identityName. That collection doesn't have to be a static list: .getIdentityRequest() could be overridden to do some kind of asynchronous lookup (LDAP comes to mind). Each Identity has a username and a password. It also has a list of "keys" (.keyring), each of which is a (perspectivename, servicename) tuple. If the remote client knows both username and password for a given Identity, then they are allowed to ask that Identity for any perspective on its keyring by supplying a (servicename/perspectivename) pair. The identity.requestPerspectiveForKey() method is supposed to find the named Perspective (asynchronously), run .attach() on it, then give a reference to the client. Once the client has that remote reference, they can do any perspective_* method they like. So my understanding breaks down in how this is all supposed to work in practice. I keep thinking of it in terms of a login shell or game, where you have a bunch of user accounts, and a user is using their client program to connect in. Let's say there are two Services: Shell and Game, and that the same users are allowed to connect to both. Then: Each user has one Identity object, with a username and password. These Identities could be created ahead of time (say, from /etc/passwd) and stored in the DefaultAuthorizer's list. Or, they might be created on the fly by a custom Authorizer class. The important thing is that .getIdentityRequest returns a valid Identity object when asked. Each user might talk to two potential Perpective objects. When user 'bob' is attached in to do shell stuff, he could use a Perspective called 'bob_shell', which is part of the Shell service. (I think the perspectivename is scoped to the Service, so this could just be named 'bob', but that would make this description confusing). When he is doing game stuff, he could use a Perspective called 'bob_game', part of the Game service. Presumably bob_shell and bob_game are instances of different subclasses of pb.Perspective, one which offers shell-like remote methods and the other offering game-like methods. The cross-user shared state that represents the communal game world could be stored up in the Game Service object, anything that needs to be shared between both the game and the shell could go in the overall Application object. Now, how are those Perspectives supposed to be created? Do they get built ahead of time (at the same time the Identities are made)? Are they supposed to outlast the client connection? In all the doc/example/ programs, a single Perspective is created ahead of time, and then a single Identity is created from that Perspective, using the .makeIdentity() utility method. The largest example I've been able to find is twisted.words, but as far as I can tell it does the same thing.. I think the words.Participant (subclassed from pb.Perspective) hangs around all the time whether or not the client is attached (it has a .status flag that starts as OFFLINE), and the perspectives are always created ahead of time (tap/words.py does svc.createPerspective(n).makeIdentity(pw)) based upon who is allowed to connect. I can see that the Perspective is kind of an in-server proxy for the remote user: the client can make it do anything they want (well, any perspective_* methods at least), and the perspective can outlast the client's connection (its .attached/.detached are called to let it know when the client comes and goes). But if it isn't supposed to (or doesn't need to) outlive the connection, then must it still be created ahead of time? Is identity.requestPerspectiveForKey() allowed to create new perspective objects on the fly? Sorry for the length. Tell me if I'm on the right track here.. if so, I'll try to put together some kind of multi-Perspective example program (maybe the telnet/game thing I just described) with a big how-it-works writeup, something that explains the concepts I just went over. An example+writeup like that would have helped / will help me figure out this part of Twisted.. maybe it could help others too. thanks much, -Brian, twisting a little bit more each day [View Less]

2 1

Re: [Twisted-Python] version control, QA, branching ...
by Laura Creighton Sept. 14, 2002

Sept. 14, 2002

> >>>>> "Donovan" == Donovan Baarda <abo(a)minkirri.apana.org.au> writes: > > yeah -- my original take on arch was that its implementation made it > unacceptable. but as i think about it, i'm not sure that's such a big > deal; the design seems sound from the docs, and since it's written in > a "software tools" style, incremental conversion to Python should be > feasible if that's ever desired. So... it's tempting to try for some > less-important … [View More]

2 1

Re: [Twisted-Python] version control, QA, branching ...
by Zooko Sept. 14, 2002

Sept. 14, 2002

There are four new version control systems that sound interesting to me: * BitKeeper http://www.bitkeeper.com/ The most mature of the four (?). Not fully free software, although I think it is freely usable for open source projects. * Subversion http://subversion.tigris.org/ Also relatively mature. * Arch http://www.regexps.com/arch.html There is a nice comparison between arch and subversion somewhere on that site. * OpenCM http://www.opencm.org/ The least mature of the four, but … [View More]

6 6

[Twisted-Python] timer granularity
by Jeremy Noetzelman Sept. 14, 2002

Sept. 14, 2002

What is the timer granularity in twisted? Is it possible to have subsecond event timers in Delayed or am I limited to integer seconds? J

3 2

[Twisted-Python] Async generators
by Tommi Virtanen Sept. 14, 2002

Sept. 14, 2002

Thought this might interest some of you: http://effbot.org/zone/asyncore-generators.htm """Instead of passing events to callbacks, pass information to a single handle function (a generator) via instance attributes. When the handler needs more data from the network, use yield to pass control back to the asyncore dispatcher.""" -- :(){ :|:&};:

1 0

[Twisted-Python] Copyright problems -- kill 'em while they are small
by Moshe Zadka Sept. 14, 2002

Sept. 14, 2002

admin/PyFontify.py does not have a license. Under copyright law, that means it is illegal to distribute it. While I would think that this presents a problem to the Twisted Release Team, I am in no position to make decisions here. However, for Debian, I distribute the source package along with the binary, and I'm responsible for its contents. Currently, that would mean I cannot upload .2, until it is either resolved or I resort to hacks (that is, repackaging with PyFontify removed). Please … [View More]

1 0

[Twisted-Python] docs typo [PATCH]
by Brian Warner Sept. 13, 2002

Sept. 13, 2002

Small typo in the PB howto, but it just so happened to be in the one place where it could do the most damage. Here's a patch. cheers, -Brian Index: pb.html =================================================================== RCS file: /cvs/Twisted/doc/howto/pb.html,v retrieving revision 1.1 diff -u -r1.1 pb.html --- pb.html 6 Aug 2002 03:31:04 -0000 1.1 +++ pb.html 13 Sep 2002 05:14:04 -0000 @@ -169,12 +169,13 @@ <p>This is the first class we dealt with. Perspectives are … [View More]

3 2

[Twisted-Python] Documentation and bug patches
by Itamar Shtull-Trauring Sept. 13, 2002

Sept. 13, 2002

Please submit all patches and bug reports to our bug tracker at http://sourceforge.net/tracker/?group_id=49387&atid=456015 so that they don't get lost.

1 0

Re: [Twisted-Python] Another proposal for new look for website
by Laura Creighton Sept. 13, 2002

Sept. 13, 2002

> > Itamar Shtull-Trauring, you are a very silly man. Thank you. > > If you mean the text - it wasn't me, I'm not usually that creative. It was > taken from http://www.twistedmatrix.com/labs. > > I assume Glyph wrote it, given the content. > > -- > Itamar Shtull-Trauring http://itamarst.org/ > Available for Python, Twisted, Zope and Java consulting Ok then, thank you whoever you are. Laura

1 0

Re: [Twisted-Python] version control, QA, branching ...
by Laura Creighton Sept. 13, 2002

Sept. 13, 2002

> Laura Creighton wrote: > > > Anders Qvist, quest(a)lysator.liu.se (the Project Lead for the Python-In-a-Tie > > Snake Farm was looking at Arch, and still is.) I think he actually started > > chaning all the perl scripts to use python, but I don't know how far along > > that project got. > > He should use Twisted ;) > > Seriously, the built-in ssh and FTP server and client support is exactly > what you need, and someday we'll have WebDAV too. … [View More]

1 0

[Twisted-Python] Another proposal for new look for website
by Itamar Shtull-Trauring Sept. 13, 2002

Sept. 13, 2002

http://itamarst.org/twisted_homepage.png Courtesy of MAXIMA Multimedia (http://www.maximam.com). -- Itamar Shtull-Trauring http://itamarst.org/ Available for Python, Twisted, Zope and Java consulting

1 1

[Twisted-Python] Minor buglet in spread.sturdy?
by Andrew Bennetts Sept. 13, 2002

Sept. 13, 2002

If you do: foo = sturdy.PerspectiveConnector(...) foo.startConnecting() foo.callRemote('echo', ...) ... You'll actually connect to the remote server *twice*. Which of these is the real bug: - callRemote sets self.connecting = True instead of startConnecting - startConnecting isn't for external use, and should be renamed "_startConnecting"? -Andrew.

1 0

[Twisted-Python] Patch for tapconvert manpage
by Samuel Bronson Sept. 13, 2002

Sept. 13, 2002

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 RCS file: /cvs/Twisted/doc/man/tapconvert.1,v retrieving revision 1.1 diff -u -2 -r1.1 tapconvert.1 - --- doc/man/tapconvert.1 11 Sep 2002 20:07:00 -0000 1.1 +++ doc/man/tapconvert.1 13 Sep 2002 04:44:30 -0000 @@ -3,5 +3,5 @@ ~ tapconvert \- convert Twisted configurations from one format to another ~ .SH SYNOPSIS - -.B tapconvert -i \fIinput\fR -o \fIoutput\rR [-f \fIinput-type\fR] [-t \fIoutput-type\fR] [-d] [-e] +.B tapconvert -i \… [View More]

1 0

[Twisted-Python] Mailing list archives -- ideal for Twisted?
by Andrew Bennetts Sept. 13, 2002

Sept. 13, 2002

Random IRC snippet: <jdub> what would be really cool <jdub> is to get rid of mhonarc and static http archives <jdub> and have, perhaps, an nntp-based archive system <jdub> with a web front end <spiv> Hmm. <spiv> That would suit Twisted nicely. <jdub> there are a few of these around <spiv> Hmmm.... <jdub> but it would be cool for twisted Basically, a unified web/nntp mail archive, that uses a common backend, but has a twisted.web and … [View More]

1 0

Re: [Twisted-Python] Another proposal for new look for website
by Laura Creighton Sept. 12, 2002

Sept. 12, 2002

> http://itamarst.org/twisted_homepage.png > > Courtesy of MAXIMA Multimedia (http://www.maximam.com). > > -- > Itamar Shtull-Trauring http://itamarst.org/ > Available for Python, Twisted, Zope and Java consulting > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python(a)twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python Itamar Shtull-Trauring, you are a very silly man.… [View More]

2 1

Re: [Twisted-Python] version control, QA, branching ...
by Laura Creighton Sept. 12, 2002

Sept. 12, 2002

> > There are four new version control systems that sound interesting to me: > > * BitKeeper > http://www.bitkeeper.com/ > > The most mature of the four (?). Not fully free software, although I think i > t > is freely usable for open source projects. > > * Subversion > http://subversion.tigris.org/ > > Also relatively mature. > > * Arch > http://www.regexps.com/arch.html > > There is a nice comparison between arch and … [View More]

2 1

[Twisted-Python] Twisted: the comics
by Itamar Shtull-Trauring Sept. 12, 2002

Sept. 12, 2002

isometric, one of the coolest web comics in existence, had write-ins for plots. So I submitted one. The result: http://isometric.spaceninja.com/_/twisted_plutonium/

1 0

[Twisted-Python] Job posting on dice
by Itamar Shtull-Trauring Sept. 12, 2002

Sept. 12, 2002

3 month contract in Portland, $65K. http://www.dice.com/DandL/s/sofor001.E-010.html

1 0

[Twisted-Python] version control, QA, branching ...
by Kevin Turner Sept. 11, 2002

Sept. 11, 2002

I caught some bits of a discussion on #twisted on my way to bed last night, and thought "Hey, I should read that." So I plundered the logs and did a lot of pruning and here you are, a discussion involving quality maintance practices with version controlled branches and unit tests and things. [attached] Keep in mind that this log HAS been trimmed by me, and while I have made an effort to maintain context, it's quite possible that you aren't seeing the full context for every remark made. … [View More]Random notes from me: * Michael Schwem was telling me about [http://aegis.sourceforge.net/ Aegis], which sounds like it's *much* better at branches than CVS is, and pays much stricter attention to the entire QA process. * In my recent romp through CVS resources, I found [http://codestriker.sourceforge.net/ CodeStriker]. I haven't talked to anyone who's used this, but it has some ideas in it. [05:26] <glyph> radix and I had some discussions about release procedure today, btw :) [05:26] <glyph> we came to some pretty radical conclusions [05:27] <itamar> glyph: and they were? [05:27] <glyph> itamar: release candidates should always be made from HEAD [05:27] <glyph> itamar: Twisted developers need to learn how to use branches for developing experimental features; HEAD should *always* be releaseable [05:27] <itamar> branches, here we come [05:28] <glyph> itamar: the better tests we have, the less craziness with branches is necessary. [05:36] <fzZzy_> glyph: shall I check in highly untested domtemplate=>microdom code? or wait, and test it some more? [05:36] <fzZzy_> I guess this goes back to the cvs branch issue [05:37] <dash> fzZzy_: well, isn't testing it easy? =D [05:38] <fzZzy_> dash: not at 2:30 am [05:38] <fzZzy_> and no, I never wrote any domtemplate tests [05:39] <dash> fzZzy_: no domtemplate tests?! gasp [05:39] <dash> fzZzy_: you sound like me [05:39] <fzZzy_> ok I'm going to bed instead since glyph didn't respond instantaneously ;-) [05:39] <fzZzy_> I'll be banging on it tomorrow [05:40] *** glyph has changed topic to "Welcome to the Twisted project: sleazeware produced in a drunken fury by college dropouts!" [05:40] <dash> glyph: !!! [05:40] <dash> glyph: I GRADUATED [05:40] <glyph> dash: you didn't write most of twisted :) [05:40] *** dash waves diploma madly [06:15] <glyph> jml: much like linux; even very stable kernels with frozen APIs contain "experimental" drivers and such [06:15] <jml> glyph: so the trick is to mark them as such? [06:15] <glyph> itamar: I don't think that's the case; in Twisted's history we've had releases that were pretty stable and didn't require a lot of after-the-fact tweaking [06:16] <jml> glyph: for many commercial packages, it's not that long after release that you get SP1.. no one really thinks it a bad thing. [06:16] <jml> just as long as code-breaking changes aren't slipped under the door. [06:17] <glyph> jml: I am increasingly confident in our test suites lately [06:17] <glyph> jml: we seem to have had relatively few problems with code-breaking stuff slipping in without anyone noticing :) [06:17] <jml> glyph: btw, how's the test-first design going? I've found it hard in the past to keep disciplined about it. [06:18] <glyph> jml: it's hard to keep disciplined about it for me too :-(. When I can do it, it's *definitely* better than the other way. [...a big discussion on one-point-oh philosophy intervenes here. Only a few tangentially related bits are included in this log excerpt...] [06:22] <glyph> itamar: in "policy": we don't have a policy for continuing development of Twisted after 1.0, in terms of legacy support of APIs that may need to change for some reason. (Yes, some large portion of twisted.internet is stable, but what is our support policy for the *other* portions of twisted that you *need* to use for a useful app? Are they just unsupported continuing forward?). We don't have a policy for releases which is sustaina [06:23] <glyph> this includes things like "when should developers use a branch?" and "how should the release manager interact with users in order to decide whether we mihgt be breaking something important?" [...] [06:27] <glyph> itamar: but then, a developer has some feature they want to play around with, which they believe to be potentially unstable, but doesn't break any tests [06:27] <glyph> what are the guidelines for them to work with that? [...] [06:52] <moshez> glyph: which reminds me. [06:52] <glyph> moshez: hmm? [06:52] <moshez> glyph: tell radix to fix ReleaseProcedure [06:52] <glyph> moshez: we've talked about changes to ReleaseProcedure [06:52] <moshez> glyph: I left a note there what he should fix [06:52] <glyph> moshez: OK [06:53] <moshez> glyph: I'm not talking about changes to the procedure, just bring the document up todate on reality. [06:53] <glyph> moshez: I don't see the note :) [06:54] <moshez> ---- This part is sorely out of date -- document the new Debian way -- [06:54] <itamar> oh [06:54] <itamar> new policy is to do all major devel on brances? [06:55] <itamar> better mail the list then [06:55] <glyph> itamar: that's a proposa, still need to hash it out, and to make sure that it is SUPER EASY for developers to do this [06:55] <itamar> it sounds painful [06:55] <moshez> glyph: it isn't. [06:55] <itamar> but it probably is easy [06:55] <moshez> glyph: it isn't even mildly easy [06:55] <moshez> glyph: I'm not sure I like that propsal actually. [06:56] <glyph> moshez: I figured you wouldn't :) [06:56] <itamar> here we go again [06:56] <glyph> but I'm not really sure what you wouldn't like [06:56] <itamar> it may make more sense to branch on each release [06:56] <moshez> glyph: merging is hell on earth [06:57] <glyph> moshez: that gives the developer incentive to integrate early, as well as provide backwards compatibility hooks and good tests so that he doesn't have to hang out in a branch for too long :) [06:58] <warner> my exp: each branch doubles the total effort. don't branch unless you know you won't do much work on one of the paths [06:58] <glyph> moshez: when radix and I discussed the policy, we were also debating the need for coverage tools in order to qualify particular changes for branches [06:58] <moshez> glyph: how do you decide which changes go on a branch and which go on HEAD? [06:58] <glyph> like if the module you are planning to restructure has 95% unit test coverage, chances are you can get away with not having a branch at all, provided you don't change tests [06:59] <moshez> glyph: and woulnd't it just make sense to say "never break unittests"? [06:59] <glyph> moshez: yes, that makes sense [06:59] <itamar> possibly the effort should go into more tests [06:59] <itamar> instead of branches [06:59] <glyph> itamar: that would be optimal [06:59] <itamar> ugh [06:59] <itamar> this is too distracting [06:59] *** itamar has quit IRC ("must work") (~itamar(a)line102-187.adsl.actcom.co.il) [07:00] <glyph> i win! [07:00] <moshez> "Finish Him" [07:00] *** glyph isn't clear what that would entail, since itamar's already disappeared [07:01] <glyph> moshez: So yes, "never break unittests" is good, but if you're doing work on, for example, cReactor, there just isn't good enough coverage to be sure that you're OK to check in to a branch which should be always-releaseable (HEAD), even if unittests are A-OK [07:02] <moshez> glyphy: and when would the merge from the branch to HEAD happen? [07:02] <glyph> moshez: after our army of simean warriors bashes on the code for several weeks [07:03] <moshez> glyph: in other words "after several weeks pass" [07:03] <glyph> moshez: i need to read up on the exact mechanics of branches in order to understand your concerns, I think [07:03] <moshez> glyph: ok. do so. [07:03] <glyph> is it not possible for a developer to continuously re-integrate patches to HEAD into their branch? [07:03] <moshez> glyph: wait. [07:05] <moshez> glyph: http://www.lerner.co.il/~moshez/cvs/cvstut34.html [07:05] <warner> glyph: in my experience, yes [07:05] <warner> glyph: however the question of "should I or not" takes up as much time as doing the commit separately to both branches [07:06] <glyph> warner: hmm [07:06] <glyph> warner: what was your experience working with branches? [07:07] <moshez> http://cvsbook.red-bean.com/cvsbook.html#Going_Out_On_A_Limb__How_To_Work_W… [07:08] <glyph> moshez: ugghh [07:08] <glyph> moshez: the 'spurious conflicts' bit is ... interesting [07:09] <warner> well, the workfolk kept alternating between the "current on HEAD" and "current on branch" schemes [07:09] <warner> the biggest problem was that people expected the merge features to mean they could do less work [07:09] <warner> but the real issue was who decided which bugs/features should get done in which releases [07:10] <moshez> glyph: I am evil [07:11] <glyph> warner: hmm [07:11] <warner> basically foisting developer work off to the config mgmt people, who didn't know the code well enough to say yes or no [07:11] <glyph> okay, I worked with branches in perforce [07:11] <glyph> they made *waaaay* more sense than this [07:11] <glyph> I think cvs's semantics are broken [07:12] <warner> yup, P4's scheme is easier to work with [07:12] <glyph> at the very least, they're not what I want ;) [07:12] <warner> the workfolk took the other path out: ClearCase [07:12] <warner> That was two years ago and they're still trying to figure out how it works. [07:12] <moshez> glyph: well, if we moved to SVN, we'd have easier branching [07:13] <warner> But at least it's expensive. They get good use out of their big NetApp boxes too. [07:13] <jml> I suppose subversion is out of the question? [07:13] <warner> I tend to see CVS's painful branching as similar to the 8-char tabstops in the linux kernel.. [07:14] <warner> .. a bug that makes you aware of just how bad it is to overuse that thing.. [07:14] <warner> .. if you were to fix it (or find a tool that did it better), you'd be tempted to use it more, and that would be bad. [07:16] <glyph> jml: Well, I originally really didn't want to consider it, because I thought that there would be funding for a Twisted-based version control system in the near future [07:17] <jml> understandable. I disagree though. [07:18] <glyph> jml: Well, the funding didn't appear as expected (though it still will at some point, most likely about a year from now), and this is the first time I've really wanted a feature which svn potentially implements better [07:18] <glyph> svn's infrastructure strategy frankly scares me though [07:19] <warner> twisted.revisions? my brain hurts [07:20] <jml> glyph: yeah, fair enough. I'm quite happy to have at least one or two network apps that aren't twisted, but that's me. [07:20] <warner> or maybe that's just the lack of sleep [07:20] <glyph> warner: your brain hurts? *your* brain hurts? [07:20] <glyph> warner: YOU HAVE NOT YET COME TO KNOW PAIN, MORTAL [07:20] *** warner laughs [07:23] <phed__> twisted.revision features: every client is also a server. you create a branch every time you edit a file. versioning is measured in minutes. realtime versioning. integrated QA [07:25] <warner> "integrated QA": my current learn-as-I-go Twisted project is a tinderbox-like distributed build network, including various forms of 'make test' stages [07:25] <glyph> warner: awesome! [07:25] <glyph> warner: is this going to be publicly available? [07:26] <warner> I'm basing it off CVS commit messages, but direct-from-VC would be better [07:26] <warner> glyph: yup. I did a similar thing for work (before I found twisted), now I'm rewriting it without the shackles of employment [07:27] <glyph> warner: are you using CVSToys? [07:27] <warner> glyph: nope. whazzat? [07:27] <glyph> warner: ooooohhhh [07:27] <glyph> http://twistedmatrix.com/users/acapnotic/cvs.png [07:27] <moshez> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAI… [07:27] <glyph> warner: talk to acapnotic :) [07:29] <warner> glyph: will do. if I guess correctly about what it does, it would get rid of yet another piece of code I need to write. Just like twisted did for the entire serialization and transport layer. [07:30] <warner> (if I wait long enough, the rest of the necessary code will disappear too. love it.) [07:31] <glyph> warner: cool :) [07:31] <glyph> warner: hey wait [07:31] <glyph> warner: you know, we could really use something like that [07:31] <glyph> warner: I keep meaning to write an automated unit-test runner with e-mail notification [07:33] <glyph> I'm going to go to sleep for about 16 hours right now [07:33] <glyph> talk to you crazy cats later [07:33] <warner> glyph: that'd be part of it. Of course with twisted you'd get an IRC bot too. The motivation back at work was to punish folks who broke the build. The status output was a web page they'd refresh every once in a while until they saw their changes were built successfully. But I'm planning on Gtk clients too. [07:34] <warner> catch you later glyph. I'll let you know what I code up. [View Less]

1 0

[Twisted-Python] man pages
by Moshe Zadka Sept. 11, 2002

Sept. 11, 2002

All utilities in bin/ should be accompanied by man pages. Violators will be eaten.

1 0

[Twisted-Python] Re: [XML-SIG] Can anyone recommend a sensible XML parser for Python?
by Uche Ogbuji Sept. 10, 2002

Sept. 10, 2002

> > Uche Ogbuji writes: > > Wouldn't it be better for Python/XML to offer a *separate*, specialized > > function for cloning nodes, rather than doing weird things with cloneNode? > > Why? I'd rather make cloneNode() do the right thing, and it seems > rather clear what that should be. Certainly more clear than for > DocumentType nodes. ;-) So you think it should do what I mentioned before? 1) Create a new documenType and document node 2) clone all child … [View More]

2 1

[Twisted-Python] Re: [XML-SIG] Re: Can anyone recommend a sensible XML parser for Python?
by Uche Ogbuji Sept. 10, 2002

Sept. 10, 2002

> > Accordin to the DOM Level 2 spec: "And, cloning Document, DocumentType, > > Entity, and Notation nodes is implementation dependent." > > This is why standards compliance is not terribly important to me. I would > rather have a useful XML API than a standardized one. Well, what do you think is the most useful behavior of cloning a document? Is it the one I posted in response to thread? If so, don't you think the element of surprise is too great (I'd be surprised … [View More]myself at that behavior)? Wouldn't it be better for Python/XML to offer a *separate*, specialized function for cloning nodes, rather than doing weird things with cloneNode? > > Can you expand a bit more on the actual use case that makes you think you want > > to clone a document node? > > I have a template "frame" document. I want to clone the document, populate it > with information lifted from other XML files, and then write the resultant > (cloned) document out. This is the very first use-case I ever had working with > XML and it is still the most common. I see. It sounds as if a general document duplication function would be of use to you. I agree that this would be useful. I'm willing to write one and add it to xml.dom.ext. But I don't think this is a use case for node.cloneNode. > > We choose not to allow it. Perfectly legal, and I think this is the right > > choice. > > Yes, but the point remains that this *used* to work, and now it *doesn't*. I don't remember. What did it do when it "worked"? > This is functionality I found useful. While I can't comment on the intrinsic > sense or nonsense of cloning document nodes in DOM, I do know that it's > difficult to keep track of when features like this appear and disappear in the > various different XML solutions for Python. Was it ever documented? Every software module has undocumented "features" that you use at your peril. I don't think it's fair to complain when these appear and disappear. Then again, the poor state of PyXML documentation in general weakens that point of mine, doesn't it? Ah well. > Maybe this is the only feature that has done this; I don't know. It just > happens that it's a very commonly-used one for me. > > This is just another instance of my general complaint that tracking versioning > dependencies is not worth the effort for my degenerately simple use-cases for > XML. > > > You mean you can't require, say PyXML 0.8.1? Tough crowd you develop for? > > :-) > > There are still some parties interested in Twisted who are upset that it > requires Python 2.1; in fact, I felt guilty doing 2.1 support because I am > likely going to have to backport portions of it to 1.5.2 for some people. We > can all thank Red Hat for this inane persistence of ancient python versions, > but it is sadly the world I live in. I sympethize. It's largely because of Red Hat that it took us so long to drop 1.5 support in 4Suite. But a couple of months ago we decided it is not worth the developemtn and support overhead and ditched support for all versions before 2.1. I sleep better since then :-) > > > My main frustration is with packaging. > > > Here you have a point. Python, PyXML, and a lot of the related packages move > > very quickly,. and so quickly that they cause all manner of packaging > > problems. > > This is my main point, and this is the one that the PyXML community can do the > least to address. Buggy and idiosyncratic implementations are already in the > wild, and some apps will depend on those particular bugs and idiosyncrasies. > If twisted depends on a new or different set of bugs and quirks, I make it > incompatible with whatever other XML-using applications are out there today. > > Given that XML is an integration technology this is certainly less than > desirable. > > > There is no easy solution to this. > > Having a project that is precipitously approaching 1.0 myself, I can > sympathize. As much as this sort of dependency and compatibility problem has > bothered me, I *know* there will be people that write apps for Twisted and will > curse my name when I enhance some functionality later on :-). > > > I have had it in mind to suggest a PyXML-in-a-tie type effort in the Python > > Business Forum once the effort on Python itself starts to gain legs. I guess > > I can count on you to at least help cheerlead? :-) > > Cheerleading, certainly :-). Although I'm less interested in seeing PyXML > prepared for "business" clients and more interested in just seeing the level of > QA on the volunteer work go up. If I *had* any spare "scarce resources" to > commit beyond my own projects, I would certainly help getting the unit tests > unified and automated. > > > > or produce what amounts to my own `implementation' of an XML parser. > > > > If you try going this route, I guarantee you'll still be trying to get the > > most basic things right six months from now. > > ... > > > > For the applications that I'm intending to write, just doing my own parser and > > > API is both more appealing and more rewarding. > > > > Really? Color me deep skeptical. I have not seen an application on earth > > where implementing one's own parser is a good idea, and precious few where > > implementing one's own API is a good idea. I have a lot of colleagues who > > have tried. > > While it is *possible* that I'm smarter than you think I am, it is certain that > I'm more stubborn. I think you take the wrong gloss on my words. I think Linus Torvalds himself would take years to write a complete and correct XML parser. It's the nature of the beast (XML), not the programmer. I certainly do not consider myself smart enough to take on that dragon. I'm just glad to lean on folk like Clark (and Drake, Evans and co), Garshol and Viellard. > My sophomoric attempt at an XML parser is now in Twisted > CVS. Interesting. So how did you test it? > I've had this objection raised over writing yet another a web server, yet > another remote procedure call protocol, yet another asynchronous socket server > and yet another database interface. It seems like at least some of these ideas > were good ones, so I went ahead and wrote an XML parser and representation > anyway :-). I would rather write a Web server, another RPC, another async socket server *and* another DBMS interface all in a row than just take on the single task of writing an XML parser. And I think I can speak authoritatively, because I *have* implemented all four of those things. > As a data point for this hypothesis, writing the parser and the node tree took > me less than half as much time as writing these posts to various mailing lists > about XML tools (not counting this post, which has been the most > time-consuming): it took less than a quarter as much time as attempting (and > failing) to track down bugs in PyXML, not counting the time I spent trying to > figure out how to turn off undesired features in a way that would work on more > than one version. My two main existing PyXML-using applications are already > ported to this, changing barely any of their code. As I said, I am very skeptical of the result. I'll be impressed when you tell me your home-brew XML parser passes the OASIS conformance suite. Anyway, this is all moot argument. It looks as if you've satisfied yourself for now. Good luck. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra ry/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitl… 1EA5A2CF4621C386256BBB006F4CEC [View Less]

3 2

[Twisted-Python] Twisted Enterprise ROW
by Sean Riley Sept. 10, 2002

Sept. 10, 2002

A major update to Twisted Enterprise Row is in! The new features include: - support for relationships between database tables. rows from child tables can be loaded automatically when a row from a parent table is loaded. - improved interface for intializing reflectors - refactoring of the DBReflector into Reflector and SQLReflector to allow easier implementation of new types of reflectors - an XML Reflector that uses twisted.persisted.marmalade. - added a ReflectorAuthorizer to dbcred to … [View More]

1 0

Re: [XML-SIG] Re: [Twisted-Python] Can anyone recommend a sensible XML parser for Python?
by Uche Ogbuji Sept. 9, 2002

Sept. 9, 2002

> uche wrote: > > > > For the applications that I'm intending to write, just doing my own parser and > > > API is both more appealing and more rewarding. > > > > Really? Color me deep skeptical. I have not seen an application on earth > > where implementing one's own parser is a good idea, and precious few where > > implementing one's own API is a good idea. > > on the other hand, virtually every commercial XML python user > I know … [View More]

1 0

Re: [XML-SIG] Re: [Twisted-Python] Can anyone recommend a sensible XML parser for Python?
by Uche Ogbuji Sept. 9, 2002

Sept. 9, 2002

> ----Security_Multipart(Fri_Sep__6_22:44:42_2002_475)-- > Content-Type: Text/Plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > On Fri, 06 Sep 2002 17:31:51 -0600, Uche Ogbuji <uche.ogbuji(a)fourthought.com> wrote: > > > BTW, from what you're describing above, you are *not* parsing XHTML. If it > > violates the DTD, it is not XHTML. Period. > > > Just say you're parsing "HTML" and don't mention a version. That's the only … [View More]> > way to say it correctly ;-) > > OK, "XML which browsers will render". I am not parsing HTML, in that I won't > accept XML that is not well-formed. I suppose I could try to wrap HtmlParser > with minidom... yuck. Gross, but probably a good idea, come to think of it :) I can't imagine why this would be gross. IMO, it's illustrates very admirable technique, and one of the strengths of Python/XML. The parsing mechanism and the generated representation are independent of each other, so you can mix them and match them in order to take advantage of the most needed features of either. We put a lot of work into making this possible, and I find it very elegant. C++ folks took ages before they cottonned on to such an approach (in the STL), and now it has them in raptures (generic programming is all the rage). Of course, old strait-jacket Java can't touch this. Too bad for them. > The reason I mentioned the cloneNode bug is because it is the most reliable and > the most trivial to demonstrate. Like I said; at some point, I will clean up > my complaints and submit some bug reports. Here's a "bare test case" of that > particular spurious accusation: > > glyph@zelda:~% python > Python 2.2.1 (#1, Aug 30 2002, 09:36:47) > [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> from xml.dom.minidom import parseString > >>> parseString("<hello_world/>").cloneNode(1) > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/lib/python2.2/site-packages/_xmlplus/dom/minidom.py", line 186, in cloneNode > clone = _clone_node(self, deep, self.ownerDocument or self) > File "/usr/lib/python2.2/site-packages/_xmlplus/dom/minidom.py", line 1248, in _clone_node > elif node.nodeType == PROCESSING_INSTRUCTION_NODE: > NameError: global name 'PROCESSING_INSTRUCTION_NODE' is not defined You see, this is why reporting such "bugs" early is helpful. I could have told you ages ago that it is a *bad* idea to call cloneNode on a Document object. Accordin to the DOM Level 2 spec: "And, cloning Document, DocumentType, Entity, and Notation nodes is implementation dependent." IOW, yer gets what yer gets and can't really complain :-) Can you expand a bit more on the actual use case that makes you think you want to clone a document node? I do agree that the confused error message is a glitch. Current PyXML CVS gives a more straightforward "sod off" :-) >>> from xml.dom.minidom import parseString >>> parseString("<hello_world/>").cloneNode(1) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/uogbuji/lib/python2.2/site-packages/_xmlplus/dom/minidom.py", line 198, in cloneNode clone = _clone_node(self, deep, self.ownerDocument or self) File "/home/uogbuji/lib/python2.2/site-packages/_xmlplus/dom/minidom.py", line 1454, in _clone_node raise Exception("Cannot clone node %s" % repr(node)) Exception: Cannot clone node <xml.dom.minidom.Document instance at 0x82e9cbc> We choose not to allow it. Perfectly legal, and I think this is the right choice. > In order to do the work I want to do, though, those bug reports aren't going to > help. Even if you resolved every bug report that I submitted within a week, I > would be stuck in the same place I am now: I have to work around the bugs in a > bunch of old versions of PyXML You mean you can't require, say PyXML 0.8.1? Tough crowd you develop for? :-) > or produce what amounts to my own `implementation' of an XML parser. If you try going this route, I guarantee you'll still be trying to get the most basic things right six months from now. > Granted, if I packaged a newer, fixed-up > version of PyXML with Twisted, I wouldn't have to be mucking about with bits > and bytes -- but I *would* have to understand the entire ontology of confusion > associated with cross-language XML APIs. > > My main frustration is with packaging. If all the world were running Debian > unstable, I'd be fine: I'd just say Depends: python2.2-xml >= 0.9. However, > with lots of users in Windows, and many more on other linux platforms with less > pleasant package management, every new package that Twisted requires is another > fifteen minutes that the software takes to get running. It's already confusing > enough to understand it when it *works*; I want the process of getting it > running to be as seamless as possible :). Here you have a point. Python, PyXML, and a lot of the related packages move very quickly,. and so quickly that they cause all manner of packaging problems. There is no easy solution to this. Python is much more of a volunteer community than, say JAva. People work on Python and PyXML mostly to scratch their itches, which means they have less incentive to worry about the packaging mess they leave behind. This is the impetus for the Python-in-a-tie effort for Python proper. I do think we'd make a lot more friends if there were a matching PyXML-in-a-tie. It would mean companies would have to commit scarce resources to freezing interfaces and then testing and packaging to oblivion. I have had it in mind to suggest a PyXML-in-a-tie type effort in the Python Business Forum once the effort on Python itself starts to gain legs. I guess I can count on you to at least help cheerlead? :-) > For the applications that I'm intending to write, just doing my own parser and > API is both more appealing and more rewarding. Really? Color me deep skeptical. I have not seen an application on earth where implementing one's own parser is a good idea, and precious few where implementing one's own API is a good idea. I have a lot of colleagues who have tried. By all means, if you'd like to try, go ahead. > Neither DOM nor SAX will > present an API which allows me to get network XML events in quite the way I > want, so I'm going to have to do some wrapping. I have learned through my own bitter experience that you do not want network interfaces to have *anything* to do with the lexical XML layer (or even Infoset). It is best to design network interactions around *application* level semantics. Basically sending around chunks of XML text is far less hazardous than what I think you mean. > (I do wish pyRXP were > event-based... it's very close, in spirit, to what I want.) If the general > quality of XML parsers in Python were really high, I would regard this impulse > as contrary and counterproductive -- why write my own library for doing this > when perfectly good ones already exist and and are deployed all over the place? Well, as I said, I don't see any evidence that the quality of XML parsers in Python is not high. You pointed out one problem in cloneNode which, from what I gather, was mostly because you're abusing DOM. This had nothing to do with parsing. Are you speaking generically? > So maybe I'm just rationalizing what I would have done anyway. Nevertheless, > it is easier to write my own XML parser than to even properly report the bugs > that I have thus far discovered. I find this claim ludicrous on its face. Writing an XML parser with the compliance level and quality of any of the ones in PyXML takes years. Yes. Years. Feel free to re-learn this fact the hard way, if you wish. > For more information my perception of XML, and why my requirements are as > stripped-down as they are, look at the presentation here: > > http://xmlsucks.org/but_you_have_to_use_it_anyway/ > > (Yes, it's a real URL, and it's not mine.) Yes. I'd guess we've all seen that link. <shrug> So what useful technology doesn't suck? XML works for me. Your mileage may vary. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra ry/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitl… 1EA5A2CF4621C386256BBB006F4CEC [View Less]

4 3

[Twisted-Python] typed mktap usage.Options parameters
by Kevin Turner Sept. 9, 2002

Sept. 9, 2002

just jotting down this note so it gets saved someplace: There are some very common types of parameters mktap uses -- remote host or IP, port number, local interface to bind to, password. We should have some sort of typed optParameters for this, so that any tap constructor that takes a port can just say "wordsPort isa port" and get back a number instead of having to int() the string and/or look it up in /etc/services, etc. Another idea being that password-type options should be prompted for … [View More]

4 3

[Twisted-Python] caching of row objects
by Sean Riley Sept. 8, 2002

Sept. 8, 2002

Currently, if an application loads a RowObject for a particular row twice, it gets two instances that correspond to the same database row. this has the potential to cause data errors as these instances don't know about each other. One solution is make the reflector know about all the rowObjects loaded (they all have unique key identifiers from the db) and act as a factory - passing out either new objects or already loaded objects instead of duplicates. This is pretty easy to do, but I'm not … [View More]

2 1

[Twisted-Python] relationships in t.e.row
by Sean Riley Sept. 8, 2002

Sept. 8, 2002

a natural extension of twisted.enterprise.row is to add support for relationships between tables. anyone got any good examples of tools or apps that do this well? Some initial thoughts.. Currently, the reflector is initialized with the "stubs" structure that consists of: stubClass, tablename, keycolumns for each (database table / row class). This information could be extended to include some relationship data in the form of foreign keys. This foreign key data would allow relationships … [View More]between tables in the database to be mirrored into the reflector. For example, in the existing row example code the stubs structure is: stubs = [ (RoomRow, "testrooms", [("roomId","int4")]) ] If there was another table "furniture" and a foreign key in that table that connects it to the room table, then that could be specified when initializing the reflector: stubs = [ (RoomRow, "testrooms", [("roomId","int4")]), [] ), (FurnitureRow, "furniture", [("furnId","int4")]), [("roomId", "int4", "rooms", "roomId")] )] where the forth element in each entry is a foreign key of : (local_column_name, column_type, foreign_table_name, foreign_column_name) (could specify the foreign class also, but the reflector should already know which class corresponds to the foreign table.) This foreign key data would then be used when loading row objects from the database. Any time a "RoomRow" object is loaded, it would load all of the FurnitureRows for that room. Although the foreign key data is specified for the child table (furniture) it is when objects of the parent table (testrooms) are loaded that the significant work happens. Allowing an option for child rows to be loaded when loading a row is probably a good idea. This probably requires some changes to t.e.row to work. Currently the optional "factoryMethod" is passed into Reflector::loadObjectsFrom. The factoryMethod will need to be available for children classes also, so it probably should be added to the stubs structure. The "data" passed to loadObjectsFrom is also an issue, maybe the data passed into the highest level loadObjectsFrom is passed down to children, or the parent Row instance that the rows are being loaded for is passed as the data...? Maybe loadObjectsFrom takes a parent object every time it is called - this may even be required. The relationship between rows once they are loaded is another issue. Where are children row objects put once they are loaded? In the above example, maybe the RoomRow object has a list member variable called "furniture" or "children" added to it and the FurnitureRow objects are put in that list? This becomes a type of containment system with a heirarchy of containers... So, loading row objects is doable. I'm not sure of all the implications for other SQL operations. Assuming that all changes to the database are going through the row interface makes things easier, but it requires more thought... A good goal is to be able to operate on these row objects in memory and have the changes propagate into the database in controllable way. ---------------- "If he's so smart, then how come he's dead?", Homer Simspon Sean Riley sean(a)ninjaneering.com [View Less]

2 2

[Twisted-Python] container elements in domtemplate
by Kevin Turner Sept. 7, 2002

Sept. 7, 2002

webquotes.html in the domtemplate howto doesn't cover this case. template: {{{ <foo> stuff <bar> things </bar> </foo> }}} How do I replace "stuff" in the template without clearing the entire foo node, thus destroyng bar and depriving me of the opportunity to insert "things"?

2 1

Re: [XML-SIG] Re: [Twisted-Python] Can anyone recommend a sensible XML parser for Python?
by Uche Ogbuji Sept. 7, 2002

Sept. 7, 2002

> > Uche Ogbuji writes: > > You see, this is why reporting such "bugs" early is helpful. I could have > > told you ages ago that it is a *bad* idea to call cloneNode on a Document > > object. > > > > Accordin to the DOM Level 2 spec: > > > > "And, cloning Document, DocumentType, Entity, and Notation nodes is > > implementation dependent." > > That's no reason to think its a bad idea to implement it or need it, > just … [View More]that you can't rely on it being supported by an arbitrary DOM > implementation. OK. So what should it mean to clone any of these node types? I can't hardly imagine anything that doesn't run into circular madness. I think the DOM WG refused to specify this for good reason. > > I do agree that the confused error message is a glitch. Current PyXML CVS > > gives a more straightforward "sod off" :-) > > Not quite; the previous message would have been raised calling > cloneNode() on a processing instruction as well. Or calling it with > deep=1 on a portion of the tree that contained a processing > instruction. That was a real bug, and not an arbitrary limitation. OK. Glad it's fixed, then. > > We choose not to allow it. Perfectly legal, and I think this is the right > > choice. > > Honestly, I think we should implement cloneNode() for Document, simply > because not doing so seems an unnecessary limitation. It is not for > the library to decide what is right for the application. It's not arbitrary at all. cloneNode is not supposed to alter the ownerDocument: that is for importNode to do. So if you clone a document node, what happens? Do you Create a new document (and thus docType) node and then effectively call importNode on the childNodes? That's the only approach that makes sense to me. Yet it's quite arbitrary and magical. I would rather force people to be clear about what they're doing by manually creating another document and then calling importNode on all the childNodes of the original. So I do not agree that we should support cloneNode for the 4 unspecified node types. > I agree that not supporting it is legal. The exception that is raised > is wrong: it should be xml.dom.NotSupportedErr. There is no stipulation that such an exception should be thrown. The behavior is impl dependent, and I don't see why that doesn't mean the implementation can choose to throw whatever exception it wishes. However, I certainly do not object to a change to throwing xml.dom.NotSupportedErr. I just don't think it's a bug that right now it doesn't. > > This is the impetus for the Python-in-a-tie effort for Python > > proper. I do think we'd make a lot more friends if there were a > > matching PyXML-in-a-tie. It would mean companies would have to > > That would be nice to have. First task: improve & integrate all the > random piles of tests out there! They should all be run when I type > "make check" at the top level, not just a handful. Yes. Build and test farms would be the main engine of such an effort. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra ry/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitl… 1EA5A2CF4621C386256BBB006F4CEC [View Less]

1 0

[Twisted-Python] 2.3 and an unstable chroot
by Moshe Zadka Sept. 7, 2002

Sept. 7, 2002

Dear root@pyramid, Python2.3's problems with distutils are fixed, so I would like to turn Python2.3 support on for Twisted 0.99.1. We have two options: 1. I can build in the unstable chroot on moshez.org: that will mean wasted upload and download time. 2. We can create an ssh-able unstable chroot on pyramid. Here are the steps to do so: 1. Pick a directory 2. Run debootstrap *woody* 3. Enter the chroot, change apt/sources.list to point to sid and dist-upgrade 4. Install ssh, and configure … [View More]

1 0

Re: [XML-SIG] Re: [Twisted-Python] Can anyone recommend a sensible XML parser for Python?
by Uche Ogbuji Sept. 7, 2002

Sept. 7, 2002

> Hmm, I know that minidom has had some problems recently, but it has also > seen some good improvements. It sounds like you need more robust DOM > support--have you tried 4DOM? It's not as fast, but it does adhere to > the spec the best. cDomlette's cloneNode does work. If minidom's doesn't, a bug report would be nice. > Maybe (when you have time) if you let us know what > you expect to accomplish we can help out--the people in XML-SIG are some > of the sharpest in the … [View More]community. Perhaps TREX or RELAX-NG would be more > suitable. I guess the only comforting thing I can say is that every > development community is experiencing growing pains when it comes to an > XML strategy. > > Good luck, > > Eron > > On Fri, 2002-09-06 at 02:39, Glyph Lefkowitz wrote: > > > > On 05 Sep 2002 17:53:09 -0400, Eron Lloyd <elloyd(a)lancaster.lib.pa.us> wrote: > > > Are you referring to PyXML? I know xml.* in the Standard Library is > > > pretty weak by far (but getting better!). > > > > Yes. In fact, PyXML is a big part of the problem. Its "minidom" module, for > > example, is *far* buggier than the one found in the standard library. (As an > > example of that, try to figure out how to make cloneNode work on a Document > > object.) What version of PyXML? > > I could deal with one set of potential problems and pitfalls using XML in > > Python and work around then, but I have to work around every combination of > > versions to make a useful app that doesn't have very stringent installation > > requirements: in pracitice this means 4 environments: python2.1 with pyxml, > > python2.1 standalone, python2.2 with pyxml, python2.2 standalone. > > > > I don't want a plethora of XML parsers with rich features, all of which are > > broken. I want *one* XML parser that can *reliably* transform a stream of > > bytes into a stream of nodes, and a text file into a tree of nodes. You haven't given any evidence to the effect that PyXML does not have this. A bug in cloneNode has nothing to do with parsing. > > You > > mentioned validatation in your post and I explicitly said that validation is > > worse than useless to me; in most cases I want to parse XHTML, which means > > dealing with lots of potentially DTD-violating stuff which is still "valid" as > > far as I'm concerned. Doesn't HtmlParser do the trick? If not, you could try dom.ext.readers.HtmlReader with a minidom implementation used to override the default. BTW, from what you're describing above, you are *not* parsing XHTML. If it violates the DTD, it is not XHTML. Period. Just say you're parsing "HTML" and don't mention a version. That's the only way to say it correctly ;-) > > Eventually I'll clean up the problem cases I'm having and submit them as bug > > reports, but right now it's not worth my time, because I really don't want to > > deal with the fragility of the PyXML or python-standard-library xml.* stuff. Well, no one can tell you what to do with your time, but such general comments are not very useful. It's not as if you posted 10 bug reports, then threw up your hands and said "I'm blowing this joint". You made one vague mention of a cloneNode bug, without even a bare test case. No one gets paid to develop PyXML, but if you come our way a bit, we're quite willing to help. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra ry/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitl… 1EA5A2CF4621C386256BBB006F4CEC [View Less]

3 3

[Twisted-Python] Re: Helps if I could type ... there is no reportlacb.com of course.
by Glyph Lefkowitz Sept. 6, 2002

Sept. 6, 2002

Hi, Laura, Andy, &c :), On Tue, 3 Sep 2002 13:09:28 +0100, "Andy Robinson" <andy(a)reportlab.com> wrote: > Hello Glyph, > > You might be interested to know of our pyRXP > parser: > > http://www.reportlab.com/xml/pyrxp.html Thanks for the reference. I think pyRXP looks pretty neat -- using existing language data structures rather than inventing an API (like DOM) certainly has its advantages. Personally I would have preferred something mutable, but I could see … [View More]

2 2

[Twisted-Python] Web MVC hello world difficulties
by Jonathan Lange Sept. 6, 2002

Sept. 6, 2002

Hello, I am trying to use Web MVC to create a simple page that has a form with a single text field. When something is entered into the text field, 'Hello World!' should be displayed in the greeting section. I cannot get it to work, the greeting field remains unchanged, and the value in the text field keeps being reset. Below is a pretty simple example that demonstrates my problem. Thanks, jml  <html> <head> <title class="title">Title will go … [View More]

1 1

[Twisted-Python] Can anyone recommend a sensible XML parser for Python?
by Glyph Lefkowitz Sept. 6, 2002

Sept. 6, 2002

So, I'm really pretty discouraged and disgusted with the state of XML tools that ship with Python today. Mainly, they do surprising and insecure things when I try to parse XML, and I don't understand how to tell what will and won't work between various versions of them. I think my requirements of an XML parser are pretty simple. Here are the basics of what I want it to do: * adhere to a subset of both DOM and SAX APIs for both event-based and synchronous processing of XML data … [View More]

2 3

[Twisted-Python] Re: [Twisted-commits] allow for the possibility that a bot's perspective already exists
by Glyph Lefkowitz Sept. 5, 2002

Sept. 5, 2002

On Thu, 05 Sep 2002 14:49:05 -0500, acapnotic CVS <acapnotic(a)twistedmatrix.com> wrote: > Modified files: > Twisted/twisted/words/service.py 1.63 1.64 > > Log message: > allow for the possibility that a bot's perspective already exists I think this *should* fail if the perspective already exists; otherwise you'd kick a user off if you tried to create a bot with their nick. -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead … [View More]

2 1

[Twisted-Python] [Fwd: Re: Twisted docs (was Re: Python IPC options)]
by Itamar Shtull-Trauring Sept. 2, 2002

Sept. 2, 2002

-------- Original Message -------- Subject: Re: Twisted docs (was Re: Python IPC options) Date: 2 Sep 2002 02:51:06 -0700 From: hwlgw(a)hotmail.com (Will Stuyvesant) Organization: http://groups.google.com/ Newsgroups: comp.lang.python References: <1030829572.943495(a)irys.nyx.net> <3D715160.2020109(a)itamarst.org_NOSPAM> <cb035744.0209011308.7b4b3ae2(a)posting.google.com> <3D728386.2060908(a)itamarst.org_NOSPAM> Itamar Shtull-Trauring <itamar(a)itamarst.org_NOSPAM… [View More]> wrote: > I take it you're going to volunteer some time to write > docs? We'd really appreciate it! ;) Okay I will try, but my TODO list is already very long. So it will be a weekend thingy and could take a while to produce something useful, besides I will have to learn Twisted first! What I propose is to show how to develop a medium sized application in the Twisted framework that uses a lot of Twisted's capabilities. It should have asynchronous *and* synchronous communication, *mobile* components and because of that a dynamic network. It should also show how to exchange data with a server / database via its URL on the internet. Also to be fun it needs a GUI so I will use Tkinter, I believe there are examples already how to combine Twisted with Tkinter. Tkinter seems to be the best choice since it is one of Python's included batteries and it is portable and I have some experience with it. Now what kind of application would that be? My idea for the application is a trader agent and its environment. It could be something like a simulation or a game where you have to program an automated trader agent that buys and sells stocks for you. The client should also have an interactive mode so you can do things manually too. There is a central market / database / server online all the time. First I need to set up a website that simulates a stock market, or maybe I can just use an existing one, have to see how stable the data are they produce. www.nyse.com? Does this kind of application show enough of Twisted's features? You have more ideas? Do you think some things are too hard or impossible? Demonstrated features --------------------- * Asynchronous communication: Updates from the market to the client (if it is online) in a send_and_forget fashion. * Synchronous communication: Buying and selling transactions * Mobility: The clients should be able to connect from anywhere and it should maybe be possible to relocate the market. * Dynamicity: See mobility. Also there will be an unknown number of clients at any time. * RPC: client <-> market, but maybe also perhaps client <-> client for forming trade groups? * GUI integration To show what a client does and to be able to do manual trading. * Remote debugging? Remote market profiling? Market logging? Have to go back to my real work now. What surprises me is that the Twisted people did not come up with a demo apllication like this already, the more I think about it the more fun it seems. I did see a MUD-something-application mentioned on the Twisted site, but could not find it. The trader application looks a bit more ``serious'' perhaps, better for public relations? Also make absolutely sure people using Windows can install everything they need with just doubleclicking an .exe or whatever. You can do it, Twisted already has that for the modules. Writing software for installing things and writing documentation is generally considered *boring* and uncool work among programmers. I know. Hope this helps inspiring you to do it and to look at it in another way? For now good luck with writing good docs about things I do not know about yet: Twisted deserves it. So one day it can become one of Python's included batteries too! :: A child of five could understand this! Fetch me a child of five. -- Itamar Shtull-Trauring http://itamarst.org/ Available for Python, Twisted, Zope and Java consulting [View Less]

1 0

[Twisted-Python] ReconnectingClientFactory & stopFactory
by Andrew Bennetts Sept. 2, 2002

Sept. 2, 2002

I think there might be a slight issue with the current client API. If the API is fine, the docs need improving! :) Say you've subclasses ReconnectingClientFactory to connect to a database in startFactory, disconnect in stopFactory. If takes several connection attempts, then multiple connections to the database will be opened and closed (assuming this factory is only constructing one client, which is the usual case, I suspect). The problem appears to be that BaseConnector (in twisted.… [View More]

3 4

[Twisted-Python] random security thoughts
by Glyph Lefkowitz Sept. 1, 2002

Sept. 1, 2002

Hi Twistedistanians, Here is some internal rambling I've been doing about fixing up PB to be more bulletproof. Apologies if it's not coherent to anyone else but I figured I'd better mention the idea on the list and see of someone smarter than me can fill in a gap or two :). So, I think I understand what the potential security problem is with PB -- specifically, it's in Jelly, because the way that types are registered with the serializer is a very primitive ACL. This violates POLA for all PB … [View More]

1 0

[Twisted-Python] Re: [Twisted-commits] fixed connectionLost calls to accept Failures. Read on, I've got gripes.
by Glyph Lefkowitz Sept. 1, 2002

Sept. 1, 2002

On Sat, 31 Aug 2002 11:54:08 -0500, radix CVS <radix(a)twistedmatrix.com> wrote: > I think all the methods that are returning CONNECTION_* should be _raising_ > them. "Return victorious or not at all". This has the benefit of useful > tracebacks in the Failure objects. Well, it was originally that way. However, it turns out that creating exception objects in Python, generating tracebacks et. al. is rather expensive. Losing connections happens a LOT. Since connectionLost is in … [View More]

1 0