[TurboGears] Re: TurboGears has a Trac now
On Oct 2, 2005, at 10:20 PM, Kevin Dangoor wrote: Given the speed with which I could get a Trac running and some of Ian's convincing arguments, TurboGears now has a Trac. It won't be mentioned on the website until I get Ticket 5 done, however... (some documentation already has changes for the next version, and the web site docs need to reflect what people are likely to be using...) http://trac.turbogears.org/ BTW, does anyone know of an antispam solution for Trac? There are many very simple ways to stop most spammers. I used the preinstalled version of Trac on TextDrive, so I didn't have an easy way to go in and modify Trac's code directly... As far as I can tell, at this time trac itself is an antispam solution (by obscurity I guess). I've never seen a spammed trac instance. -bob
[TurboGears] Re: Kid and embedded javascript
On Oct 5, 2005, at 10:32 PM, [EMAIL PROTECTED] wrote: Hi, Kid is very strict. It got confused if I embedd javascript in the template and use a completely legal construct like : if (a 10) I believe it is the '' that is being interpretated as begining of tag. Using the comment out trick like the following doesn't help. That is actually not a perfectly legal construct in XML or XHTML, and Kid is an XML language. It does need to be escaped with entities or wrapped in ![CDATA[]]. -bob
[TurboGears] Re: PATCH - FormEncode requirment
On Oct 6, 2005, at 6:58 AM, Kevin Dangoor wrote: On 10/6/05, Matthew Scott [EMAIL PROTECTED] wrote: On 10/6/05, Kevin Dangoor [EMAIL PROTECTED] wrote: Hmm... I had no problem with getting the thirdparty packages. Alternatively, you can pick up the FormEncode trunk manually: http://svn.colorstudy.com/FormEncode/trunk/ Kevin Not sure if this is Lethalman's problem or not, but since I use svk quite heavily instead of svn, I thought I'd mention this anyway that svk does not have support for svn:external properties. Now this is something I am fully aware of and compensate for when necessary since I've been using svk for a long time, but it might be worth briefly mentioning the use/side-effects of svn:externals in any documentation that mentions the TurboGears svn repostory. That's too bad. It's also too bad that the two current mechanisms for browsing the repository (Trac and the basic index provided by the Subversion apache module) don't display properties, otherwise I could link to the current list of externals. On the plus side, you do know what versions of which packages are required because setup.py tells you. trac in svn shows properties -bob
[TurboGears] MochiKit 0.90 released
MochiKit 0.90 http://mochikit.com/download.html has been released! This release includes a new feature, some bug fixes. The new feature in 0.90 is JSON serialization and evaluation support via serializeJSON, evalJSON and registerJSON. 2005-10-08 v0.90 - Fixed ISO compliance with toISODate - Added missing operator.sub - Placated Mozilla's strict warnings a bit - Added JSON serialization and unserialization support to MochiKit.Base: serializeJSON, evalJSON, registerJSON. This is very similar to the repr API. - Fixed a bug in the script loader that failed in some scenarios when a script tag did not have a src attribute (thanks Ian!) - Added new MochiKit.DOM createDOMFunc aliases: H1, H2, H3, BR, HR, TEXTAREA, P, FORM - Use encodeURIComponent / decodeURIComponent for MochiKit.Base urlEncode and parseQueryString, when available.
[TurboGears] Re: Kid is Pain in the ( )*( )
On Oct 17, 2005, at 3:02 PM, Art wrote: Is there a way to make KID accept regular HTML and to be so uptight on proper XML. I have a bunch of older HTML pages that I'm trying to use in Subway but making it all XML compliant is a major pain. No. Or maybe going with cheetah would be easier or will it defeat the whole goal ? Run it through a utility that converts HTML to XHTML, e.g. tidy http://tidy.sourceforge.net. Your templates will be better for it. -bob
[TurboGears] Re: TG doesn't like 'content'?
On Oct 22, 2005, at 1:30 PM, Swaroop C H wrote: I'm facing a strange problem where returning dict(content='',) in any index() causes TG to cry but changing it to dict (someothername='',...) works. It looks like Kid has a few reserved names in the BaseTemplate that you can't use: write, serializer, serialize, generate, initialize, pull, content, transform -bob
[TurboGears] MochiKit 1.0!
MochiKit 1.0 is out the door: announcement: http://bob.pythonmac.org/archives/2005/10/24/mochikit-10/ download: http://mochikit.com/download.html svn tag: http://svn.red-bean.com/mochikit/tags/MochiKit-1.0/ Lots of changes, the coolest ones are the new examples: MochiRegExp - a Regular Expression explorer: http://mochikit.com/examples/mochiregexp/index.html Interpreter - a JavaScript interactive interpreter: http://mochikit.com/examples/interpreter/index.html The Interpreter is so cool for demonstration purposes that I'm thinking about putting together a screencast. That'll probably go out sometime tomorrow if I find the time. Enjoy! -bob
[TurboGears] Re: python 2.3
On Oct 28, 2005, at 12:20 AM, [EMAIL PROTECTED] wrote: Kevin Dangoor wrote: On 10/27/05, David Stanek [EMAIL PROTECTED] wrote: On 10/27/05, Leandro Lucarella [EMAIL PROTECTED] wrote: And list comprehension (but I don't know if TG uses list comprehension a lot). List comprehension is possible in P2.3. Sad to say that I currently use P2.3.3 :-( OK. So, it sounds like there's a fair number of people running 2.3. As far as I'm aware, none of TurboGears' dependencies require 2.4. So, here's what we can do: If someone submits a patch to TurboGears to fix the 2.4isms (probably just decorators and sets), I'll start producing 2.3 versions of TurboGears. I think I can do this reasonably and without a lot of work. If it does start to get to be onerous, I may ask for a volunteer to produce 2.3 versions, but I'm thinking it shouldn't be too bad. sets are available for 2.3 in default library. 2.4 only speeds them up with a C implementation. That particular workaround is easy: try: set, frozenset except NameError: from sets import Set as set, ImmutableSet as frozenset -bob
[TurboGears] Re: SVN Checkout Problem
On Oct 31, 2005, at 11:11 AM, SuperJared wrote: When attempting to check out TG: Fetching external item into 'turbogears/thirdparty/sqlobject/ ez_setup' svn: Unknown hostname 'svn.eby-sarna.com' Is anyone able to resolve that host? Looks like his DNS is down, but it appears that 64.239.5.21 is the correct IP address. If you toss that in your hosts file or equivalent you might be able to do it. -bob
[TurboGears] Re: SVN Checkout Problem
On Oct 31, 2005, at 12:52 PM, Phillip J. Eby wrote: Ian Bicking wrote: Now that Python has moved to svn, maybe there's an svn external that can be set up pointing to that server? Not yet; the name of the file in SVN is 'ez_setup.py', but you can only do an external to directories, not individual files. The other issue of course is that the eby-sarna SVN version is only updated when I actually make a release, which is not necessarily the same time at which I update the version numbers in revision control! So, I don't think I'll be changing this at the moment, without some thought as to how to keep it separate. Well you could always use a branch somewhere in Python SVN that has the same semantics as the eby-sarna SVN version... -bob
[TurboGears] Re: OT: Development olatform opinions (To Mac...?)
On Nov 4, 2005, at 5:42 AM, Kevin Dangoor wrote: On 11/4/05, Matthew Bevan [EMAIL PROTECTED] wrote: I've been using Gentoo Linux for the last year and a half without any trouble. It is, in fact, the only operating system I use, and it works better than anything else I could imagine. My workflow revolves around three applications, and three active windows, with Gimp thrown in there occasionally: Matthew makes a really good point here. If browsing and writing code are the main things you'll be doing, a modern Linux is likely a fine choice. Fast, stable, easy to use and install packages. You can do these types of things without much hassle at all. My Mac does a bunch of other things for me, though, that I am nearly positive would be far more difficult on a Linux box. I have all of my contacts in the standard Address Book that comes with the system. Those sync up with my cellphone via bluetooth and can also go to my ipod (same with my calendar entries). I use iPhoto and iTunes for their respective duties. Snapz Pro X and iMovie make things like screencasts easy. I use OmniOutliner for organizing myself and OmniGraffle for diagrams. I use PhotoShop from time to time when doing web graphics. And you can't take my Quicksilver away. I use TextMate for editing, and it is my favorite. But, I could use other editors if pressed into a corner (and would certainly stick to Eclipse if I was doing Java). With the possible exception of Quicksilver, there are doubtless programs that do similar things for Linux. I'd bet that they'd be a lot harder to set up and use day-to-day and likely have fewer features. That's the tradeoff. You pay more in both the hardware and software, but the experience in using it is better. Yeah, but what you pay is more than totally amortized by the time you save and/or productivity gained by not having to deal with Windows or Linux. My experience, anyway. -bob
[TurboGears] Re: Choice of video capture software and medium.
On Nov 2, 2005, at 8:27 AM, Kevin Dangoor wrote: On 11/1/05, Matthew Bevan [EMAIL PROTECTED] wrote: I find it pretty great that the 20-minute video and various feature show-offs for CatWalk are being done in video. Realtime demonstrations can often have more impact than written descriptions, however, I have problems with the choice of medium. On my wonderful 64-bit laptop, when I play those quicktime videos I get no audio. On the other hand, I have Macromedia Flash running without a problem. (A feat on 64-bit assisted by a binary version of Firefox). Have you tried VLC by any chance? It may not work with the codec that I've used for this incarnation of the video. I'm not sure, but VLC plays an awful lot of files. I am planning to try different codecs to improve compatibility for Linux users. If I had the money for Sorenson Squeeze, I'd generate SWFs. Or, if I was using Camtasia on Windows I could likely do it there as well. Camtasia has other features and is tempting... it's a pity it's Windows only. At the moment, I just don't have the time to try and wire up something like vnc2swf with audio on my Mac. ffmpeg can transcode to flv, which should be playable anywhere Flash or VLC are around. -bob
[TurboGears] Re: TurboTunes: new tutorial/screencast
On Nov 7, 2005, at 8:34 PM, Bob Ippolito wrote: On Nov 7, 2005, at 7:58 PM, Kevin Dangoor wrote: I've just posted a new tutorial called TurboTunes which shows off CatWalk a bit for people that haven't seen it. Ronald Jaramillo wrote the tutorial and created the sample application. This tutorial is a QuickTime (.mov) file with the video in H.264 and the audio in AAC. This combination provided high-quality results, small (19.3MB) file size and works with the latest QuickTime Player for Mac and Windows, as well as VLC and probably Mplayer. Give it a try and I'm sure you'll let me know if you have trouble viewing it! Posted it.. where? I don't see it on your blog on on the front page of turbogears.com. I may be blind, URLs help :) I had to look harder, it's relatively tucked away in the docs: http://turbogears.com/docs/TurboTunes/index.html -bob
[TurboGears] Re: TurboTunes: new tutorial/screencast
On Nov 7, 2005, at 9:12 PM, Kevin Dangoor wrote:
On 11/7/05, Bob Ippolito [EMAIL PROTECTED] wrote:
I had to look harder, it's relatively tucked away in the docs:
http://turbogears.com/docs/TurboTunes/index.html
D'oh! Sorry about making you dig around. There will be more prominent
links, but I just wanted some confirmation that it was functional.
I just gave it a look. The content is quite good, and the new codec
settings played great in QuickTime (it even looked fine scaled up
to fullscreen on my tibook).
Two things:
1. next time, it would be cool if you could say MochiKit with the
correct pronunciation ('mō ch ē kit.. like the Japanese mochi). For
some reason other people are saying it like you did ;) I'm planning
to do a screencast pretty soon showing off some of what MochiKit can
do (entirely from the interpreter example), but I think TG has a few
more eyes and ears on it.
2. In the loadJSONDoc code, you should be able to just do::
loadJSONDoc(artists, list);
... which would implicitly call queryString(list), notice that it is
a HTML node and call formContents(list) for its arguments:
(list.name, list.value) and build a URL like artists?song=2.
Anyway, that's what it's supposed to do. If it doesn't then that's a
bug and I'll fix it before 1.1 (I haven't tested it with SELECT lists
yet).
-bob
[TurboGears] Re: TurboTunes: new tutorial/screencast
On Nov 7, 2005, at 11:03 PM, Ian Bicking wrote: Kevin Dangoor wrote: I've just posted a new tutorial called TurboTunes which shows off CatWalk a bit for people that haven't seen it. Ronald Jaramillo wrote the tutorial and created the sample application. This tutorial is a QuickTime (.mov) file with the video in H.264 and the audio in AAC. This combination provided high-quality results, small (19.3MB) file size and works with the latest QuickTime Player for Mac and Windows, as well as VLC and probably Mplayer. Give it a try and I'm sure you'll let me know if you have trouble viewing it! Also of note: I've gone back to building the website from the trunk (I had been building from the 0.8 branch). 0.9-specific items (such as the new tutorial) are marked as such. This arrangement will hopefully make it easier for people running svn to find docs and for people who are running the current released version to see what's coming next. Spiffy; works fine with VLC for me. I like the rotating G. One data design note -- I don't think you should normally give length to StringCol (i.e., you should use TEXT). Fixed-length fields are a relic of the 80's; modern databases can and do deal pretty well with arbitrary length text fields. Except MySQL doesn't allow indexes on them. Dumb MySQL. In fact, if I remember correctly (and I may not), many databases will be more space-efficient with arbitrary length fields, because they don't preallocate the full length, but they frequently do for fixed length fields. Also, less typing! Yeah, and space efficiency is directly proportional to performance, because modern databases are almost always bound by IO. -bob
[TurboGears] Re: TurboTunes: new tutorial/screencast
On Nov 7, 2005, at 11:16 PM, Bob Ippolito wrote: On Nov 7, 2005, at 9:12 PM, Kevin Dangoor wrote: On 11/7/05, Bob Ippolito [EMAIL PROTECTED] wrote: I had to look harder, it's relatively tucked away in the docs: http://turbogears.com/docs/TurboTunes/index.html D'oh! Sorry about making you dig around. There will be more prominent links, but I just wanted some confirmation that it was functional. I just gave it a look. The content is quite good, and the new codec settings played great in QuickTime (it even looked fine scaled up to fullscreen on my tibook). Two things: .. another minor thing -- I don't think Apple has titlemarked share/title to steal :) -bob
[TurboGears] Re: TurboTunes: new tutorial/screencast
On Nov 8, 2005, at 6:45 AM, Kevin Dangoor wrote:
On 11/8/05, Bob Ippolito [EMAIL PROTECTED] wrote:
1. next time, it would be cool if you could say MochiKit with the
correct pronunciation ('mō ch ē kit.. like the Japanese mochi).
For
some reason other people are saying it like you did ;) I'm planning
to do a screencast pretty soon showing off some of what MochiKit can
do (entirely from the interpreter example), but I think TG has a few
more eyes and ears on it.
Hmmm... I couldn't even find a spot where I said MochiKit in this one.
Where was that?
There wasn't one
-bob
[TurboGears] Re: Anyone have a good pointer to SQLObject query usage examples?
On Nov 10, 2005, at 6:32 PM, anders pearson wrote: On 2005-11-10 21:08:46 -0500, Jeff Grimmett wrote: I'm having an aweful time with SQLObject. Oh, I get stuff out of it and all, but my code is very, very clumsy - I'm generally getting all of a particular model's objects, then filtering them in Python code. Very wasteful. What I'd like to do is construct queries that do the same thing so I can take advantage of SQLO's features. So here's one particular problem: CoreMenu = ['home', 'site', 'software',] Menu = Page.select(Page.q.name http://Page.q.name in CoreMenu) 'in' isn't supported by SQLObject directly it sounds like you want Page.select(OR(Page.q.name == home, Page.q.name == site, Page.q.name == software)) or, if CoreMenu is really something likely to change: Page.select(reduce(OR,[Page.q.name == m for m in CoreMenu])) I think you mean: Page.select(OR(*[Page.q.name == m for m in CoreMenu])) reduce(OR, ..) would give you something a bit different (but semantically valid in this particular case): OR(OR(Page.q.name == home, Page.q.name == site), Page.q.name == software) Also make sure to pay attention to the edge cases (one or zero elements in CoreMenu) if they're possible. Not sure how OR would handle zero or one arguments, but reduce sure doesn't like to see zero arguments with no initial value. -bob
[TurboGears] Re: Sprint at PyCon?
On Nov 13, 2005, at 1:16 PM, Kevin Dangoor wrote: I'm going to propose that we have a sprint at PyCon. http://us.pycon.org/TX2006/HomePage The sprints are February 27th to as late as March 2nd. (They have 4 days of sprints, but I've gathered that you can do less than that if need be.) If you're thinking of attending PyCon and would be interested and able to join in on a TurboGears sprint for some portion of those days, please (DON'T reply to this message, but instead) send a note to the turbogears-sprint list turbogears@googlegroups.com http://groups.google.com/group/turbogears-sprint Looks like you pasted the wrong sprint email address there.. :) -bob
[TurboGears] MochiKit 1.1 Intro Screencast
I put together an introductory screencast for MochiKit this week, presented via the interactive interpreter example: http://mochikit.com/screencasts/MochiKit_Intro-1 This screencast was recorded with Snapz Pro X 2 and was encoded with QuickTime using the H.264 video and AAC audio codecs. I've confirmed that it's playable with QuickTime 7 and VLC 0.8.2, but may very well be playable elsewhere. It weighs in at 22M for 13:24 at 640x480.. so you can probably stream it with any sort of broadband connection. If it becomes slow for whatever reason, there's a mirror at archive.org: http://www.archive.org/details/MochiKit_Intro-1 A script for the screencast is available here (though there are some minor differences, it's close enough): http://mochikit.com/screencasts/MochiKit_Intro-1.txt The screencast is in the public domain, and I have a lossless version (PNG video encoding, raw audio) available upon request (647M). Snapz Pro X: http://www.ambrosiasw.com/utilities/snapzprox/ QuickTime: http://www.apple.com/quicktime VLC: http://www.videolan.org/ -bob
[TurboGears] Re: Nevow STAN and Turbogears
On Nov 19, 2005, at 9:33 AM, Tim Lesher wrote:On 11/19/05, Michele Cella [EMAIL PROTECTED] wrote: That's only my personal opinion, but doesn't this completely break theMVC paradigm? Personally I don't really like to have view code mixedwith my controller code. I agree. Stan is one of the big things that turned me off from Nevow. Then apparently you didn't look very hard at it! Stan is an option, but so is an XML templating language and whatever else you want to hook in. Nothing in Nevow really encourages or requires usage of Stan.-bob
[TurboGears] Re: Suggestions for new stuff in stdvars
On Nov 20, 2005, at 11:36 PM, Dan Jacob wrote: I was thinking of some useful functions/variables that could go into stdvars cycle(items, *args): generator that returns (index, item, looped_value) like this: tr py:for=index, product, css_class in std.cycle(products, 'row_0', 'row_1') py:attrs=class=css_class td.../td /tr cycle is a little confusing because it's in itertools.. here's how that would be written as a generator with existing Python constructs (of course you'd want to bring in the itertools stuff to a shorter namespace). itertools.izip(itertools.count(), products, itertools.cycle(row_0, row_1)) -bob
[TurboGears] Re: One connection per request ?
On Nov 28, 2005, at 1:38 PM, Jorge Godoy wrote: Steve Bergman [EMAIL PROTECTED] writes: Wait a minute. I'm not sure what limitations CherryPy/Http 1.0 have, but it is perfectly OK to have multiple *connections* to the same port. It's even OK to have multiple connections to the same port from the same remote host. Only 1 server can *listen* on a particular port, however. Then you either multiplex the connection or fork it to another port. You are very confused. Forking and sockets have nothing to do with each other. In the CherryPy case, it isn't even forking, it's threads. You should read up on TCP instead of confusing everyone else. What's happening here is that CherryPy isn't eagerly closing down the TCP sockets as quickly as Apache is apparently doing. No more, no less. If the connections were to remain open with Apache you'd see 20 connections from 20 different origin ports. CherryPy is only LISTENING on one port, just like Apache. This is almost definitely harmless, but it's probably worth taking a look into seeing why they're staying alive... it might just be HTTP Keep-Alive with a more optimistic timeout than what Apache is using. -bob
[TurboGears] Re: One connection per request ?
On Nov 28, 2005, at 2:08 PM, Jorge Godoy wrote: Jorge Godoy [EMAIL PROTECTED] writes: How can you get to answer to 2 simultaneous clients on the same port at the same time without multicast/broadcast then? Threads allow you to run concurrent things but they don't magically turn your physical medium into something that can carry more information at the same time. There's no need for physical medium here, you can only answer one request at a time on each port, this is what I was trying to say. I was thinking on another thing that involved more bandwidth, this is why there appeared the physical constraint on my message. Even with threads, you can't handle two different things at the very same time on the same port. And there's one process listening or writing to the port at a given time. If multiple threads request the information from this server process, the server is acting as a multiplexer. If forking -- I haven't read CP's code and I wasn't thinking specifically about it even tho it is the one that was involved -- them each process can bind to a port and handle everything from there, without the need of a multiplexer. You're confusing ports and sockets. Ports are just an addressing scheme, sockets facilitate the connection... all of what you just said here is totally bogus. -bob
[TurboGears] Re: a triviality: how do you like your URLs?
On Dec 5, 2005, at 12:58 PM, Ian Bicking wrote: Kevin Dangoor wrote: So, in a generic CRUD feature, what would you want your URLs to look like: 1) http://yoursite/articles/10/edit 2) http://yoursite/articles/edit/10 3) http://yoursite/articles/edit?id=10 http://yoursite/article-10?action=edit ... because 10 doesn't mean anything and articles isn't a very useful container, I prefer non-hierarchical URIs like article-10. You can usefully use that in several contexts, like / edit?obj=article-10, or /editor/article-10, or /article-10/edit Generally I don't like query arguments... Mostly because they're kinda ugly and are too closely related to form posting. I'd avoid them most of the time if it was easy to. The combined class-identifier scheme looks nice though, in a flat is better than nested kind of way. -bob
[TurboGears] Re: Using onload combined with py:if
On Dec 6, 2005, at 12:48 PM, Jeff Watkins wrote:
Jorge Godoy wrote:
How can I call a javascript funcion on page load when a given
python variable
is set? I tried:
body py:if=not variable
body py:if=variable onload=js_function(this.form
['some_widget'])
...
/body
I would probably address this like so:
script py:if=variable type=text/javascript language=javascript
function documentLoaded()
{
js_function(this.form['some_widget']);
}
if (window.addEventListener)
window.addEventListener( load, documentLoaded, false );
else if (window.attachEvent)
window.attachEvent( onload, documentLoaded );
else // sucky browser?
window.onload= documentLoaded;
/script
In these kinds of situations I prefer *never* to dynamically generate
code. What I do instead is simply place a hidden input element in
the page conditionally with whatever value is necessary, and the
JavaScript code in the page will know what to do with it. For example:
input type=hidden value=${message} id=show_message
py:if=show_message /
and the (probably external to the page) script would look something
like:
addLoadEvent(function () {
var msg = getElement(show_message);
if (!msg) return;
alert(msg.value);
});
... or if I wasn't using MochiKit
(function () {
var old_onload = document.body[onload];
document.body.onload = function () {
if (old_onload) old_onload();
var msg = document.getElementById(show_message);
if (!msg) return;
alert(msg.value);
};
})();
Of course, if the data you need to pass into JavaScript isn't just a
string, you should probably JSON encode it.
There are a couple reasons for using methods like this:
- It's hard enough to debug *static* JavaScript code
- You can test the JavaScript code independently from any server
stuff just by putting a test value in there and using py:attrs for
the dynamic value
- It's easy to do something with the data outside JavaScript using
only XML machinery (XSLT even).
-bob
[TurboGears] Re: Using onload combined with py:if
On Dec 6, 2005, at 1:19 PM, Jeff Watkins wrote:
Bob Ippolito wrote:
In these kinds of situations I prefer *never* to dynamically
generate code. What I do instead is simply place a hidden input
element in the page conditionally with whatever value is
necessary, and the JavaScript code in the page will know what to
do with it. For example:
input type=hidden value=${message} id=show_message
py:if=show_message /
and the (probably external to the page) script would look
something like:
addLoadEvent(function () {
var msg = getElement(show_message);
if (!msg) return;
alert(msg.value);
});
... or if I wasn't using MochiKit
(function () {
var old_onload = document.body[onload];
document.body.onload = function () {
if (old_onload) old_onload();
var msg = document.getElementById(show_message);
if (!msg) return;
alert(msg.value);
};
})();
Of course, if the data you need to pass into JavaScript isn't
just a string, you should probably JSON encode it.
There are a couple reasons for using methods like this:
- It's hard enough to debug *static* JavaScript code
- You can test the JavaScript code independently from any server
stuff just by putting a test value in there and using py:attrs for
the dynamic value
- It's easy to do something with the data outside JavaScript using
only XML machinery (XSLT even).
-bob
Bob, I'm not certain what you're trying to get at here. No one's
suggested dynamically generating Javascript code at all. The
closest anyone's come is including or excluding a script block
based on a Python variable.
Which is still dynamically generated code. The fact that it's coming
in and out dynamically probably implies that there's also dynamic
data ending up in there too. Getting the dynamic stuff escaped
correctly, the code debugged, etc. is just not worth it. Don't
generate code (especially with something that's tailored for
generating something else entirely with different rules).
And off topic, is there some particular reason you don't like using
the DOM methods for adding event listeners? Your non-Mochikit
solution for adding a load handler is particularly opaque even to
someone like myself who regularly teaches JavaScript programming.
It makes the problem seem harder than it really is. (Yes, I know my
example didn't account for multiple onload handlers, but I usually
throw an exception rather than deal with browsers that are so old
they support neither addEventListener nor attachEvent.)
Yes, because it's less code and it works the same in all browsers.
If I took out the enclosing function (so as not to pollute the window
namespace) and the onload chaining, then it would be the simplest
version by far. I did those things because it's generic and
unobtrusive to other scripts, if it was my page and I knew what else
was in it then I wouldn't have bothered.
document.body.onload = function () {
}
rather than
if (some capability) {
callSomethingWithThreeArguments();
} else if (another capability) {
callSomethingWithTwoSimilarButNotIdenticalArguments();
} else {
fallBackToSomethingElseIfWeCare();
}
-bob
[TurboGears] Re: Turbogears enhancement proposition hash_random
On Dec 7, 2005, at 11:28 AM, Kevin Dangoor wrote: On 12/7/05, Kevin Dangoor [EMAIL PROTECTED] wrote: If we were adding something for this explicit purpose, I'd prefer to add a flag to the url function and then have TurboGears eat the incoming tg_random variable so that you don't need to add another parameter to your methods. FYI, I've opened ticket 196 to implement this solution. It's a small enough task that I've targeted it for 0.9. Why not just set the cache headers correctly instead? -bob
[TurboGears] Re: Turbogears enhancement proposition hash_random
On Dec 7, 2005, at 1:30 PM, Jonathan LaCour wrote: On Dec 7, 2005, at 3:58 PM, Bob Ippolito wrote: If we were adding something for this explicit purpose, I'd prefer to add a flag to the url function and then have TurboGears eat the incoming tg_random variable so that you don't need to add another parameter to your methods. FYI, I've opened ticket 196 to implement this solution. It's a small enough task that I've targeted it for 0.9. Why not just set the cache headers correctly instead? I tried this repeatedly, and never was able to get it working with IE. The only solution I have found that works is sending a timestamp in the URL (which is similar to the proposed hash solution). Have you had a different experience with XMLHttpRequest and caching in IE? If so, exactly what headers did you have to send? This would be a much more elegant solution if it actually works :) Setting Expires should work, but I don't have a Windows box in front of me to confirm that I'm remembering it correctly. -bob
[TurboGears] Re: Ruby book sales surpass Python
On Dec 8, 2005, at 5:27 AM, Kevin Dangoor wrote: Interesting article over at Tim O'Reilly's site: http://radar.oreilly.com/archives/2005/12/ ruby_book_sales_surpass_python.html There's a fair bit of discussion about Rails and the Python web frameworks (including our own). I'll have more to say on this topic soon. I haven't read any of the Ruby books, but I was never very happy with any of the Python books... so this doesn't come as a big surprise to me. -bob
[TurboGears] Re: making an exe
py2exe uses console, windows, service, or com_server. script is ignored. On Dec 9, 2005, at 9:32 AM, Kevin Dangoor wrote: sadly, no... I mean script = toddswiki-start.py, Kevin On 12/9/05, martin [EMAIL PROTECTED] wrote: you mean: scripts = [toddswiki-start.py], ?? -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: New devcast: TurboGears Widgets
On Dec 13, 2005, at 12:19 PM, Damjan wrote: From the new Devcasts page: http://www.turbogears.org/docs/devcasts.html Ahh, what's with python developers and H.264 QuickTime... Can't you use some more standard format ... that works on Linux for example. H.264 is an excellent codec for encoding this kind of material, and it's an open standard. It's also very easy to encode from Mac OS X, because QuickTime has support for it. It works fine if you play it with a recent version of VLC. You can probably also use MPlayer. The key is just to use something new enough. -bob
[TurboGears] Re: Comparison operators in a Kid template
On Dec 13, 2005, at 1:00 PM, Simon Belak wrote: Brian Beck wrote: David Stanek wrote: On 12/10/05, Kevi But I am not sure how good of an idea this would be. I'll bring it up on the Kid mailing list after I think about it for a bit. I brought it up on there a few days ago, and I think the developers value the always-valid-XML feature quite highly. Personally I think that's just a checklist feature and doesn't actually help developers. The able to write actual Python in your templates is a much more valuable feature to me, so I'd like to see it changed... You can always use operator.lt() A bit messy perhaps but automatic validation (even relatively minor such as XML validity) is not to looked down at either. Maybe lt, gt, le, ge should be available directly? I guess there's always cmp.. lt: cmp(a, b) == -1 gt: cmp(a, b) == 1 le: cmp(a, b) != 1 ge: cmp(a, b) != -1 -bob
[TurboGears] Re: New autocommit style with tg-admin shell
On Dec 13, 2005, at 2:14 PM, Jorge Godoy wrote: Jared Kuolt [EMAIL PROTECTED] writes: I just have to wrap it with hub.being() and hub.commit() and it works but I got really frustrated trying to figure that out. Thoughts? I think this change is surprising everyone and making some parts of TG unusable without resorting to other tools (such as creating users to use with the identity framework). One solution is just to make the TG shell do something like this: hub.begin() try: execute_input() hub.commit() except: hub.rollback() raise The psql tool for PostgreSQL does something like this. Autocommit is implemented by the client, not the server. I guess what would be needed is for the tool to have before-input, after-input, and on-exception hooks, and for a hook to be written that keeps a weakref to all hubs so that it can do this. I'm of course assuming that hubs support nesting of transactions, because it would be even more surprising if users couldn't manually do them! Otherwise you'd need some way to disable the hook if it's detected that the hub is currently in some kind of transaction. -bob
[TurboGears] Re: Quick MochiKit Hack
On Dec 15, 2005, at 7:50 AM, Arnar Birgisson wrote: 2005/12/14, Gunfighter [EMAIL PROTECTED]: MochiKit has a ton of great features. A feature I've found helpful when working with my TG app is the interactive interpreter as demonstrated on the MochiKit site: http://www.mochikit.com/examples/interpreter/index.html Nice. I use this: http://www.squarefree.com/shell/ on by bookmarks toolbar. This opens a js shell running in the context of your current page so you can call any function and inspect any variable. Very handy.. Unfortunately, the squarefree shell bookmarklet is absolutely worthless unless you're in Firefox or Mozilla. The MochiKit interpreter works everywhere MochiKit does, which includes (at least) Safari, IE, and Opera. -bob
[TurboGears] Re: Combine TG and Subway?
Not to mention that Kid can't do CSS. Even Zope, which was (to my knowledge) the first framework to use attribute-based templating, needs to break down and use DTML to generate other document formats such as CSS. It's a pretty bad idea to generate CSS or JavaScript anyway. Why would you ever need to? Especially because you probably wouldn't end up doing it correctly if you tried, because all these langauges have different escaping rules. -bob
[TurboGears] Re: Combine TG and Subway?
On 12/22/05, Bob Ippolito [EMAIL PROTECTED] wrote: It's a pretty bad idea to generate CSS or JavaScript anyway. Why would you ever need to? I don't know about you, but I regularly wish I could set variables in CSS, mostly for colors. Inman has a php package that does this and I've seen it mentioned in several places besides just on his site. When was the last time you wanted to do this? What was the use case? If there are just a few different colors, you can always use separate css files (either just copies, or three files.. a base file and two with @imports and the custom colors). If it's really dynamic every page load then the css declarations are probably better off ending up in the html anyway. That way you can cache the static parts of the css and the dynamic parts definitely won't get cached since they're not in a separate file. -bob
[TurboGears] Re: Egg on my face...
Can someone give me a URL or a history on why Egg is used to package TurboGears if so many distributions have a problem with it... I ask because I have moved my laptop form Windows to FC4, and I find, with quite a bit of humor and frustration, that, although TurboGears installed on Windows without a hitch, it is harder to install on linux than on Windows... Not a good sign... Without eggs, TurboGears wouldn't really be possible. Its dependencies are too many and too new to make it practical to install any other way, not to mention the fact that it takes advantage of entry points and such. There are two problems that managed package systems have with eggs: 1. Documentation. 2. Managed packages don't have the EGG-INFO metadata. Both problems are pretty much solved, but it will take some time to trickle down. You can find more information about eggs and how to effectively use them on the wiki page for EasyInstall: http://peak.telecommunity.com/DevCenter/EasyInstall You should pay attention to the virtual python section, as that's the least painful way to do it on platforms with managed python packages. FWIW, OS X installation is also painless as-is. -bob
[TurboGears] Re: Egg on my face...
Bob Ippolito wrote:
Can someone give me a URL or a history on why Egg is used to package
TurboGears if so many distributions have a problem with it...
I ask because I have moved my laptop form Windows to FC4, and I find,
with quite a bit of humor and frustration, that, although TurboGears
installed on Windows without a hitch, it is harder to install on linux
than on Windows... Not a good sign...
Without eggs, TurboGears wouldn't really be possible. Its dependencies
are too many and too new to make it practical to install any other way,
not to mention the fact that it takes advantage of entry points and
such.
There are two problems that managed package systems have with eggs:
1. Documentation.
2. Managed packages don't have the EGG-INFO metadata.
Both problems are pretty much solved, but it will take some time to
trickle down. You can find more information about eggs and how to
effectively use them on the wiki page for EasyInstall:
http://peak.telecommunity.com/DevCenter/EasyInstall
You should pay attention to the virtual python section, as that's the
least painful way to do it on platforms with managed python packages.
FWIW, OS X installation is also painless as-is.
-bob
I'm running Ubuntu and the most painless solution I've found (at least
for me) it's to install every thing egg-related on /usr/local, I've put
this on my .pydistutils.cfg:
[install]
prefix=/usr/local
[easy_install]
site-dirs=/usr/local/lib/python2.4/site-packages
then when I need to install/upgrade I do it by using sudo, if for some
reason I need to remove something by hand I can find it under
/usr/local without the fear of removing the wrong thing.
Virtaul python was not the best for me since it copies many packages
and you need to have an alias to your virtual python executable, but if
you don't have root access then it's most probably the best solution.
Copies are a good thing because they are the specific version that has the
egg metadata, which is usually newer than what your managed package has.
In your configuration, you'll probably get different packages with import
foo and require('foo'); import foo. That's confusing.
-bob
[TurboGears] Re: simple_json now in use
I'll have decoding in simple_json for 0.2. It's almost done... need to hammer out a bug or three and write real tests. -bob On Dec 25, 2005, at 8:24 AM, Kevin Dangoor wrote: OK. I wasn't aware of that. Feel free to add the json-py requirement back in (or I'll do it when I get a chance). Kevin On 12/25/05, Jeff Watkins [EMAIL PROTECTED] wrote: The new AjaxDataController expects all object data to arrive in JSON format. I was using json-py to parse the incoming JSON data. In keeping with the One Way To Do It, I think whatever JSON package TurboGears supports, MUST encode and decode JSON formatted data. Otherwise, developers will be forced to find an alternative solution for JSON. On 24 Dec, 2005, at 9:12 pm, Kevin Dangoor wrote: At the moment, TurboGears doesn't actually have anything that depends on incoming JSON (that I'm aware of... CatWalk, perhaps?) You can make REST-style requests just fine without being able to decode JSON. -- Jeff Watkins http://newburyportion.com/ Computers are like Old Testament gods; lots of rules and no mercy. -- Joseph Campbell -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: simple_json now in use
Ok, it's done in svn with the obvious API (simple_json.loads/load), which takes an optional encoding kwarg to specify what encoding to expect input to be in. It must be an ASCII based encoding though, something like UCS-2 needs to come in as unicode because that affects more than strings. The encoder in 1.0 encodes as ASCII represented as str instances by default (using \u escapes), you can turn that off and get 0.1 behavior by passing ensure_ascii=False, which will give you either a str or unicode string as output based on the normal Python str-unicode coercion rules. I've version bumped to 1.0 because it's basically done other than future performance tweaks and maybe a bugfix or two. It's already on svn and in CheeseShop. The advantages-by-design over json-py are: 1. MIT licensed 2. Correct and fully extensible encoder 3. Correct decoder with encoding options 4. Python 2.3 support 5. Probably faster (have not benchmarked at all) The decoder does take advantage of some undocumented sre API, which binds it to sre and CPython, but that's basically an academic restriction in this context. The tests are kinda lazy and require nose. It's just a big doctest in simple_json/__init__.py. -bob On Dec 25, 2005, at 5:40 PM, Bob Ippolito wrote: I'll have decoding in simple_json for 0.2. It's almost done... need to hammer out a bug or three and write real tests. -bob On Dec 25, 2005, at 8:24 AM, Kevin Dangoor wrote: OK. I wasn't aware of that. Feel free to add the json-py requirement back in (or I'll do it when I get a chance). Kevin On 12/25/05, Jeff Watkins [EMAIL PROTECTED] wrote: The new AjaxDataController expects all object data to arrive in JSON format. I was using json-py to parse the incoming JSON data. In keeping with the One Way To Do It, I think whatever JSON package TurboGears supports, MUST encode and decode JSON formatted data. Otherwise, developers will be forced to find an alternative solution for JSON. On 24 Dec, 2005, at 9:12 pm, Kevin Dangoor wrote: At the moment, TurboGears doesn't actually have anything that depends on incoming JSON (that I'm aware of... CatWalk, perhaps?) You can make REST-style requests just fine without being able to decode JSON. -- Jeff Watkins http://newburyportion.com/ Computers are like Old Testament gods; lots of rules and no mercy. -- Joseph Campbell -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: simple_json now in use
It's also API compatible with json-py, all you have to do is change the import.. e.g.:-import json+import simple_json as jsonHowever, json-py's API is horribly named and I would recommend a refactor towards the marshal/pickle-inspired API. This is trivial: change read(s) to loads(s) and write(obj) to dumps(obj).There are, of course, load and dump for file-like objects. Technically load is currently worthless because it just does loads(f.read()), but dump actually will write in chunks which may be useful in some conditions.-bobOn Dec 25, 2005, at 9:36 PM, Jeff Watkins wrote:Thanks very much, Bob. I'll convert the AjaxDataController to use the new API.On 25 Dec, 2005, at 7:21 pm, Bob Ippolito wrote:Ok, it's done in svn with the obvious API --Jeff Watkinshttp://newburyportion.com/Democracy n: A country where the newspapers are pro-American.
[TurboGears] Re: Combine TG and Subway?
On Dec 26, 2005, at 12:00 AM, fumanchu wrote: Perhaps it's something about Python itself, or perhaps my design skills have improved, or my sensibilities changed. But I should think you could find a way to say, fine, use Cheetah; if you don't use Kid, you don't get this nice i18n tool (unless you port it! ;). Your choice. I think it's worthwhile to make it easy to use Cheetah as an alternative... if for no other reason than it would give a lot of people a good reason to shut up. All of the ranting and raving for and against Cheetah makes me ill. Personally I find Cheetah to be a really gnarly choice for an HTML/ XML template language, but it seems like an OK choice for other content if you really can't get along with just string interpolation. I just don't find myself in that situation very often. However, I'm not writing other users' web apps, so I couldn't care less how funky their templates are. All I'm concerned with is that Kid (or something of similar design) is what's used in the core for doing HTML and XML. -bob
[TurboGears] Re: AjaxDataController
On Dec 26, 2005, at 1:32 AM, Robin Munn wrote: On 12/25/05, Jeff Watkins [EMAIL PROTECTED] wrote: If you're like me and do a lot of Ajaxy stuff, you'll be happy to hear that there is now a specific DataController for Ajax requests: AjaxDataController (bet the name comes as a surprise). This is *very* cool, THANK YOU! Now to persuade Bob Ippolito to add a postSimpleXMLHttpRequest() function to MochiKit. I tried a while ago, but I wasn't able to articulate a clear use-case. This looks like a very clear use-case, though. Bob? What do you think? Does this one use URL encoding or JSON? -bob
[TurboGears] Re: Combine TG and Subway?
On Dec 29, 2005, at 2:14 PM, Jorge Godoy wrote: Jeff Watkins [EMAIL PROTECTED] writes: I understand the difference between wire and infoset, but they're just not relevant to me. If I write a document that contains: script src=.../script I don't want my template processor to change that to: script src=.../ It doesn't happen here: script src=/tg_widgets/turbogears.widgets/calendar.js language=JavaScript /script script src=/tg_widgets/turbogears.widgets/lang/calendar-pt- utf8.js language=JavaScript /script script src=/tg_widgets/turbogears.widgets/calendar-setup.js language=JavaScript /script This is the code I view in Firefox, for the following template: script language=JavaScript src=/tg_widgets/ turbogears.widgets/calendar.js /script script language=JavaScript src=/tg_widgets/ turbogears.widgets/lang/calendar-pt-utf8.js /script script language=JavaScript src=/tg_widgets/ turbogears.widgets/calendar-setup.js /script My dev.cfg specifies xhtml-strict as output for Kid. It looks like you have a space between the opening and closing script tags, which it is probably preserving. -bob
[TurboGears] Re: Combine TG and Subway?
On Dec 29, 2005, at 2:35 PM, Jeff Watkins wrote:
Maybe I'm just being grumpy because I haven't had any sleep, but I
really hate template processors that modify anything I didn't ask them
to modify. In addition to fiddling with my tags when I didn't ask it
to, it uppercases everything. Ick.
The thing is that it's not a tool for handing text, it only
understands XML. By the time it parses the document, all of your
entities will be translated to unicode, attribute order is made
irrelevant, and empty tags are empty tags. It's *not* changing your
document with regard to the XML format.
If this was Python, you'd be asking for print {c: 'd', a:
r'b'} to look the same as the input expression, where Python's dict
hashing algorithm and string repr rules happen to print out something
quite different but absolutely equivalent.
-bob
[TurboGears] Re: Kid question
On Dec 30, 2005, at 4:35 AM, Jeremy Jones wrote: [EMAIL PROTECTED] wrote: This is basically in following form : a=iter(alist) zip(a, a, a) map(None, a , a, a) The gurus(one of the bot) said that it is very bad in that there is no contract saying zip/map would take one element from each iterable, in that order. There is only contract for the output(tuples, one from each iterables). Therefore, it is possible in some future version(though I very much doubt) that it can be implemented that 4(or whatever number) is taken from the iterables at a time, say for optimization purpose. Seems like worst case, you wind up with a mangling of the ordering. Actually, worse than that. You could get as (in your example above) of different sizes. That would be bad. The ordering I can live with. The variable sizesnot good. Point taken. I doubt they would do that as well. That would break Python's few surprises idioms. If you want guarantees, then use itertools.izip or itertools.imap. Their definitions prevent that kind of (EXTREMELY unlikely) optimization. -bob
[TurboGears] Re: Turbogears does not work with Python 2.4.2?
On Jan 2, 2006, at 1:45 PM, modmans2ndcoming wrote: +++ Traceback (most recent call last): File /usr/local/bin/tg-admin, line 5, in ? from pkg_resources import load_entry_point File /Library/Python/2.3/site-packages/setuptools-0.6a8-py2.3.egg/ pkg_resources.py, line 2192, in ? working_set.require(__requires__) File /Library/Python/2.3/site-packages/setuptools-0.6a8-py2.3.egg/ pkg_resources.py, line 503, in require needed = self.resolve(parse_requirements(requirements)) File /Library/Python/2.3/site-packages/setuptools-0.6a8-py2.3.egg/ pkg_resources.py, line 483, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: elementtree=1.2.6 ++ This is what I get. It looks like for some reason, when I have python 2.4.2 installed from Darwinports, OS X does not look there for it and tries to use python 2.3. If you're using Darwinports you probably want to make sure /opt/local/ bin is before /usr/bin and /usr/local/bin in your PATH. That's probably a script from an older installation, because $PREFIX/bin for the Darwinports python isn't /usr/local/bin. -bob
[TurboGears] Flash Remoting with Python and TurboGears
I threw together a little Flash Remoting prototype for TurboGears in order to play around with the AMF implementation in flashticle (mostly to make sure it was correct beyond the stuff I've found in FLV and SOL files). If anyone is interested in that sort of thing, the library code is checked in here (flashticle.turbogateway is the TG-specific gateway implementation): http://svn.red-bean.com/bob/flashticle/trunk The demo TurboGears app is here (currently just one trivial example adapted from some O'Reilly book): http://svn.red-bean.com/bob/turbogatewaydemos/trunk It will probably work to do easy_install flashticle==dev since I registered it at Cheese Shop, but I haven't tested that. I grab a checkout and do python setup.py develop. The demos package isn't registered, so you have no choice there :) As far as I know, this is the only working open source flash remoting implementation for Python. There's another one out there that's basically a literal translation of a Perl implementation (AMF::Perl) that was ported from a PHP implementation... but I didn't even bother to run it after a quick horrific glance at what unfinished Python code looks like when written by a Perl programmer that doesn't seem to be aware that there's an extensive standard library. There's currently no documentation, online examples, proper website, etc. However, if you need this sort of thing then the API is relatively easy to figure out and it's sure as hell easier than writing your own. -bob
[TurboGears] [JOB] Content portal developer
Our company, Mochi Media LLC, is in need of a web developer to put together a content portal site (ideally with the TurboGears stack) on a contract basis. Being located in the San Francisco bay area is a huge bonus, as is working knowledge of Macromedia Flash and JavaScript. If you're interested, please contact us off-list at: [EMAIL PROTECTED] Please include relevant experience (especially high volume web development work) and some code samples (open source is best). -bob
[TurboGears] Re: Flash Remoting with Python and TurboGears
On Jan 3, 2006, at 10:39 PM, Robin Munn wrote: On 1/3/06, Kevin Dangoor [EMAIL PROTECTED] wrote: On 1/3/06, Bob Ippolito [EMAIL PROTECTED] wrote: I threw together a little Flash Remoting prototype for TurboGears in order to play around with the AMF implementation in flashticle (mostly to make sure it was correct beyond the stuff I've found in FLV and SOL files). Neat! Now I just need an excuse to do flash remoting! Pardon my ignorance, but what exactly *is* flash remoting? Google is your friend. http://www.google.com/search?q=%22flash+remoting%22 -bob
[TurboGears] Re: nl2br for Kid?
Something like this, I guess:
span py:for=line in line.splitlines()${line}br//span
On Jan 5, 2006, at 12:58 PM, Jared Kuolt wrote:
Is there a simple solution for newline-to-br (nl2br) in Kid?
Simple explantation, I need something that will escape all HTML
entities then add a br/ at every newline.
Thanks in advance,
Jared Kuolt
--
[EMAIL PROTECTED]
[TurboGears] Re: Extending TG objects
On Jan 5, 2006, at 4:17 PM, Stephen Thorne wrote: I'm having a bit of problem with inheritance. Because of @turbogears.expose() I can't seem to be able to do this: class MyClass(ParentClass): @turbogears.expose(self, args): def foo(self): d = super(MyClass, self).foo() d.update(dict(bar='baz')) return d because of the double-decoration going on. Is this kind of behaviour even possible? How do I access the original, pre-decorated method in the parent? That should work perfectly fine, given a correct turbogears.expose call of course. How about you show a full example that doesn't work and also post the traceback? -bob
[TurboGears] Re: if you're running from svn...
On Jan 6, 2006, at 9:41 AM, Kevin Dangoor wrote: After updating to [459], you'll need the TurboKid plugin. You should be able to get that by running easy_install TurboKid or, if that doesn't work for some reason, easy_install http://www.turbogears.org/download/eggs/TurboKid-0.9.0- py2.4.egg You'll also need to run python setup.py develop python setup.py develop worked fine here, with no explicit installation step for TurboKid. -bob
[TurboGears] Re: if you're running from svn...
On Jan 6, 2006, at 12:20 PM, Kevin Dangoor wrote: On 1/6/06, Phillip J. Eby [EMAIL PROTECTED] wrote: FYI, as of setuptools 0.6a9, you can set [easy_install] find_links in setup.cfg and they will be honored by the develop command. So you should be able to get this to work okay even for stuff that's not in PyPI. Ahh! That's nice. So standard operating procedure henceforth when requirements change is just setup.py develop. cool. It might be good to toss an index.html in thirdparty and point to that in find_links as well, so when you svn up it'll update that as well. Now all we need is a version of setup.py develop that checks all dependent eggs to ensure they're up to date (and by default for find_links targets that are local). -bob
[TurboGears] Re: File upload blocks other requests
On Jan 7, 2006, at 10:09 AM, Jorge Godoy wrote: Bob Ippolito [EMAIL PROTECTED] writes: It would be great if TG's controller had a filter that did streaming. CherryPy's default is stupid. Isn't it better, then, to suggest changing CP's default? This way besides TG users CP users would also benefit from the change... No, it would break backwards compatibility... where in this case it doesn't matter much, because old applications don't subclass TG's controller. -bob
[TurboGears] Re: Json to Opera Error
On Jan 8, 2006, at 12:57 PM, Olivier Favre-Simon wrote: webwurst wrote: Any news on this Opera/Json-topic? I'm using Firefox (1.5) and Opera (8.5 and 8.0) with TurboGears-0.8a6. If i send Json-Data from TurboGears to Opera I get strage Error-Messages (includung some Eastern-Characters, similar to this http://www.mail-archive.com/mochikit@googlegroups.com/msg00148.html). This is an Opera bug, and it's been fixed in TG for some time now, but you'll need to use trunk or wait for 0.9 to see it. -bob
[TurboGears] Re: Exception reporting (was Re: Identity crisis)
On Jan 8, 2006, at 12:46 PM, Leandro Lucarella wrote: Marek Baczynski, el domingo 8 de enero a las 12:24 me escribiste: Cliff Wells napisal(a): *Much* easier to track down. I think a couple hours with grep searching for exception blocks and adding some code to print/log/ save the traceback would go a long way to making debugging apps easier. Of course, if you do much more than printing the exception, great care must be taken that *that* code doesn't raise an exception itself ;-) When I was playing with Twisted and Nevow, I absolutely fell in love how good the exception reporting was. Tracebacks (when allowed) showed not only the whole exception stack, but also (IIRC) several lines of context, all that with pretty html formatting. S nice. They probably use cgitb[1] from standard python distribution. It could be nice to integrate it to TG too... What we should do is this: http://blog.ianbicking.org/ajaxy-exception-catching.html -bob
[TurboGears] Re: Proposal: TurboGears extensions
On Jan 10, 2006, at 4:16 PM, Jeff Watkins wrote: I'd like to propose a new entrypoint for TurboGears: turbogears.extension. The entrypoint will be a function to call on startup that can register a filter or whatever. The first extensions would be the Visit Tracking and Identity framework. This way, if you don't want Identity and Visit Tracking, you don't easy_install them. Thoughts? I think it's a bad idea to activate some feature just because it happens to be installed. You should have to explicitly ask for those features to be activated somehow. Perhaps list the entry points in the dev.cfg/prod.cfg. PasteDeploy http://pythonpaste.org/deploy/ does something similar with its config files. -bob
[TurboGears] MochiKit SVN moving to svn.mochikit.com
I'm going to move the MochiKit SVN from http://svn.red-bean.com/ mochikit to http://svn.mochikit.com so that it's easier for me to manage. http://svn.mochikit.com has been a mirror of the red-bean repository for many months now, and has had consistently better uptime (with the bonus that the trac timeline updates instantly, etc.). In order to switch repositories, simply checkout again or use the following command from your checkout directory:: svn switch --relocate http://svn.red-bean.com/mochikit http:// svn.mochikit.com -bob
[TurboGears] Re: [mochikit] MochiKit SVN moving to svn.mochikit.com
On Jan 13, 2006, at 9:58 AM, Bob Ippolito wrote: I'm going to move the MochiKit SVN from http://svn.red-bean.com/ mochikit to http://svn.mochikit.com so that it's easier for me to manage. http://svn.mochikit.com has been a mirror of the red-bean repository for many months now, and has had consistently better uptime (with the bonus that the trac timeline updates instantly, etc.). In order to switch repositories, simply checkout again or use the following command from your checkout directory:: svn switch --relocate http://svn.red-bean.com/mochikit http:// svn.mochikit.com My mistake, it's not at the root: svn switch --relocate http://svn.red-bean.com/mochikit http:// svn.mochikit.com/mochikit -bob
[TurboGears] Re: [mochikit] Re: MochiKit SVN moving to svn.mochikit.com
On Jan 13, 2006, at 10:08 AM, Bob Ippolito wrote: On Jan 13, 2006, at 9:58 AM, Bob Ippolito wrote: I'm going to move the MochiKit SVN from http://svn.red-bean.com/ mochikit to http://svn.mochikit.com so that it's easier for me to manage. http://svn.mochikit.com has been a mirror of the red-bean repository for many months now, and has had consistently better uptime (with the bonus that the trac timeline updates instantly, etc.). In order to switch repositories, simply checkout again or use the following command from your checkout directory:: svn switch --relocate http://svn.red-bean.com/mochikit http:// svn.mochikit.com My mistake, it's not at the root: svn switch --relocate http://svn.red-bean.com/mochikit http:// svn.mochikit.com/mochikit Argh -- due to the software used to mirror the repository (SVN::Mirror), the UUID is different and svn switch isn't cool with that. Nevermind, you must checkout again. This is the last time I do something of this nature in the morning before coffee :) -bob
[TurboGears] Re: Fwd: [mochikit] Port of script.aculo.us
On Jan 13, 2006, at 2:06 PM, Diwaker Gupta wrote: For those of you not on the MochiKit list, I wanted to bring this up: Thomas Hervé has ported Script.aculo.us to MochiKit! I took a quick look through, and it's a good start. This is fabulous! TG and friends need a lot more visibility at this stage and this will help tremendously. Blog away! :) I'd wait until it lands in SVN to blog about it. This will be a MochiKit 1.3 feature. -bob
[TurboGears] Re: note to those following svn: nose now required
On Jan 20, 2006, at 9:31 AM, Jorge Godoy wrote: Soni Bergraj [EMAIL PROTECTED] writes: Maybe the tg-admin quickstart template should include a sqlite db uri relative to the project, so you can get right into the toolbox and get prototyping after a quickstart? Would also be nice to have a tool to migrate one DB URI to another, given a model module. I personally like that idea:) Me too. But even then, I don't expect sqlite to be a requisite for TG. Why not? SQLite is something most people should have anyway; it's the best tool for many tasks -- especially tests, as Kevin said. It's not heavy either, less than 250k as an egg. -bob
[TurboGears] Re: note to those following svn: nose now required
On Jan 20, 2006, at 10:20 AM, Jorge Godoy wrote: Bob Ippolito [EMAIL PROTECTED] writes: Why not? SQLite is something most people should have anyway; it's the best Because there are a lot of projects that don't need it. And TG works fine without it, just testing fails -- and we don't run tests on production environments. You also don't want your production environments to be very different from your development environments. tool for many tasks -- especially tests, as Kevin said. It's not heavy either, less than 250k as an egg. I'm not worried with space here... It just isn't needed for normal operation. Otherwise we'd start requiring MySQL, PostgreSQL, etc. that are also supported (I know it is *very* different, but why add a dependency that doesn't exist?)... Why care? If you weren't paying attention to the list or svn, you probably wouldn't even have noticed. Just because it is small I don't think it should be there. And since it is small enough and easy enough to install, one line at the docs would solve the problem: To run tests you'll need to run: easy_install sqlite I am still thinking about this new 'nose' requirement... It is nice for development environments, but why have it on a production server? It was optional before and is needed now... It's absolutely useful to have the capability to test on a production server, especially right before you deploy. So you propose that instead of adding a little code, we require users to read more documentation? That's backwards. The idea is to make things easier, and having something get installed for you is a hell of a lot easier than reading docs. I don't think that avoiding a couple unused files in a directory that you never look at on a production server is a very good justification for anything, especially not if it's in exchange for ease of use. I like having the tools, but if it is easy to install them, and it is in the docs, and they aren't required for normal operation, why requiring them all the time, even on a production environment? It's easier to require it than to document it and make people read the docs. People don't read documentation unless something goes wrong. TurboGears is great because it's easy to get up and going, the only thing you need to remember how to do is run tg-admin and adjust your db uri. To that end, I've proposed that the quickstart db uri should default to an in-project-dir SQLite database to remove that requirement for prototyping. It also makes the barrier to entry a lot lower for someone who just wants to download TurboGears and go through some of the tutorials. There's a shitload of things in Python and TurboGears that you don't use in a production environment, but it doesn't mean the space they take up on disk does any harm. They aren't additional security risks, they don't get in the way, and they don't make TurboGears harder to install or deploy. I really don't see any justified reason to avoid their inclusion. -bob
[TurboGears] Re: note to those following svn: nose now required
On Jan 20, 2006, at 5:27 PM, Michele Cella wrote: Setting the db uri (and at this point I would add executing tg-admin sql create) usually to your project dir is the step I hate. To address Jorge concerns, I would propose to not make SQLite a dependency (no problem for me anyway). Maybe we can try to import pysqlite and if we don't get an exception we can ask something like: Do you want turbogears to prepare a SQLite database for your project? [Yes] Yes, give me a db ready to go. Running tg-admin sql create doesn't do anything unless there's something in your model. Adding a tg-admin sql create button and/or checkbox next to Write model would be a nice addition to ModelDesigner though. There's no need to ask the question -- it should just put a SQLite DB URI in there (if pysqlite is installed). It won't create the DB until it needs to, and creating a SQLite DB is better than an error. If you have a need to manually specify a DB URI, you'd simply just comment out or change that line. -bob
[TurboGears] Re: Dynamic SQLObject classes
On Jan 21, 2006, at 2:11 PM, Jeff Watkins wrote: I have what sounds like a strange request, even to me: I'd like to create a SQLObject class on the fly. Imagine something like the following: def create_link_table( class1, class2 ): class LinkTable(SQLObject): class sqlmeta: table= link_%s_%s % (class1, class2) id= None obj1= ForeignKey( class1 ) obj2= ForeignKey( class2 ) LinkTable.createTable( True ) return LinkTable But I don't think this will work because of SQLObject's lame registry thing. I suppose I could put each generated class into its own registry, but that's even lamer. Any thoughts? I don't know the specifics of SQLObject, but you can do anything you need to do with regard to creating classes on the fly and whatnot with type's constructor. -bob
[TurboGears] ann: MochiKit 1.2
MochiKit 1.2 the ocho is now available! This release is the calm before the storm, it contains mostly bug fixes and minor functionality improvements -- but big things are coming soon. We have a signal/slot dispatch mechanism, a script.aculo.us port, a new testing system, non-browser compatibility (SpiderMonkey, KJS, SpiderMonkey, Rhino) and a normalized event object all in the works which will be hitting the trunk soon. For more information about the new features check out the mailing list and the trac instance. download: http://mochikit.com/download.html release announcement: http://mochikit.com/ann/MochiKit-1.2.html -bob
[TurboGears] Re: API documentation
On Jan 23, 2006, at 1:21 PM, Kevin Dangoor wrote: I'm planning to take a run through the tg code and update API docs while I'm at it. I'm not enormously fond of epydoc, and I think Fredrik Lundh's Pythondoc looks good: http://effbot.org/zone/pythondoc.htm Its default output is pretty readable and allows us to intelligently annotate the code (much like epydoc does). It looks like it'll be easy to format things however we wish, and Fredrik is actively working on it (as it is, I'm using a hacked version of epydoc, which no longer seems to be maintained). Though Pudge uses Kid templates, I'm not as keen on the output it produces and the fact that it doesn't allow the same kinds of annotations you can do with pythondoc. Something I *do* like about Pudge and hacked into my epydoc is the links to colorized source. Sometimes the source remains the best document, and having that a click away is a bonus. Well, Pudge is definitely a work in progress. I like the fact that the docs are reStructuredText more than anything.. and I think the docs for simple_json turned out pretty decently: http://svn.red-bean.com/bob/simplejson/trunk/docs/index.html The problem with Pudge is that you do need to hack it a bit in order to do what you want, but commit bits are pretty easy to come by. -bob
[TurboGears] Re: API documentation
On Jan 23, 2006, at 2:13 PM, Ian Bicking wrote: Bob Ippolito wrote: On Jan 23, 2006, at 1:21 PM, Kevin Dangoor wrote: I'm planning to take a run through the tg code and update API docs while I'm at it. I'm not enormously fond of epydoc, and I think Fredrik Lundh's Pythondoc looks good: http://effbot.org/zone/pythondoc.htm Its default output is pretty readable and allows us to intelligently annotate the code (much like epydoc does). It looks like it'll be easy to format things however we wish, and Fredrik is actively working on it (as it is, I'm using a hacked version of epydoc, which no longer seems to be maintained). Though Pudge uses Kid templates, I'm not as keen on the output it produces and the fact that it doesn't allow the same kinds of annotations you can do with pythondoc. Something I *do* like about Pudge and hacked into my epydoc is the links to colorized source. Sometimes the source remains the best document, and having that a click away is a bonus. Well, Pudge is definitely a work in progress. I like the fact that the docs are reStructuredText more than anything.. and I think the docs for simple_json turned out pretty decently: http://svn.red-bean.com/bob/simplejson/trunk/docs/index.html The problem with Pudge is that you do need to hack it a bit in order to do what you want, but commit bits are pretty easy to come by. Probably most of the TG developers already have commit, actually; Ryans been giving *.lesscode access instead of just one-per- repository. I certainly like ReST, and I like Pudge's layout generally. Certainly some layout things could use some work, but that's mostly just a matter of spit-and-polish, nothing fundamental. Annotations would be significantly harder. I've started creating actual HTML links to link items to each other, but it's a little crude -- fully annotated links would certainly be better. That said, doing post- processing on the generated HTML does not seem so bad to me (docutils people always seem to find this terrible, but it seems fine to me), and not too hard either. That's just the difference between, say, `turbogears.expose module-turbogears.html#expose`_ (which works now) and `turbogears.expose turbogears.expose`_ (which is I think is like the kind of links Fredrik is making). Heck, we could try to create another pass that creates his markup, and use his tools. I think he even suggested such stacking as a design goal. Hacking docutils isn't all that hard. In order to build the MochiKit documentation, I wrote a small script (barely over 100 lines of liberally spaced code) that uses publish_parts to: 1. Add two custom roles to docutils (mochidef for defining functions, mochiref for referencing them) 2. Insert some custom includes in the HTML output (the new JavaScript- generated TOC feature, custom CSS) 3. Walk a directory tree and create the docs. The script is here: http://svn.mochikit.com/mochikit/trunk/scripts/make_docs.py Here is an example of the output: http://mochikit.com/doc/html/MochiKit/DOM.html What Pudge brings to the party is the ability to find the reST in docstrings, discover the module layout, and nicely display the source code in reference to the functions. Adding features like annotations can be done relatively easily, because you don't even need to touch Pudge code to add roles to docutils. -bob
[TurboGears] Re: API documentation
On Jan 23, 2006, at 4:11 PM, Ian Bicking wrote: Bob Ippolito wrote: Hacking docutils isn't all that hard. In order to build the MochiKit documentation, I wrote a small script (barely over 100 lines of liberally spaced code) that uses publish_parts to: 1. Add two custom roles to docutils (mochidef for defining functions, mochiref for referencing them) 2. Insert some custom includes in the HTML output (the new JavaScript- generated TOC feature, custom CSS) 3. Walk a directory tree and create the docs. The script is here: http://svn.mochikit.com/mochikit/trunk/scripts/make_docs.py That's not hard at all. My understanding is that Frederik's markup might allow nesting, and I don't think you can generally nest docutils roles, right? Though in the cases where you might want to (which might not be many) it could potentially be faked with combination roles. I don't think you can nest roles, I also can't imagine why you'd want to... Here's the source file he's using: http://effbot.org/lib/zipfile.txt But I think the @@ stuff gets converted to markup later, which might be an easier place to intercept. That doesn't look too bad, except for the HTML. Ick. One thing that's interesting about his approach is that the links don't need to understand what their targets are -- i.e., you don't need special links for modules, or classes, or methods. That could be particularly useful for TG if it meant that it could link to document on other sites, maybe using the package as a key to a rool url, like sqlobject points to http://sqlobject.org/lib/, MochiKit to http://mochikit.com/doc/html/MochiKit/, etc. You can do that with just about anything. In fact, the MochiKit make_docs.py script does something awfully close to that. References that start with MochiKit. refer to other modules of MochiKit, so they end up at named anchors on other HTML pages. References that aren't fully qualified just point at a named anchor. It also prettifies the output of the reference such that the user doesn't see the fully qualified name, since that's generally just visual clutter. In other words, if the mochi_name function was a generic function or had some kind of registry, it could easily point elsewhere in URI space based on upon arbitrary rules as needed. -bob
[TurboGears] Re: API documentation
On Jan 23, 2006, at 4:20 PM, Jeff Watkins wrote: On 23 Jan, 2006, at 6:06 pm, Bob Ippolito wrote: Hacking docutils isn't all that hard. I would like to suggest that we choose something that doesn't require hacking. If it doesn't work easily, it won't get used. Documentation and tests (I'm guilty on this) is usually the last thing to get done because the fancy tools need hand-holding. Let's pick something that *already* works and run with it. Nothing already works. I've been doing Python for a few years now, and all the mature docs-from-source tools suck hard. The signal:noise ratio is like 0.001, and/or the docstring markup is stupid. I do not want my source code to be b@ugly/b. It's WAY more efficient for me to grep the source and read the docs in source form than to navigate a 2000 file three-frame HTML document tree. Docutils comes very close to being good as an external document tool, but it needs a couple lines of domain-specific roles in order to make cross-referencing work well. That's a pretty big barrier to entry, but the markup is excellent and the output is flexible. For MochiKit, it was more than worth writing forty lines of code or so to make that happen (most of the code revolves around just finding the doc files, not the roles). What's needed in this case is a doc-from-source tool, which pretty much leaves just Pudge and PythonDoc as decent options. Pudge has docutils behind it, but is nascent. PythonDoc is a bit more mature, but it requires inline HTML for any markup that isn't represented by the PythonDoc @tags (e.g. emphasis, tables, etc.). For an example of what docutils markup looks like in source code, you could take a look at some of simplejson's source: http://svn.red-bean.com/bob/simplejson/trunk/simplejson/encoder.py and the Pudge output: http://svn.red-bean.com/bob/simplejson/trunk/docs/class- simplejson.JSONEncoder.html http://svn.red-bean.com/bob/simplejson/trunk/docs/simplejson/ encoder.py.html?f=63l=277#63 For me, it was well worth a little hacking to make sure my (a) source wasn't fugly (b) the output is navigable. Compare this index page to TurboGears, for example: http://svn.red-bean.com/bob/simplejson/trunk/docs/index.html In this case, Pudge puts all the information you need in one place, **skipping over irrelevant modules, like the tests**, instead of just a long unfiltered list of modules with mostly meaningless comments (when there are comments). API documentation should absolutely not include tests or private APIs that the user doesn't need to know about. That's what the source is for. I had to make some slight changes to Pudge in order to make that happen, but nothing big, and I didn't spend very long on it. I'm not saying Pudge is painless, because it's not, but at least the output is useful. -bob
[TurboGears] Re: API documentation
On Jan 23, 2006, at 5:49 PM, Ian Bicking wrote: Bob Ippolito wrote: One thing that's interesting about his approach is that the links don't need to understand what their targets are -- i.e., you don't need special links for modules, or classes, or methods. That could be particularly useful for TG if it meant that it could link to document on other sites, maybe using the package as a key to a rool url, like sqlobject points to http:// sqlobject.org/lib/, MochiKit to http://mochikit.com/doc/html/ MochiKit/, etc. You can do that with just about anything. In fact, the MochiKit make_docs.py script does something awfully close to that. References that start with MochiKit. refer to other modules of MochiKit, so they end up at named anchors on other HTML pages. References that aren't fully qualified just point at a named anchor. It also prettifies the output of the reference such that the user doesn't see the fully qualified name, since that's generally just visual clutter. So you are doing `MochiKit.DOM.TABLE`:mochiref, right? then translating that to MochiKit/DOM.html#TABLE, and translating the text to TABLE (based on the namespace of the containing document, or always stripping the namespace?) Here's some examples that cover all of the cases that mochi_name currently handles: :mochiref:`MochiKit.DOM.computedStyle(elem, style, mozillaEquivalentCSS)` a href=DOM.html#fn-computedstylecomputedStyle(elem, style, mozillaEquivalentCSS)/a :mochiref:`computedStyle(elem, style, mozillaEquivalentCSS)` a href=#fn-computedstylecomputedStyle(elem, style, mozillaEquivalentCSS)/a :mochiref:`MochiKit.DOM` a href=DOM.htmlMochiKit.DOM/a It's of course rather specialized, but it's very easy to cut and paste the role I've written and do something slightly different for another purpose. All we need then is a global index of fully qualified names to target URLs, and either rewrite the pages (nice for static publishing) or do redirects (nice for linking). Personally I try hard to make sure stuff I do doesn't depend on arbitrary server-side junk, and that it's relatively friendly to search engines. I don't see any good reason to use a redirector here. It's not like we have a marketing department that cares about exit page information :) I'm really trying hard to not reimplement other people's stuff though ;) OTOH, if the redirector was in place then at least it would be HTTP-API compatible with Frederik's work. And I think one thing we all share in common is that we care almost solely about HTML output, and don't really care about PDF or whatever. docutils does have quite nice PDF output (via pdftex, anyway), but HTML is *way* more appropriate for this kind of document. On the other hard, one /theoretical/ advantage that PythonDoc has is that it would be possible to extend developer tools (IDEs and whatnot) to understand its tags, which contain semantic information that would be useful for tool tips, completion, etc. That's at a cost though, just like manifest typing in general. Practically, I can't imagine that happening any time soon. -bob
[TurboGears] Re: JSON chokes on Decimal value
On Jan 26, 2006, at 10:18 PM, Dan Jacob wrote: class Member(SQLObject): name = StringCol(length=45) billing_rate = CurrencyCol() @turbogears.expose(format=json) def get_member_data(self, member_id): member = model.Member.get(member_id) return dict(member=member) http://trac.turbogears.org/turbogears/ticket/472 -bob
[TurboGears] Re: RhubarbTart
On Jan 30, 2006, at 2:25 PM, Ian Bicking wrote: Kevin Dangoor wrote: Here's my philosophy on stuff like this: I aim for TurboGears to be best-of-breed. The definition of best-of-breed will change over time. (It'll also vary from person to person, but there's not much I can do about that.) As the best changes, I'd like to see TurboGears change with it. Of course, changes need to have reasonable migration paths and all of that, which is the primary limiting factor. But, the bigger the win, the easier it is to justify a slightly more painful transition. ... * Filters. CP-style filters could be implemented in RhubarbTart, but I'd rather just not. The filters in TG could be reworked or have extra interfaces to be phrased as WSGI middleware. I think the actual application-facing interface to things like Identity don't need to be changed, so this might not be an issue. Since TG uses decorators more than filters (for app-visible APIs), I think this is mostly OK as-is. In my experience, filters are a bad API anyway. Every time I've ever wanted to use a filter, it was for a particular URL, which isn't really supported without lots of jiggering. -bob
[TurboGears] Re: RFC: Mapping _ to lazy_gettext everywhere.
On Jan 31, 2006, at 1:21 PM, Jorge Godoy wrote: Michele Cella [EMAIL PROTECTED] writes: The best thing will probably be an automatized way of determining if _ should be mapped to gettext or lazy_gettext, I really have no idea if it's possible or not. It has to be that way from what I'm seeing here on some tests. For example, the format attribute for the CalendarDatePicker expects a string, so _ works but lazy_gettext doesn't. And you can't use _ due to the problems reported on ticket #485. json.write also seems to have problems with it, because it prints the class instance and not the translated string. jsonify is easy enough to fix -- just add another generic function that checks for that type and Does The Right Thing. This should work: http://trac.turbogears.org/turbogears/ticket/497 -bob
[TurboGears] Re: RFC: Mapping _ to lazy_gettext everywhere.
On Jan 31, 2006, at 4:32 PM, Jorge Godoy wrote: Bob Ippolito [EMAIL PROTECTED] writes: jsonify is easy enough to fix -- just add another generic function that checks for that type and Does The Right Thing. This should work: http://trac.turbogears.org/turbogears/ticket/497 Wow! You're fast! :-) Thanks Bob! I believe that from this patch you're +1 for this... Sounds like a practical thing to do. Lowering the barriers to i18n is key if you want any of us stupid Americans to implement it ;) Using the _ function is definitely the de facto standard, whether through gettext or other means. It's pretty easy to analyze code and build string tables if you're using _, too.. I wrote a trivial one a while back: http://tinyurl.com/b5bp7 -bob
[TurboGears] Re: setlike behavior
uniquelist describes what it means better than orderedset does... orderedset usually means something else. -bob On Feb 5, 2006, at 2:09 PM, Kevin Dangoor wrote: There's a question in your patch about setlike. The purpose of the setlike class is to act like a set (things only appear once), but remember the order that things were added in. setlike is a bad name, but orderedset isn't such a great idea either. setlike exists specifically for handling JSLink, CSSLInk, etc. objects. You only want them to appear once per page, but you want them to appear in the order requested (because it matters sometimes). Kevin On 2/5/06, Alberto Valverde [EMAIL PROTECTED] wrote: I've posted a patch for the new widgets API which you can use to avoid it: http://trac.turbogears.org/turbogears/attachment/ticket/490/ newbase_widget_vars.2.patch The discussion is at: http://trac.turbogears.org/turbogears/ticket/490 Hope i helps, Alberto. On Feb 5, 2006, at 1:09 PM, Max Ischenko wrote: 1. I don't like been forced to write boilerplate code like this: def update_data(self, d): d['headers'] = self.headers d['collist'] = self.collist d['getcol'] = self.getcol -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: run as cgi!?
On Feb 7, 2006, at 5:56 AM, Lee McFadden wrote: On 2/7/06, Robert Hicks [EMAIL PROTECTED] wrote: Correct me if I am wrong but when I check out the low end Python support for hosting companies Python is always offered as a cgi and not as mod_python. So what I am hearing is nope. Both python-hosting[1] and develix[2] (to name only two) offer Turbogears support. And anywhere that supports Rails should also be sufficient for TurboGears. They have very similar requirements. -bob
[TurboGears] Re: Cocoa and JSON and Turbogears
On Feb 7, 2006, at 9:40 PM, schwa wrote: Sorry about the blatant self publicising. I have some code that might be handy for anyone thinking about directly interfacing a Turbogears Application with Cocoa (on Mac OS X of course). I've written JSON serializer/deserializer classes for Cocoa and also have JSON_INPUT decorator that you can use in your TG controller methods to allow a method to take input via JSON data in the http body. I've blogged about here http://toxicsoftware.com/blog/index.php/weblog/entry/ cocoa_json_turbogears/ and here http://toxicsoftware.com/blog/index.php/weblog/entry/cocoajson/ Looks interesting, but your decorator is semi-broken. simplejson.read (and simplejson.write) are deprecated and are going to spew warnings every time you use them. They're cruft from json-py compatibility. The reason they're deprecated is because the methods read and write almost always means something entirely different in Python (e.g. file-like objects). You should be using loads/dumps (the same API as marshal and pickle). The most appropriate code would be simply this:: theDictionary = simplejson.load(cherrypy.request.body) Rather than:: theBody = cherrypy.request.body.read() theDictionary = simplejson.read(theBody) Additionally, JSON_INPUT is not a PEP-8 compliant name. It should be called json_input. -bob
[TurboGears] Re: semi-OT: TG on Intel Macs?
On Feb 13, 2006, at 3:03 PM, isaac wrote: Anybody have experience getting TG up and running on the new intel macs? I suspect it will work OK, although it would on the Python 2.3 that comes with the OS (how bad is that for somebody who learned it on 2.4?). So far Fink isn't ready for the switch, and I'm not sure if the other Mac sources of 2.4 is either...? If you know, please share. ;) Is there a good chance the source would compile without much hassle? The binary Python 2.4.1 distribution that most people are using works fine on Intel, albeit via Rosetta only. Python's sources do not compile for Intel out of the box, but we're pretty close to having those patches and a universal build ready. Check the past couple weeks of pythonmac-sig for more information. -bob
[TurboGears] Re: Sonoma Sunshine
On Feb 14, 2006, at 7:37 AM, SamFeltus wrote: Anyways, it bypasses all that JavaScript and HTML stuff. ( JavaScript in my minority opinion being an inferior version of ActionScript, open source issues aside ). That's not really true. ActionScript's eval is not the same as JavaScript's, so you cant add new code to the system at runtime that is not precompiled... this precludes writing an AS interpreter in AS, which is incredibly useful for debugging if nothing else. AS1 is horribly broken because it doesn't (didn't?) support closures properly, and I think its string comparison was broken too. AS2 fixes most of these problems, but all the manifest typing is hand- waving because it doesn't actually provide you with anything until AS3, where it provides some performance enhancements. I guess AS2 is better than the intersection of all features and the union of all bugs in common HTML+JS platforms, but it doesn't hold up so well if you compare it to a particular implementation like Rhino or SpiderMonkey. -bob
[TurboGears] Re: Application with SQLite won't quit
On Feb 16, 2006, at 10:26 AM, Mike Orr wrote: On 2/16/06, Kevin Dangoor [EMAIL PROTECTED] wrote: On 2/15/06, Mike Orr [EMAIL PROTECTED] wrote: Then I discovered if the server is not handling a request, pressing ctrl-C quits all the threads. But if it is handling a request, the threads remain. If I then press Stop in the browser, the threads still remain, and I have to kill them. Whereas if I kill the threads with extreme prejudice, the browser suddenly times out. I'd expected the threads to just halt when I press ctrl-C and the browser to time out immediately. But I haven't used a multithreaded framework for a while so I'm not sure this is possible. Still, the main thread can tell the others to hurry up and exit, no? You can use a global variable that tells the other threads to exit when they get around to it. I don't know of a way for the main thread to kill the other threads. That's one thing I never understood. Java does it, but Python claims it's impossible. You can send an exception to a thread from the another thread, but only from the C API (because the behavior is relatively dangerous). It probably wouldn't help much in this case anyway, because any C function (e.g. socket or database call) is going to block until it returns back to Python. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Application with SQLite won't quit
On Feb 16, 2006, at 11:45 AM, Gustavo Sverzut Barbieri wrote: On 2/16/06, Mike Orr [EMAIL PROTECTED] wrote: On 2/16/06, Kevin Dangoor [EMAIL PROTECTED] wrote: On 2/15/06, Mike Orr [EMAIL PROTECTED] wrote: Then I discovered if the server is not handling a request, pressing ctrl-C quits all the threads. But if it is handling a request, the threads remain. If I then press Stop in the browser, the threads still remain, and I have to kill them. Whereas if I kill the threads with extreme prejudice, the browser suddenly times out. I'd expected the threads to just halt when I press ctrl-C and the browser to time out immediately. But I haven't used a multithreaded framework for a while so I'm not sure this is possible. Still, the main thread can tell the others to hurry up and exit, no? You can use a global variable that tells the other threads to exit when they get around to it. I don't know of a way for the main thread to kill the other threads. That's one thing I never understood. Java does it, but Python claims it's impossible. Linux have pthread_kill(), but maybe it's too dependent on platform and Python doesn't support it. Java, AFAIR, does its own thread implementation but I may be wrong. I'm also looking for a solution in this area :-( You're out of luck, there is not and never will be a solution to this problem. It's simply not possible to safely kill a thread in Python without the consent of that thread, because it's not designed in a way that makes that a safe operation. Java was designed with that constraint, but I'm sure that even Java fails to do this if the runaway thread is stuck in native code. Using pthread_kill would be very bad -- imagine that the killed thread was holding the GIL at the time. Assuming the platform supported that function: you'd kill the thread, but you'd also deadlock Python because every other thread would wait forever on the GIL. IOTW, If you want killable execution contexts that don't require instrumentation, you must use processes. You have no other option. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Sonoma Sunshine pt 2
On Feb 17, 2006, at 7:15 AM, SamFeltus wrote: I stuck the old WXPython version up, I am gonna get it debugged and running on TG. New version is still at http://sonomasunshine.com/sonomasunshine/FrontPage.html also http://sonomasunshine.com/sonomasunshine/TestPage.html Are ya'll giving it some time to load, there are no preloaders yet. Looking at logs, some people definitely get all the files, others only get some. I think 1 problem might be too many large JPEG's, for now it depends on all JPEGs loading correctly to work. The loading needs error checking for certain. My connection is 11mbit (down, anyway), I gave it a few minutes, I don't think that's the problem :) Here is the JSON it is importing, how is that not technically JSON, I am confused by that? http://sonomasunshine.com/cgi-bin/write_json_static.py? pagename=FrontPage It's not JSON because your encoding code is broken (unless you're doing it by hand?!), like I said previously. You need to read the JSON spec more closely, or use a library that is actually correct (e.g. simplejson). In this particular document the following things deviate from JSON: 1. json_str= - not JSON. 2. license_mc.setts.text is not escaped correctly 3. notes_text_mc.setts.text is not escaped correctly 4. error_text_mc.setts.text is not escaped correctly If you take a look at the JSON spec you'll see that the string encoding should be: Any UNICODE character except or \ or control character. The important thing to note is that newline is a control character. In some of your other JSON documents (found by following the links I saw in the front page's JSON) I saw unescaped in text (like the Python code samples), which is broken by almost any JSON parsing rules because it would prematurely terminate the string. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Sonoma Sunshine pt 2
On Feb 17, 2006, at 1:19 PM, SamFeltus wrote: PS 1. json_str= - not JSON. I was just using FlashVars to import the JSON str, not aware of a better method. I can see right now hand editing the JSON is a BAD thing and the sooner all that editing is ported to TG the better. I think you can still use LoadVars and just parse straight off of the this.toString() in the onLoad instead of looking for a json_str property. You might also be able to use the XML object to do it. I haven't mucked with Flash and JSON before. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Sonoma Sunshine pt 2
On Feb 18, 2006, at 12:47 PM, SamFeltus wrote: Going back and making some changes to make it work correctly online (looking good on localhost sure is different from live on net). http://sonomasunshine.com/sonomasunshine/FrontPage.html It oughta (crosses fingers) work on OS 10.4 (Safari/Mozilla) and Windows XP(IE/Mozilla) with the following temporary vexations... Doesnt like www in the url That's probably a sign that you should be using relative URLs and/or implement crossdomain.xml properly. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: What licenses are all pieces of TurboGears under? Are all GPL compatible?
On Feb 28, 2006, at 5:13 PM, [EMAIL PROTECTED] wrote: TurboGears joins together a lot of different pieces. Do they all have GPL compatible licenses? What are they? Yes, RTFM: http://turbogears.org/about/license.html The cleanest thing to do if yes it seems would be to make the whole bucket of code a big GPL'd package if possible. Just curious and just my $0.02. Why the heck would someone want that? It's currently more free than GPL. It's not really distributed as a bucket of code anyway. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Ajax library scorecard: Mochikit gets a B+ :-(
On Mar 6, 2006, at 6:44 AM, modmans2ndcoming wrote: Can TG provide Rico as an option for the javascript kit? MochiKit didn't get a B+ for any technical reason, the scorecard states that This toolset provides a limited amount of dhtml compared with most of the others. It's not really fair to grade MochiKit on stuff it doesn't attempt to do, but whatever. It should probably be in the unrated AJAX only group. The stuff that MochiKit does do, it gets right. Rico would be a large step backwards in compatibility because it only partially supports Safari (I'd have to imagine its Opera support is worse). It definitely doesn't deserve the A- that the author gives it on those grounds. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: bike shed #1: config extension/dotted names
On Mar 7, 2006, at 3:47 PM, Ian Bicking wrote: Kevin Dangoor wrote: So, if there's another trick that we can use to make it look INI- like, but still function entirely like a normal Python module, I'm game for trying that out. Otherwise, given the constraints above, it sounds like people are interested in changing the extension. .pyini? pyc? (for python configuration -- just kidding!). For this file in particular I don't see any problem with Python syntax, or even a funny Python-like syntax (i.e., exec in a funny namespace -- though I'd be sure to test that in 2.3, since it acts differently on this stuff I think). At least as it isn't advertised as a Python module through the .py extension. Then it's just a matter of aesthetics. Of course, if it is aesthetics then that's a good sign that you can waste an unbounded amount of time. Maybe just do whatever now -- use what you have with a new extension -- and add another file extension later if you come to hate what you've made ;) I think that the only difference between 2.3 and 2.4 wrt exec namespaces is that you're allowed to use dict subclasses in 2.4. Not that you should.. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Safari and XMLHttpRequest encoding
On Mar 7, 2006, at 5:02 PM, Jonathan LaCour wrote: On Mar 7, 2006, at 2:50 PM, Jonathan LaCour wrote: Seems like I am the only one busy with email today :) Has anyone come up with a workaround to this problem: http://trac.turbogears.org/turbogears/ticket/186 ... its currently causing me great pain! I filed a bug against WebKit's bugzilla, but I would love to find a workaround, if possible. Isn't this irrelevant for JSON since simplejson escapes everything but ASCII? Well, I am not entirely sure. Its possible that the bug I mentioned isn't my problem, but I have a controller method that returns some unicode strings inside a dictionary. This controller method is being called by loadJSONDoc() on the client side, and the unicode string is being placed into a textarea. On Safari, I see escaped text. On Firefox, I see proper unicode strings. So, it seems like this may be the bug I mentioned, but I don't know for sure. Write a test case so that other people can see the issue. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Safari and XMLHttpRequest encoding
simplejson already escapes everything outside of ASCII to \u literals, which are certainly going to be interpreted correctly on the client side -- at least when using eval(( + json + )) or any other correct JSON parser. I want to see a test case because the problem definitely isn't where the original poster thinks it is... unless he is using a pre- simplejson TurboGears, in which case the bug was fixed when switching from json-py to simplejson. -bob On Mar 7, 2006, at 6:07 PM, Hiroki Ohtani wrote: Hi all, This is popular problem when we handle non-ascii charactor with AJAX or json. Safari and KDE Konqueror always mishanlde json charactor encoding. Workaround is : urlescape json string at server side and unescape json string at client side. Has anyone come up with a workaround to this problem: http://trac.turbogears.org/turbogears/ticket/186 ... its currently causing me great pain! I filed a bug against WebKit's bugzilla, but I would love to find a workaround, if possible. Isn't this irrelevant for JSON since simplejson escapes everything but ASCII? Well, I am not entirely sure. Its possible that the bug I mentioned isn't my problem, but I have a controller method that returns some unicode strings inside a dictionary. This controller method is being called by loadJSONDoc() on the client side, and the unicode string is being placed into a textarea. On Safari, I see escaped text. On Firefox, I see proper unicode strings. So, it seems like this may be the bug I mentioned, but I don't know for sure. Write a test case so that other people can see the issue. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Safari and XMLHttpRequest encoding
On Mar 8, 2006, at 6:49 AM, Jonathan LaCour wrote:
Write a test case so that other people can see the issue.
Okay, I created a simple test case as a TurboGears 0.9a1
application. It works fine in Firefox, but doesn't work properly in
Safari. You can download it at:
http://cleverdevil.org/testcase.tar.gz
I definitely could be doing something wrong, but if it works in one
browser and not another, that leads me to believe that its a bug in
the browser.
Looks like it's a bug in TG somewhere.. simplejson does the right thing:
import simplejson
print simplejson.dumps(dict(text=u'\u00bfHabla espa\u00f1ol?'))
{text:\u00bfHabla espa\u00f1ol?}
but TG does not:
import urllib
print urllib.urlopen('http://127.0.0.1:8080/test').read()
{tg_flash:null, text:¿Habla español?}
This is apparently Kevin's fault according to svn blame:
370 kevin class GenericJSON(JSONEncoder):
829 kevin def __init__(self):
829 kevin super(GenericJSON, self).__init__
(ensure_ascii = False)
In this revision:
http://trac.turbogears.org/turbogears/changeset/829
Supposedly this helps non-ascii characters through JSON, but it
doesn't have the intended result.
The right fix for #430 would've been to ensure unicode strings from
browser input, instead of ensuring potential garbage makes its way
into the JSON output. In this case, it would be a change to the way
URLs (at least the query string) are handled.
This could be fixed by making cherrypy.lib.parseQueryString look at
the resultant dict for keys that are outside of ASCII and decoding
them to UTF-8... or it could be done as a filter like the formencode
NestedVariablesFilter in startup.
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---
[TurboGears] Re: Open Question: Turbogears and scaling...
On Mar 17, 2006, at 3:17 PM, Robin Haswell wrote: my time has a cost and optimisation often buys less performance than, say, a Dell SC1425 Unfortunatly my time is not worth a IBM 64way mainframe (or I would be one happy hacker). Bigger machines help but as my comment said before this will give you only linear optimization at some point you will need _exponential_ optmizaitions. This also depends on the complexity of the data relationships that your application needs. You need a machine that is 64 times faster buy Nah mate you miss my point! Not bigger machines, *more* machines. A Dell SC1425 is a pretty low-end piece of kit, the idea is you use multiple machines. Let's say you have an application that is currently running at 100% above acceptable capacity. You can solve this problem in basically four ways: 1. Buy hardware that is twice as powerful 2. Perform optimisation, caching - etc. 3. A combination of the 1) and 2) 4. Buy another similar server and run them both In my experience, 4) is always the cheapest option, and requires less hassle than 2) and 3) (and less hassle is the TG way!). The trick is to make option 4 possible by asking questions like What will happen if I use two app or database servers - or both early on in the build process. I do this for everything and it's served me right so far :-) Part of my personal PHP standard library is some wrappers around session management and database handling that means: Scaling horizontally, what you list as 4, is the only real option. There's plenty of public record that shows that all the successful guys (Google and LiveJournal come to mind) are using lots of relatively cheap servers, rather than small numbers of giant servers. If you design for that, you'll never have a problem so long as you can afford to operate, and that's not so tough of a problem because the costs are at worst linear. With any other option, the price to upgrade grows exponentially and there's a ceiling on what kind of power you can even buy to run an app that is mostly serial. Good optimizations can do wonders in the short term, e.g. cut immediate hardware costs in half... but you get that anyway if you wait about a year. It's typically better to expand your service such that it maximizes profits, rather than optimize your service to minimize your overhead. There's only so low you can go with cutting your overhead.. but there's no well defined ceiling for maximum profits (look at Google!). -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Explain the implications of implicit transactions
On Apr 11, 2006, at 6:50 PM, Kevin Dangoor wrote: On 4/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I ought to pass object identifiers around for page to page rather than object themselves, then re-get the object from the database within the next page's code. Is this a correct observation, a necessary pattern? I actually think that this is more an observation about use of sessions than the implicit transactions. Generally speaking, implicit transactions do what you really want to happen anyhow. There are no guarantees about putting an SQLObject (or other kind of persistent object) into a session. Most persistent objects have some kind of association with the connection they were created from. From request to request, you can't count on that being the same connection. Hanging on to the object id is a good solution, imho. I don't know the specifics of how sessions work in TG, but there's no technical reason you couldn't put SQLObjects in a session correctly if sessions were treated kinda like a pickle store. The session- serialization for a SQLObject would simply be a reference to the class and the object's id. When you pull it out of the session from some other request, it would simply resurrect that object using the current connection. Personally I prefer the explicit by-identifier way and try and keep the state on the client instead of in a session (for a lot of reasons) but there's nothing inherently dangerous about the pattern that the user tried first (if the pieces fit together properly). -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: [mochikit]How to add onclick attr to DOM?
On Apr 20, 2006, at 1:34 AM, Henotii wrote:
I just follow the doc of mochikit, and use A({href:#}, test) to
add element successful.
But it seems can't work with A({onclick:test_func()}, test).
The output html just like this atest/a, and without the onclick.
Is there something wrong? And how can I add attr like onclick when
using MochiKit. The mochikit's doc is not very clear in this.
It should work if you use::
A({onclick: test_func}, test)
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---
[TurboGears] Re: Is Identity too much? I think so.
On Apr 23, 2006, at 8:44 AM, Jeff Watkins wrote:On 23 Apr, 2006, at 11:26 am, Alberto Valverde wrote:Also I should note that you don't *need* to undersand how they work in order to *use* them.On the other hand, if you need to understand the code that uses them, you'll NEVER actually know what the code does unless you understand EVERY instance of the generic function. It's impossible to look at the following code any actually know what it does:@generic()def flip_the_frobble(obj): pass...def clever_function(obj): flip_the_frobble(obj)What does clever_function actually do? It's impossible to tell, because you have no idea what versions of the generic flip_the_frobble have been created.When languages like C++ offer function overloading, they do it via type inspection. So you can very clearly understand whether the function will be invoked. However, generic functions have no such limitations. I've heard lots of arguments touting that generic functions increase the flexibility of code, and that's certainly true. However, no one has every cited an example that can only be achieved using generic functions. I've yet to hear an explanation similar to: "I've been looking for a way to flip my frobbles for ages, and thanks to generic functions, I now can!"Most generic function instances use a type or identity check as the predicate. Even with just plain type checking in languages like C++ you can get lost with deep hierarchies where a function matches a class exactly but also one or more of its superclasses.There ARE use cases that are best solved by generic functions (or a poor re-implementation of them):"I've been looking for a flexible way to have a library that can be extended by users, preferably without using adaptation, yet another type registry, or monkey-patching."There are of course no self-contained use cases that are best done with generic functions, but TG needs to offer extensibility to its users without them having to maintain their own fork.-bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: scriptaculous + mochikit = pain
On Apr 27, 2006, at 7:55 AM, Karl Guertin wrote: On 4/26/06, Mark Ramm [EMAIL PROTECTED] wrote: And I keep hearing rumors that Python scripting is comming soon to a mozilla browser near you. Note that that Python scripting does not mean client area scripting, it means chrome level scripting. It'll be a boon if you're developing firefox extensions or XUL apps, but I haven't heard anything about python making it into the client area. It'd be a security disaster if it did end up accessible by client area scripting, with CPython anyway. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: SQLObject rant: unicode support sucks
On Apr 27, 2006, at 2:45 PM, Tim Lesher wrote: On 4/27/06, Baruch [EMAIL PROTECTED] wrote: I still feel that SQLObject is not doing the obvious thing here, it should use the UTF-16 encoding from the start especially when it has this comment for UnicodeCol: Note: parameters in queries will not be automatically encoded, so if you do a query matching a UnicodeCol column you must apply the encoding yourself. This will bite the ass of anyone who naively uses UnicodeCol's and thinks that his queries will just work properly. This is just conjecture, but on most Python distributions, the internal representation for a ufoo is UTF-8, so that's probably why SQLObject defaults to it. Uh, no. Totally wrong. Exactly zero Python representations use UTF-8 internally. They either use UCS-2 or UCS-4. The reason for the SQLObject default is that UTF-8 is the most likely unicode codec for unicode data coming to and from databases (and also network traffic). I know PostgreSQL deals in UTF-8, and I'd guess that MySQL is the same. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: SQLObject rant: unicode support sucks
On Apr 27, 2006, at 7:09 PM, Kevin Dangoor wrote:
On 4/27/06, Jorge Godoy [EMAIL PROTECTED] wrote:
test_unicode=# select * from test_unicode_table;
id | test_column
+-
1 | áéíóú
2 | áéíóú
3 | áéíóú
4 | áéíóú
5 | áéíóú
6 | áéíóú
(6 registros)
Do those characters require more than 1 byte for UTF-8 encoding?
Yeah...
len(unicodedata.normalize('NFC', u'\xe1\xe9\xed\xf3\xfa').encode
('utf-8'))
10
len(unicodedata.normalize('NFD', u'\xe1\xe9\xed\xf3\xfa').encode
('utf-8'))
15
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---
