On 7/11/07, bedros <[EMAIL PROTECTED]> wrote:
>
> they just released under open source (LGPLv2).
>
> https://storm.canonical.com/
Cross posting like this is really bad form. Plus, unless you have a
specific proposal for how Storm should be used in Django,
Django-developers isn't really the right
On 7/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> On Jul 11, 12:42 am, bedros <[EMAIL PROTECTED]> wrote:
> > they just released under open source (LGPLv2).
> >
> > https://storm.canonical.com/
> >
> > Tutorial is here
> >
> > https://storm.canonical.com/Tutorial
>
Yawn.
--~--~--
On Jul 11, 12:42 am, bedros <[EMAIL PROTECTED]> wrote:
> they just released under open source (LGPLv2).
>
> https://storm.canonical.com/
>
> Tutorial is here
>
> https://storm.canonical.com/Tutorial
See this thread:
http://groups.google.com/group/django-developers/browse_thread/thread/185f62e8e2
On Jul 10, 11:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Don't decide that this hinges on "fully internationalize humanize or it
> shouldn't go there". Incremental changes are good.
agreed.
>
> > There are four reasons why I feel it is better to have this as part of
> > the core:
>
they just released under open source (LGPLv2).
https://storm.canonical.com/
Tutorial is here
https://storm.canonical.com/Tutorial
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
On 7/11/07, mario__ <[EMAIL PROTECTED]> wrote:
>
>Please take a look at this url http://code.djangoproject.com/ticket/3505
> I wrote a little patch for the ticket subject. Comments or kicks will
> be appreciated :-)
Can you help out a little bit here by providing a test case (not
necessarily
On Tue, 2007-07-10 at 23:45 +, Graham Dumpleton wrote:
[...]
> Django has problems in related areas with CGI and WSGI type hosting
> solutions as well. For example, mod_wsgi, FastCGI, SCGI, and CGI. This
> is because Django ignores SCRIPT_NAME variable which defines the mount
> point of the ap
On Tue, 2007-07-10 at 09:20 +0200, Gábor Farkas wrote:
> hi,
>
> when specifying view-functions in the urlconfs, you can either specify
> them by their name as a string, or by referencing them "pythonically"
> (importing them, and giving the urlconf the callable).
>
> which is the "preferred"
On Tue, 2007-07-10 at 08:39 -0400, Sean Patrick Hogan wrote:
> The "pythonic" way is a new addition to Django if I'm not mistaken.
>
> I personally prefer calling by string because (I'm assuming here) it
> doesn't load the function unless it needs to.
Bad assumption. The first time you access t
On Tue, 2007-07-10 at 18:26 +, [EMAIL PROTECTED] wrote:
>
> On Jul 9, 10:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
> wrote:
> > Maybe an addition to django.contrib.humanize?
>
> If we decide to only support English, then I am fine with including
> this as part of django.contrib.humanize
Please take a look at this url http://code.djangoproject.com/ticket/3505
I wrote a little patch for the ticket subject. Comments or kicks will
be appreciated :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
I'd also be interested in the memory usage of strings vs. importing
the functions directly.
At work, we tend to use the string method when it's an undecorated
view function, and the pythonic way when we're going to decorate them:
usually caching, but sometimes login_required, etc.
The mixing and
On Jul 11, 6:25 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
>
> > All of this could be fixed by simply changing ModPythonRequest
> > (django/core/handlers/modpython.py) to use req.path_info instead of
> > req.uri. Is
> > there any reason not
That's a good question and one I don't know the answer to.
But here's one thing to keep in mind. Let's say that introspectively
looking up a function is 4x more costly. If I have 8 entries in my URLConf
going to different functions, calling by string is 2x faster.
Plus, there's the issue of mem
On Jul 10, 6:20 am, Carl Karsten <[EMAIL PROTECTED]> wrote:
> apply decorators? do tell...
>
> (sorry to turn this into a d-user post...)
>
> Ideally I would like to apply it to this whole tree:
>
> (r'^eventcal/', include('eventcal.urls')),
You can apply it to specific views, not to an in
It's also just very verbose.
1 >>> class Person(object):
2 ... __storm_table__ = "person"
3 ... id = Int(primary=True)
4 ... name = Unicode()
So, I have to declare a __storm_table__ and id for every model. That should
be assumed by default and allowed to be overwritten (i
On 7/10/07, Sean Patrick Hogan <[EMAIL PROTECTED]> wrote:
> The "pythonic" way is a new addition to Django if I'm not mistaken.
>
> I personally prefer calling by string because (I'm assuming here) it doesn't
> load the function unless it needs to. So, if I have a URLConf that
> references 8 view
I feel your pain here. I never quite understood why the app, project,
whatever, had to care where it was being deployed. Or rather, why one
has to go out of his way to make URLs work in different contexts.
Coming from the Java world, this was something I had never run into,
and I was pretty put
On Tue, Jul 10, 2007 at 09:40:49PM -, [EMAIL PROTECTED] wrote:
> On Jul 10, 5:02 pm, Forest Bond <[EMAIL PROTECTED]> wrote:
> > Is this kind of change relevant for all of the other methods? I have not
> > used
> > any of the others. Certainly, if a change like this is made, the other
> > ha
On Jul 10, 5:02 pm, Forest Bond <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 10, 2007 at 04:25:17PM -0400, Marty Alchin wrote:
>
> > On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> > > All of this could be fixed by simply changing ModPythonRequest
> > > (django/core/handlers/modpython.py) to us
On Jul 10, 4:43 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> Not sure if you guys have seen this, but maybe Django can take a bit
> from what it does well.
>
> https://storm.canonical.com/Tutorial
The problem is no one knows what it 'does well' yet :-)
It is missing many of the features Django
On Tue, Jul 10, 2007 at 04:25:17PM -0400, Marty Alchin wrote:
>
> On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> > All of this could be fixed by simply changing ModPythonRequest
> > (django/core/handlers/modpython.py) to use req.path_info instead of req.uri.
> > Is there any reason not to do
Not sure if you guys have seen this, but maybe Django can take a bit
from what it does well.
https://storm.canonical.com/Tutorial
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post t
On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> All of this could be fixed by simply changing ModPythonRequest
> (django/core/handlers/modpython.py) to use req.path_info instead of req.uri.
> Is
> there any reason not to do that (aside from breaking backwards compatibility)?
I'm certainly
On Tue, Jul 10, 2007 at 04:13:44PM -0400, Max Battcher wrote:
>
> On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> > So, the problem is that I have to update my urls.py to include the /mysite/
> > prefix in all URLs.
> >
> > ...
> >
> > If this can be solved using some crazy middleware-type so
On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> So, the problem is that I have to update my urls.py to include the /mysite/
> prefix in all URLs.
>
> ...
>
> If this can be solved using some crazy middleware-type solution, I'd be open
> to
> that. It doesn't seem ideal to me for the current
On 7/10/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> There's already a "copy-and-paste" version of the error traceback, so
> I'd recommend using that as the contents of the pastebin paste. It's
> just the traceback, as plain text, without any local variable values.
>From what I can tell, this
On 7/10/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
> I am considering adding a 'paste to http://dpaste.com"; button to the error
> page
> template, but not if the security nutz are going to say it makes it too easy
> for
> people to expose stuff that shouldn't be exposed.
>
> So, if such a butt
On Jul 10, 2:05 pm, Carl Karsten <[EMAIL PROTECTED]> wrote:
> I am considering adding a 'paste tohttp://dpaste.com"; button to the error page
> template, but not if the security nutz are going to say it makes it too easy
> for
> people to expose stuff that shouldn't be exposed.
>
> So, if such
Russell Keith-Magee wrote:
> Any feedback (especially objections to committing) would be
> appreciated.
First, great work! I think all the kiddies will like it. Won't be long
before Django has a Scriptaculous widget set, I bet :)
Are we fine with having two ways to add media?
The two methods
On Jul 9, 10:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Maybe an addition to django.contrib.humanize?
If we decide to only support English, then I am fine with including
this as part of django.contrib.humanize.
If we decide to properly internationalize humanize, then I am fine
with
I am considering adding a 'paste to http://dpaste.com"; button to the error page
template, but not if the security nutz are going to say it makes it too easy
for
people to expose stuff that shouldn't be exposed.
So, if such a button were created, what would you nutz-os say?
Carl K
pw, hat's
Hi,
I was trying to set up a site at a URL that is not at the root of the web
server. I am using mod_python, and my apache config looks similar to that
included with the relevant django documentation, which I'll duplicate here:
[from http://www.djangoproject.com/documentation/modpython/]
--
It's been a while since I had mentioned much about my signed cookies
app, and I just wanted to check and see if there might be any updates
to the ticket soon. I've set up a Google Code project[1] for it, and
the app itself is quite robust, thanks to the excellent feedback I've
gotten.
I guess now
Yeah, I've used the caching decorators in my URLConf for generic views that
way.
I think it's good to support both ways and I don't think either is going
away, but someone more familiar with development should probably comment on
that.
Sean.
On 7/10/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
James Bennett wrote:
> On 7/10/07, Sean Patrick Hogan <[EMAIL PROTECTED]> wrote:
>> The "pythonic" way is a new addition to Django if I'm not mistaken.
>
> Yes, it was added between the 0.95 and 0.96 releases.
>
>> I personally prefer calling by string because (I'm assuming here) it doesn't
>> l
On 7/10/07, Sean Patrick Hogan <[EMAIL PROTECTED]> wrote:
> The "pythonic" way is a new addition to Django if I'm not mistaken.
Yes, it was added between the 0.95 and 0.96 releases.
> I personally prefer calling by string because (I'm assuming here) it doesn't
> load the function unless it needs
The "pythonic" way is a new addition to Django if I'm not mistaken.
I personally prefer calling by string because (I'm assuming here) it doesn't
load the function unless it needs to. So, if I have a URLConf that
references 8 view functions, it only imports the one for the correct URL if
I call by
Since the algorithm is identical to the one used by TeX, the hyphenation
data can be taken from there as well. I used a TeX distribution to get
the latest patterns for English to include in the module. I installed
MiKTeX, and dug around in the tex/generic/hyphen directory to find
them. There
Todd, good to meet a fellow nerd: I also have the five-volume hardcover
set. My code is implemented from appendix H of volume 1 (or is it volume
A?).
--Ned.
Todd O'Bryan wrote:
> On Tue, 2007-07-10 at 02:54 +, [EMAIL PROTECTED] wrote:
>
>> On further reflection, there is a huge internati
hi,
when specifying view-functions in the urlconfs, you can either specify
them by their name as a string, or by referencing them "pythonically"
(importing them, and giving the urlconf the callable).
which is the "preferred" way?
i'm always using the "pythonic" way (import the view function,
41 matches
Mail list logo
