From: Chuck E. <Chu...@ya...> - 2001-12-20 21:31:21
|
MiscUtils.DataTable now fully supports CSV files. It was lacking proper support for embedded quotes and newlines. The test suite has been expanded and I also tested some existing projects of mine. -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-31 18:36:52
|
+1 , but lets think through the actual API changes it would entail: * trans.request instead of trans.request(), trans.response.write(...) instead of trans.response().write(...), etc. * trans.request() and trans.response() would raise an exception, etc. * lots of changes to existing servlet code !!! though a conversion tool could ease migration * many 'properties' would be read only, which Python 2.2 handles quite gracefully. * some of the 'properties' are calculated properties that don't map directly to an attribute. Again, Python 2.2 handles this well. trans.session trans.servlet trans.request trans.response trans.application session.values ? request.cookies ? request.fields ? request.values ? request.rawRequest ? request.urlPath ? request.remoteAddress ? ... and lots more ... see http://webware.sourceforge.net/Webware/WebKit/Docs/Source/Summaries/HTTPRequest.py.html response.cookies ? response.headers ? response.size ? What about the internal attributes/methods that are underscored? Tavis |
From: Tavis R. <ta...@ca...> - 2002-01-18 17:48:38
|
thinking some more about the 'properties style' proposal ... One of the motivations for making the switch to 'properties' is to remove the performance costs associated with all the accessor methods. In cases where no calculations are done, 2 methods and an underscored attribute can be replaced with a single property. However, these 'quasi-properties' WON'T have docstrings associated with them! True 'properties' can have docstrings, but they require 2 methods and an internal underscored attribute. Thus, there's a conflict between speed and docstrings. Tavis |
From: <ir...@ms...> - 2002-01-18 20:23:34
|
On Fri, Jan 18, 2002 at 11:01:03AM -0800, Tavis Rudd wrote: > thinking some more about the 'properties style' proposal ... > > One of the motivations for making the switch to 'properties' is to > remove the performance costs associated with all the accessor > methods. In cases where no calculations are done, 2 methods and an > underscored attribute can be replaced with a single property. > However, these 'quasi-properties' WON'T have docstrings associated > with them! True 'properties' can have docstrings, but they require 2 > methods and an internal underscored attribute. Thus, there's a > conflict between speed and docstrings. Elaboration? There seem to be several ways to document a property. And what do you mean by quasi-property? One can argue that our current practice is quasi-properties. To create a property, you first write the get, set and delete methods (we already have the first two), then pass those and a docstring as arguments to the property() constructor. So we can do any of the following: 1) Leave the docstrings in the separate methods. Possibly more convenient when reading the source, but harder for introspection tools to find when dissecting the property. 2) Move all documentation into the property object rather than in the source methods. We'd have to put the documentation into a string variable first, or hardcode it as a constructor argument literal (ugh). 3) Have a wrapper for property() that concatenates the docstrings of the three methods, puts in section headers and separators, and passes that as the property's docstring. 4) Can properties have attributes? Functions and methods can. Perhaps we can add meta-information onto the property that way, if there's a need for that. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Tavis R. <ta...@ca...> - 2002-01-18 20:34:16
|
On Friday 18 January 2002 12:29, Mike Orr wrote: > On Fri, Jan 18, 2002 at 11:01:03AM -0800, Tavis Rudd wrote: > > thinking some more about the 'properties style' proposal ... > > > > One of the motivations for making the switch to 'properties' is > > to remove the performance costs associated with all the accessor > > methods. In cases where no calculations are done, 2 methods and > > an underscored attribute can be replaced with a single property. > > However, these 'quasi-properties' WON'T have docstrings > > associated with them! True 'properties' can have docstrings, but > > they require 2 methods and an internal underscored attribute. > > Thus, there's a conflict between speed and docstrings. > > Elaboration? See my response to Ian. > There seem to be several ways to document a property. > And what do you mean by quasi-property? One can argue that our > current practice is quasi-properties. By 'quasi-properties', I mean plain old attributes that might be turned into 'true properties' at a later date. |
From: <in...@fa...> - 2002-01-18 21:28:13
|
Hoi, I'm new here (just making the move from Java servlets and thus far incredibly happy with Webware) so please excuse me if I'm misunderstanding something. Howerver, I don't get why you want to move to (quasi-) properties style. IMHO, (grossly exagerated) code like obj.foo().bar().tar().boing()['idx'] is often an indication of brokenness and it would seem unfortunate to me to 'optimize' it and make the awful indirection less obvious by removing the braces. Shouldn't the question be why indirections like that are needed in the first place and to try to remove the necessity altogether rather than hiding it with syntactic sugar? regards -- Ingo Lütkebohle / in...@fa... http://fargonauten.de/people/ingo PGP encrypted e-mail preferred. Fingerprint follows 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B |
From: Chuck E. <Chu...@ya...> - 2001-12-31 21:45:32
|
On Monday 31 December 2001 11:48 am, Tavis Rudd wrote: > +1 , but lets think through the actual API changes it would entail: > > * trans.request instead of trans.request(), trans.response.write(...) > instead of trans.response().write(...), etc. Nice. > * trans.request() and trans.response() would raise an exception, etc. Which would make sense in the new format. > * lots of changes to existing servlet code !!! though a conversion > tool could ease migration I feel obligated that the project provide a conversion tool with the release that uses the properties style. I have 2 juicy projects I can test such a tool on and I'm sure there are others who would be willing to help with testing that. > What about the internal attributes/methods that are underscored? Most of the underscored attributes are to prevent name conflicts with their methods. Other underscored attributes are never exposed for reading by external users of the class and should remain so. Likewise for methods. Another interesting question: Can a script aid in the conversion of Webware, or is it better to just go line by line with the occasional search and replace? .response() --> .response ._response --> .response -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-31 22:00:48
|
On Monday 31 December 2001 13:45, Chuck Esterbrook wrote: > > * lots of changes to existing servlet code !!! though a > > conversion tool could ease migration > > I feel obligated that the project provide a conversion tool with > the release that uses the properties style. I have 2 juicy projects > I can test such a tool on and I'm sure there are others who would > be willing to help with testing that. ... > Another interesting question: Can a script aid in the conversion of > Webware, or is it better to just go line by line with the > occasional search and replace? > > .response() --> .response > ._response --> .response Alot of the conversions will be identical in the WebKit code and the servlet code so it would make sense to write a converter tool that could handle both. It should be able to do a dry/debug run before doing the actual conversion. For each file it would print each affected line before and after the conversion, so you can verify it's working properly. Speed's not an issue so you could just create a list of regexs and their substitutions then loop through every line searching for matches and doing all the conversions on the current line before moving on. That should easier to debug than doing a global find and replace. If we go ahead with this, it would make sense to use this transition to weed out any methods/properties that shouldn't be there, such as the methods of 'HTTPRequest' that assume too much about the url-decoding scheme. |
From: Ian B. <ia...@co...> - 2002-01-03 20:10:06
|
On Mon, 2001-12-31 at 15:45, Chuck Esterbrook wrote: > > * lots of changes to existing servlet code !!! though a conversion > > tool could ease migration > > I feel obligated that the project provide a conversion tool with the > release that uses the properties style. I have 2 juicy projects I can > test such a tool on and I'm sure there are others who would be willing > to help with testing that. My thoughts on converting: do it the easy way, change Servlet, HTTPServlet, and Page to use properties. Then create LegacyServlet, LegacyHTTPServlet, and LegacyPage -- and any others (LegacyTransaction, I suppose) -- that act like the old classes. The conversion tool will simply replace these modified classes with the new classes. Perhaps the classes should have the version number in them, like LegacyServlet06 (from version 0.6). Since on the first run, maybe Response and Request get converted, but not Transaction. So the person has some things from the old, 0.6 behavior, and some servlets written for 0.7. Then you do Transaction, and you have to leave LegacyServlet07 alone, and change Servlet to LegacyServlet07... I'm not sure. I'm not sure how to keep those legacy classes up to date, though -- they could become a pain. Especially since code like: def request(self): return self._request def setRequest(self, req): self._request = req Should become simple attribute access, which is fastest. However, LegacyTransaction would have to wrap this new Transaction, not just subclass it or something... though maybe with the clever use of __dict__... or maybe LegacyTransaction could be generated by simply giving it a list of attributes to wrap, and the getters and setters for those attributes could be generated. Smarter automatic conversion tools seem difficult and probably not robust. An editor with search and replace will do most of the work, with programmer oversight which will probably be necessary in any case. The only annoying part is that the translation x.setY(z) to x.y = z is hard to do in an editor. It can't be done just with regexes, though, as it has to understand nested expressions. Ian |
From: Chuck E. <ChuckEsterbrook@StockAlerts.com> - 2002-01-04 01:35:40
|
On Thursday 03 January 2002 12:13 pm, Ian Bicking wrote: > The only annoying part is that the translation x.setY(z) to x.y = z > is hard to do in an editor. It can't be done just with regexes, > though, as it has to understand nested expressions. Why would it have to understand nested expressions? Aren't setFoo() methods always invoked as statements? foo.setBar(blahblah) Something like: $\t+[A-Za-z0-9_]+\.set[A-Z][A-Za-z0-9_]*\(\.+\)^ I always get my regexes slightly wrong the first time, but the gist is: beginning of line one or more tabs identifier ".set" cap letter more alphanumerics "(" 1 or more characters ")" end of line I think regexes could handle that. If they couldn't, we could certainly deal with the situation with our own code. Then axe the "set", decap the identifier, replace "(" with " = " and kill the rightmost ")". foo.setBar(baz) foo.bar = baz Or am I missing something? Actually, if you did that blindly you would screw up the occasional setFooBar() that takes multiple arguments, assuming these exist in Webware. BTW Another thought is that Python comes with a module to translate source to AST nodes that can then be examined. If I remember right. But in general I agree with Tavis' comment that this could be done line by line. Also, I'm in favor and an "all the way" approach. e.g., a script that would translate 99% of code and mark problem spots with a tag that could be grepped for (assuming we didn't achieve 100%). -Chuck |
From: Ian B. <ia...@co...> - 2002-01-04 02:24:02
|
On Thu, 2002-01-03 at 19:35, Chuck Esterbrook wrote: > On Thursday 03 January 2002 12:13 pm, Ian Bicking wrote: > > The only annoying part is that the translation x.setY(z) to x.y = z > > is hard to do in an editor. It can't be done just with regexes, > > though, as it has to understand nested expressions. > > Why would it have to understand nested expressions? Aren't setFoo() > methods always invoked as statements? > > foo.setBar(blahblah) > > Something like: > > $\t+[A-Za-z0-9_]+\.set[A-Z][A-Za-z0-9_]*\(\.+\)^ Well, it could be something like .setBar(x+(y*10))... though that might not matter, since they will always be the only statement on the line. But more like: \.set[A-Z][A-Za-z0-9_]*\((.*)\)\s*^ You don't have to match the first part, which may be any expression (e.g., self.request().setFoo(y)). Of course, this won't work if you have done line continuation. I do that a lot, since I tend to just nest expressions a lot. Really, you have to do parenthesis-counting to deal with that. I.e., you have to parse, not do a regex. You could mark lines that include things like .setResponse( without the proper trailing ) -- I'm drawing a blank on just which methods are going to be replaced, since all I can think of is the multi-argument ones, so I'm not sure how long the expressions are likely to be. > I always get my regexes slightly wrong the first time, but the gist is: > > beginning of line > one or more tabs > identifier > ".set" > cap letter > more alphanumerics > "(" > 1 or more characters > ")" > end of line > > I think regexes could handle that. If they couldn't, we could certainly > deal with the situation with our own code. > > Then axe the "set", decap the identifier, replace "(" with " = " and > kill the rightmost ")". > > foo.setBar(baz) > foo.bar = baz > > Or am I missing something? > > Actually, if you did that blindly you would screw up the occasional > setFooBar() that takes multiple arguments, assuming these exist in > Webware. setHeader, setValue, etc. I think we'd just want to match the specific ones we're replacing. You could potentially replace (.*) with ([^,]+), which would avoid setHeader and such -- but if you are setting something to a list or tuple, it will give a false-negative. > BTW Another thought is that Python comes with a module to translate > source to AST nodes that can then be examined. If I remember right. Yeah, but we don't want to do that, do we? > But in general I agree with Tavis' comment that this could be done line > by line. > > Also, I'm in favor and an "all the way" approach. e.g., a script that > would translate 99% of code and mark problem spots with a tag that > could be grepped for (assuming we didn't achieve 100%). I mostly would worry that it could be fragile and wouldn't provide a stable transition -- after all, the translator is meant to make Webware a stable platform for development. For it to be stable, the transition has to work really well. With the less elegant technique of supporting the old interfaces through alternate classes, you can make a system that works really well (since it is only translating module and class names, and provides an interface we already understand), and is very robust. With all the possible ways the syntax can be represented, it's very hard to translate it -- what about PSP, or even code written in Cheetah? There's going to be dead-tree stuff out there that will enshrine a certain Webware interface. Even if the new interface is a clear improvement, it will still be easier for people if they can try older examples and such. If it's just to provide convenience for moving old servlets to new code, then a source-code-translator would be better, and it might be useful in conjunction with providing old interfaces as well. But I don't think convenience is the motivation for this backward compatibility, no? Ian |
From: Tavis R. <ta...@ca...> - 2002-01-18 18:45:37
|
more thoughts ... The motivations for moving to the 'properties style': ---------- * trans.request.fields['a'] is slightly easier to read and type than trans.request().fields()['a'] * it seems to require less code in the source files: i.e. we can get rid of most of the accessor methods * direct access is marginally faster than using accessor methods in cases where no calculations are needed The cons/risks as I see them: ------------- * this proposal requires extensive changes to existing code * the marginal speed benefits of direct access cannot be reaped without dropping some important docstrings * !!! replacing the obj.setFoo() methods with obj.foo = 1234 introduces a whole new class of bugs, in which someone might accidentally write obj.foa = 1234. This can be safeguarded against with the new __slots__ attribute, BUT __slots__ is new/immature and comes with lots of caveats (see http://www.python.org/2.2/descrintro.html). In particular, there is a strange dichotomy between __slots__ and __dict__. Furthermore, using __slots__ does not protect against this sort of error when using subclasses. IMHO, the implementation of __slots__ in Python 2.2 needs more work and using it is risky! With these things in mind I change my vote from +1 to 0 for the foo() accessor methods and -1 for the setFoo() methods. Tavis On Friday 18 January 2002 10:16, Chuck wrote: > Speed wasn't my motivation for properties. I just considered the > speed a bonus. > > My motiviation is getting rid of the vast majority of ()s and _s > and extraneous method declarations in Webware for something that is > faster to read and write as well as more Pythonic. > > You are right that doc strings are important though. I hope the > Python community provides a solution. > > > -Chuck On Friday 18 January 2002 11:01, Tavis Rudd wrote: > thinking some more about the 'properties style' proposal ... > > One of the motivations for making the switch to 'properties' is to > remove the performance costs associated with all the accessor > methods. In cases where no calculations are done, 2 methods and an > underscored attribute can be replaced with a single property. > However, these 'quasi-properties' WON'T have docstrings associated > with them! True 'properties' can have docstrings, but they require > 2 methods and an internal underscored attribute. Thus, there's a > conflict between speed and docstrings. > > Tavis > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Ian B. <ia...@co...> - 2002-01-18 19:01:01
|
On Fri, 2002-01-18 at 13:58, Tavis Rudd wrote: > > * the marginal speed benefits of direct access cannot be reaped > without dropping some important docstrings property() includes a docstring argument (the optional fourth argument). It's not as clearly visible, unfortunately, but it should still be extractable. Ian |
From: Tavis R. <ta...@ca...> - 2002-01-18 19:08:54
|
On Friday 18 January 2002 11:04, Ian Bicking wrote: > On Fri, 2002-01-18 at 13:58, Tavis Rudd wrote: > > * the marginal speed benefits of direct access cannot be reaped > > without dropping some important docstrings > > property() includes a docstring argument (the optional fourth > argument). It's not as clearly visible, unfortunately, but it > should still be extractable. I didn't explain myself clearly enough: Here's an example of 'quasi-properties', aka 'direct access', and no docstrings: class Transaction(object): def __init__(self, app, ...): self.application = app Here it is again with true properties and a docstring: class Transaction(object): def __init__(self, app, ...): self._application = app def _getApp(self): return self._application application = property(_getApp, None, None, 'docstring') This 'quasi-properties' approach is faster than the 'accessor-method' approach that Webware currently uses. The true 'properties' style is the equivalent to, or possibly slower than, accessor methods. Tavis |
From: Ian B. <ia...@co...> - 2002-01-18 19:21:12
|
On Fri, 2002-01-18 at 14:20, Tavis Rudd wrote: > This 'quasi-properties' approach is faster than the 'accessor-method' > approach that Webware currently uses. The true 'properties' style is > the equivalent to, or possibly slower than, accessor methods. Ah, I see. You mean the plain attribute style, which properties simulate. I feel like there's been proposals for adding doc strings to attributes...? Ah... it's PEP 224, which has been rejected. Guido proposed using a convention like: class Whatever a = 10 __doc_a__ = 'a is used for whatever' Usually I'd just summarize all the attributes in the class doc string. It's easier to read anyway, though it can't be automatically extracted. Ian |
From: Tavis R. <ta...@ca...> - 2002-01-18 19:24:33
|
On Friday 18 January 2002 11:24, Ian Bicking wrote: > On Fri, 2002-01-18 at 14:20, Tavis Rudd wrote: > > This 'quasi-properties' approach is faster than the > > 'accessor-method' approach that Webware currently uses. The true > > 'properties' style is the equivalent to, or possibly slower than, > > accessor methods. > > Ah, I see. You mean the plain attribute style, which properties > simulate. > > I feel like there's been proposals for adding doc strings to > attributes...? Ah... it's PEP 224, which has been rejected. Guido > proposed using a convention like: > > class Whatever > a = 10 > __doc_a__ = 'a is used for whatever' But then what about docstring processing tools like pydoc? > Usually I'd just summarize all the attributes in the class doc > string. It's easier to read anyway, though it can't be > automatically extracted. That works, but its not as clean as the current approach. And it increases the chances of the docstring being out of date. |
From: Ian B. <ia...@co...> - 2002-01-18 19:34:31
|
On Fri, 2002-01-18 at 14:36, Tavis Rudd wrote: > > I feel like there's been proposals for adding doc strings to > > attributes...? Ah... it's PEP 224, which has been rejected. Guido > > proposed using a convention like: > > > > class Whatever > > a = 10 > > __doc_a__ = 'a is used for whatever' > > > But then what about docstring processing tools like pydoc? Without any standard for attribute doc strings, no, pydoc wouldn't work. It seems like it would be very easy to add, though. > > Usually I'd just summarize all the attributes in the class doc > > string. It's easier to read anyway, though it can't be > > automatically extracted. > > That works, but its not as clean as the current approach. And it > increases the chances of the docstring being out of date. I don't think so, because plain attributes will usually be best defined in __init__, which is usually right next to the class docstring. The style: class Whatever: a = 10 is something I almost never use, except for a few boring constants. I usually do: class Whatever: def __init__(self): a = some derived value Putting it in the class docstring is as good a place as I can think of. Ian |