date:20070710

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 string which saves me from loading 7 functions that I'm not
using.  If I import them all at the top, I'm importing functions that may
have nothing to do with rendering the current page.  Of course, the impact
on resources is probably minimal to none, but it still means writing less
code to call by string.

from project.app.views import function

(r'^$', function)

is more than

(r'^$', 'project.app.views.function')

Sean.

On 7/10/07, Gábor Farkas <[EMAIL PROTECTED]> 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" way?
>
> i'm always using the "pythonic" way (import the view function, and give
> it to the urlconf), and assumed that this is the recommended way.
>
> but what always worried me is that you still have to enter that
> "string-prefix", which is of course an empty-string in my case, but
> still, it's quite ugly there.
>
> so i wondered whether the pythonic-way is really the preferred one.
>
> so i went to check the django-documentation...
>
> the documentation on the django-site:
>
> http://www.djangoproject.com/documentation/tutorial03/#design-your-urls
>
> uses the string-based syntax.
>
> but the django-book:
>
> http://www.djangobook.com/en/beta/chapter03/
>
> uses the pythonic-syntax.
>
> so:
>
> 1. which is the preferred way?
> 2. will django support both ways "forever"?
> 3. would it make sense to make the tutorial and the book more consistent
>   by using the same urlconf-style?
>
> thanks,
> gabor
>
> >
>

-- 
www.PovertyFighters.com

If you knew you could fight hunger and poverty, conserve the environment,
empower women, combat AIDS, improve labor standards and win a national
competition for your university--all with only two clicks a day--would you do
it?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

2007-07-10 Thread James Bennett

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 to.

On the other hand, importing the functions and using them directly
opens up some interesting possibilities -- you can apply decorators
like 'login_required' to them right there in the URLConf, which adds
another layer of configurability that isn't possible when referencing
them as strings.

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

2007-07-10 Thread Carl Karsten


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
>> load the function unless it needs to.
> 
> On the other hand, importing the functions and using them directly
> opens up some interesting possibilities -- you can apply decorators
> like 'login_required' to them right there in the URLConf, which adds
> another layer of configurability that isn't possible when referencing
> them as strings.
> 

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')),

otherwise, I need to 'cover' all of the ones listed below,  including 
databrowse, which is currently exposed.

Carl K

# eventcal/urls.py

from django.conf.urls.defaults import *
from django.contrib import databrowse
from eventcal.models import Event

info_dict = {
 'queryset': Event.objects.all(),
}

urlpatterns = patterns('eventcal.views',
 (r'^/?$','month_index'),
 (r'^(?P\d{4})/(?P\d{2})/$', 'month_index'),
 (r'^(?P\d{4})/$',  'year_index'),
 (r'^databrowse/(.*)',databrowse.site.root),
 (r'^test/(?P[-\w]+)/$', 'test_event_detail'),
)

urlpatterns += patterns('',
 (r'^detail/(?P[-\w]+)/$', 
'django.views.generic.list_detail.object_detail', info_dict),
)

databrowse.site.register(Event)


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

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:
>
>
> 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 to.
>
> On the other hand, importing the functions and using them directly
> opens up some interesting possibilities -- you can apply decorators
> like 'login_required' to them right there in the URLConf, which adds
> another layer of configurability that isn't possible when referencing
> them as strings.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> >
>


-- 
www.PovertyFighters.com

If you knew you could fight hunger and poverty, conserve the environment,
empower women, combat AIDS, improve labor standards and win a national
competition for your university--all with only two clicks a day--would you do
it?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Ping: #3285 - Signed Cookies

2007-07-10 Thread Marty Alchin


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 the main question is whether it should even be included in
Django itself, or if it should remain as a separate app. I'm  not
going to assume that it should be included, but if it shouldn't be,
it's probably best to close the ticket so that it's not cluttering up
the reports.

If it is deemed appropriate for the official distribution, I'd be
interested to know if you guys think it's ready to be included.
Obviously I'm willing to do more work on it if necessary.

-Gul

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

mod_python: Why use req.uri, not req.path_info?

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/]

SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonDebug On

That documentation correctly adds:

"Restart Apache, and any request to /mysite/ or below will be served by Django.
Note that Django’s URLconfs won’t trim the “/mysite/” — they get passed the full
URL."

So, the problem is that I have to update my urls.py to include the /mysite/
prefix in all URLs.

This is clearly not very DRY. For me, the biggest pain is that I'm actually
trying to deploy the same project at two different URLs (with different host
parts, too). (I have reasons to do this, although they aren't incrediblly
relevevant, so I won't go into that). Since my urls.py has to be so aware of my
apache config, I can't do things the way I want to and use the apache config to
enable & disable access to different application fragments under each base URL.

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)?

If a change like this is in order, I assume it will be made prior to 1.0. What
do people think about this? I didn't get much from a Google search, but it
seems hard to believe that it hasn't come up yet in the past.

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 behavior to be the default,
though.

-Forest

signature.asc
Description: Digital signature

sensitive data on error page?

2007-07-10 Thread Carl Karsten


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 off to the nutz-os for keeping us safe.  glad someone is on top of 
this stuff.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ned Batchelder's hyphenate



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 that as well. (you don't use commas in German, you use periods
for instance).

There are four reasons why I feel it is better to have this as part of
the core:
1. Hyphenation is a media standard and crucial for non-html templates.
Sites which want to generate printable PDF's of say conference
programs, or in a standard news media style will want this as much as
they want pluralize, widthratio, rjust, and center. This is more than
a template filter, but is a text utility.

2. reduce duplication of code and confusion
The actual code being duplicated is extremely minimal, but having two
text wrappers in very different locations is confusing to both
developers and users. For template filters, it would be better to have
them documented together.

3. Internationalization
To properly implement this we need to integrate with the
internationalization code and have the core language developers help
with maintaining the hyphenation rules. It does not feel DRY to have a
separate internationalization system in humanize, and it does not seem
right to have sections of the core only used by a contrib module
(though this is done for admin).

In the end if those wiser than I decide it should be in humanize I
have no problem changing the patch and writing up the doc and unit
tests. I will need help with the internationalization parts. I do not
have enough experience with the i18n system to make the proper
architectural decisions. For the translated text, the wrapping should
use the locale middleware specified hyphenation rules. For text which
has not been translated, it should use the native LANGUAGE_CODE rules.
Not sure how to get that working.

-Doug



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: #4418 - Newforms Media, ready for commit?

2007-07-10 Thread Gary Wilson

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 are as a property, using a getter method:

class MyWidget(Widget):
 ...

 def _get_media(self):
 return Media({
 'css' = {'all': ('/path/to/css',)},
 'js' = ('/path/to/js',),
 })
 media = property(_get_media)

and as an inner class:

class MyWidget(Widget):
 ...

 class Media:
 css = {'all': ('/path/to/css',)}
 js = ('/path/to/js',)

While the inner class version looks a little nicer, it has been brought 
up [1] that defining media as an inner class is less flexible (mainly 
because of the lack of inheritance capabilities).

Just throwing out an idea here, maybe we could accommodate this problem 
with something like:

class MyWidget(Widget):
 ...

 class Media:
 css_extend = {'all': ('/path/to/css2',)}
 js = ('/path/to/js',)

Where, " ="  would replace media defined in base class(es) 
and "_extend =" would extend media defined in base class(es).

Of course, this would be exchanging the complexity of supporting two 
ways to define media with the complexity of looking at base class(es) if 
there is a _extend being used.  Although, this is already 
being done when no media is defined so maybe it wouldn't take too much 
code to determine this.  Thing is, we would be doing all this to get 
inheritance, which we get for free if using a property instead.

-

On another note, in line 114 of django/newforms/widgets.py there is:

media_property and media_property or Media(media_definition)

is this, perhaps, supposed to be:

media_property or media_definition and Media(media_definition)

Gary

[1] 
http://groups.google.com/group/django-developers/browse_frm/thread/58fc9cab819c08b9/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: sensitive data on error page?

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 a button were created, what would you nutz-os say?
>
> Carl K
>
> pw, hat's off to the nutz-os for keeping us safe.  glad someone is on top of
> this stuff.

This would be nice for those developing (i.e. not production) to get
help debugging. Production has the e-mail response.

1. There is no way to make it secure enough.
The local variable stack could have the secret code in it, or a users
typed password, password to the LDAP backend auth system!
There is no way to protect all the data in any system, as you have
know way of knowing what those will be out in the field.

2. Most settings are already protected.
The stuff that is obvious I believe is already protected (could be
wrong about that).

I think a disclaimer would be enough. Letting the poster know they are
giving out sensitive information to the world, and to never do this
with a production system.
Then again I have not done security for 10 years, and I am sure others
will be better informed opinions.

-Doug

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: sensitive data on error page?

2007-07-10 Thread Adrian Holovaty


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 button were created, what would you nutz-os say?

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.

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: sensitive data on error page?

2007-07-10 Thread Marty Alchin


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 is exactly what #2437 already does. Is
there a reason the existing patch isn't suitable? It seems like we're
reinventing the wheel a bit.

-Gul

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: mod_python: Why use req.uri, not req.path_info?

2007-07-10 Thread Max Battcher

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 behavior to be the default,
> though.

Fixing the URLs redundancy is easy, create a new mysite_urls.py and
mysite_settings.py for the site at /mysite/.  In mysite_settings put
the ROOT_URLCONF to mysite_urls.py and mysite_urls just needs the
simple url pattern ('^mysite/', include('urls.py')) to match the new
"global" prefix.  You can do the same for other sites or it would be
easy enough to use a more generic prefix regex and share the same
prefix matching urls and trade off a little regex efficiency...  Each
site should have its own settings anyway, at the very least for
separate SITE_IDs.  (Settings is just python, so you can easily
inherit some base settings with a line like ``from base_settings
import *``.)

-- 
--Max Battcher--
http://www.worldmaker.net/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: mod_python: Why use req.uri, not req.path_info?

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 solution, I'd be 
> > open to
> > that.  It doesn't seem ideal to me for the current behavior to be the 
> > default,
> > though.
> 
> Fixing the URLs redundancy is easy, create a new mysite_urls.py and
> mysite_settings.py for the site at /mysite/.  In mysite_settings put
> the ROOT_URLCONF to mysite_urls.py and mysite_urls just needs the
> simple url pattern ('^mysite/', include('urls.py')) to match the new
> "global" prefix.  You can do the same for other sites or it would be
> easy enough to use a more generic prefix regex and share the same
> prefix matching urls and trade off a little regex efficiency...  Each
> site should have its own settings anyway, at the very least for
> separate SITE_IDs.  (Settings is just python, so you can easily
> inherit some base settings with a line like ``from base_settings
> import *``.)

Yes, that would work, and I've done similar things for other situations, but I'm
really just having a hard time seeing why django even cares about /mysite/ at
all.

The solution you mention here requires me to add two python source files to my
tree, and in the end, if I want to move my app to a different URL, I still have
to change both the apache configuration and mysite_urls.py.  It just shouldn't
be that complicated, should it?

I figure I should just have to change the apache configuration, which is where
django instances are mapped to URLs.  urls.py is where django views are mapped
to sub-urls of the main django instance, right?

-Forest

signature.asc
Description: Digital signature

Re: mod_python: Why use req.uri, not req.path_info?

2007-07-10 Thread Marty Alchin

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 no expert in this area, but keep in mind that mod_python
is just one available option for deploying Django. There would have to
be some equivalent in the other situations, such as FastCGI, in order
for this to be taken seriously.

Above all, I think the intent here is consistency. It's hardly a Good
Idea to have one way to lay out your URLs for mod_python and a
different one for the rest. I'm not saying it's impossible to do (I
don't know enough to say that), just that they all need to work the
same way.

So if mod_python ends up being the only one that supports this, I'd be
very opposed to making changes for the mod_python case.

-Gul

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

New Python ORM

2007-07-10 Thread David Cramer


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 to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: mod_python: Why use req.uri, not req.path_info?

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 that (aside from breaking backwards
> > compatibility)?
> 
> I'm certainly no expert in this area, but keep in mind that mod_python
> is just one available option for deploying Django. There would have to
> be some equivalent in the other situations, such as FastCGI, in order
> for this to be taken seriously.

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 handlers
would need to be updated for consistency.  I agree with you there.

If there was some way to tell apache/mod_python to pass the URL sans the prefix
in to django, I would simply do that.  I have not been able to find any such
thing.

But really, the prefix is a deployment detail that I should be able to make my
application agnostic to.  I don't have to include my domain name in my urls.py,
why should I have to include a prefix?

Maybe this behavior could be determined by something in settings.py.

-Forest

signature.asc
Description: Digital signature

Re: New Python ORM




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 already has, and looks to be
behind SQLAlchemy which people are already working on integrating in
some fashion (maybe).


-Doug


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: mod_python: Why use req.uri, not req.path_info?




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 use req.path_info instead of 
> > > req.uri.
> > > Is there any reason not to do that (aside from breaking backwards
> > > compatibility)?
>
> > I'm certainly no expert in this area, but keep in mind that mod_python
> > is just one available option for deploying Django. There would have to
> > be some equivalent in the other situations, such as FastCGI, in order
> > for this to be taken seriously.
>
> 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 
> handlers
> would need to be updated for consistency.  I agree with you there.
>
> If there was some way to tell apache/mod_python to pass the URL sans the 
> prefix
> in to django, I would simply do that.  I have not been able to find any such
> thing.
>
> But really, the prefix is a deployment detail that I should be able to make my
> application agnostic to.  I don't have to include my domain name in my 
> urls.py,
> why should I have to include a prefix?
>
> Maybe this behavior could be determined by something in settings.py.
>
> -Forest
>
>  signature.asc
> 1KDownload

Your applications should be root url agnostic. Each app should have
its own urls.py and the root site urls.py (and its accompanying
settings.py) should have the site specific information including the
root. Then the apps are included in the site specific root urls.py

You might want to check out this thread for more information:
http://groups.google.com/group/django-developers/browse_thread/thread/e9d92bceab679f6a/#

Here is an example of having the root urls.py get its bases from
settings.py (though not a very good one):
https://svn.python.org/conference/django/trunk/pycon/urls.py

Hope that helps!

-Doug


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: mod_python: Why use req.uri, not req.path_info?

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 
> > handlers
> > would need to be updated for consistency.  I agree with you there.
> >
> > If there was some way to tell apache/mod_python to pass the URL sans the 
> > prefix
> > in to django, I would simply do that.  I have not been able to find any such
> > thing.
> >
> > But really, the prefix is a deployment detail that I should be able to make 
> > my
> > application agnostic to.  I don't have to include my domain name in my 
> > urls.py,
> > why should I have to include a prefix?
> >
> > Maybe this behavior could be determined by something in settings.py.
> >
> > -Forest
> >
> >  signature.asc
> > 1KDownload
> 
> Your applications should be root url agnostic. Each app should have
> its own urls.py and the root site urls.py (and its accompanying
> settings.py) should have the site specific information including the
> root. Then the apps are included in the site specific root urls.py

Pardon me for mis-speaking.  I meant that I felt my site-specific urls.py should
be root URL agnostic.  Actually, I am pushing for that URL prefix to only be
mentioned in the apache config.  While I appreciate your assistance in helping
me do things how you would do them, I am really hoping someone can answer my
question: why use req.uri instead of req.path_info?  Is there a good reason?

> You might want to check out this thread for more information:
> http://groups.google.com/group/django-developers/browse_thread/thread/e9d92bceab679f6a/#

A quick scan of that thread doesn't turn up much relevant info.  What am I
looking for there?

> Here is an example of having the root urls.py get its bases from
> settings.py (though not a very good one):
> https://svn.python.org/conference/django/trunk/pycon/urls.py

Thanks; I won't be needing further assistance with Python, however.

-Forest


signature.asc
Description: Digital signature

Re: mod_python: Why use req.uri, not req.path_info?

2007-07-10 Thread Kevin Menard


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 off by it.  I could map an application to any
context and things just work.  On IRC, I have seen this as a recurring
"problem" over the past two years of my participation there.  Most
people respond with "configure a new subdomain *shrug*", which clearly
is not appropriate for all circumstances.  Alas, that's exactly what
I've deferred to for simplicity's sake.

So, if the change is simple enough to make, I'm +1 (non-binding) for it.

-- 
Kevin

On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> 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/]
>
> 
> 
> SetHandler python-program
> PythonHandler django.core.handlers.modpython
> SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> PythonDebug On
> 
> 
>
> That documentation correctly adds:
>
> "Restart Apache, and any request to /mysite/ or below will be served by 
> Django.
> Note that Django's URLconfs won't trim the "/mysite/" -- they get passed the 
> full
> URL."
>
> So, the problem is that I have to update my urls.py to include the /mysite/
> prefix in all URLs.
>
> This is clearly not very DRY.  For me, the biggest pain is that I'm actually
> trying to deploy the same project at two different URLs (with different host
> parts, too).  (I have reasons to do this, although they aren't incrediblly
> relevevant, so I won't go into that).  Since my urls.py has to be so aware of 
> my
> apache config, I can't do things the way I want to and use the apache config 
> to
> enable & disable access to different application fragments under each base 
> URL.
>
> 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)?
>
> If a change like this is in order, I assume it will be made prior to 1.0.  
> What
> do people think about this?  I didn't get much from a Google search, but it
> seems hard to believe that it hasn't come up yet in the past.
>
> 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 behavior to be the default,
> though.
>
> -Forest
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGk8pFRO4fQQdv5AwRArNzAJ9jur9ar1+vVtAgR2/+EaGsgyksvgCfZCub
> 3P41eIxMRdCx/5pO7xGNCQA=
> =2t4f
> -END PGP SIGNATURE-
>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

2007-07-10 Thread Kevin Menard


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 functions, it only imports the one for the correct URL if
> I call by string which saves me from loading 7 functions that I'm not using.
>  If I import them all at the top, I'm importing functions that may have
> nothing to do with rendering the current page.  Of course, the impact on
> resources is probably minimal to none, but it still means writing less code
> to call by string.

Sorry to be taking this a bit OT, but you raised an interesting point.
 Do you happen to know what the cost impact is for importing a
function into the current scope VS the cost of introspectively looking
up a function?  Is either cached or is this done on a per request
basis?

As an aside, I prefer the pythonic way because PyDev is able to give
me some help with auto-completion, which tends to mean less errors due
to stupid typos.

-- 
Kevin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: New Python ORM

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 (in my opinion).

   1 >>> class Employee(Person):
   2 ... __storm_table__ = "employee"
   3 ... company_id = Int()
   4 ... company = Reference(company_id, Company.id)

Here we see that I have to declare a company_id and the the foreign key -
Django does this in one step with ForeignKey(Model).

It just seems that Django's ORM is already syntactically nicer and, other
than inheritance, Storm doesn't seem to have any really compelling feature.

On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
>
> 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 already has, and looks to be
> behind SQLAlchemy which people are already working on integrating in
> some fashion (maybe).
>
>
> -Doug
>
>
> >
>

-- 
www.PovertyFighters.com

If you knew you could fight hunger and poverty, conserve the environment,
empower women, combat AIDS, improve labor standards and win a national
competition for your university--all with only two clicks a day--would you do
it?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

2007-07-10 Thread Collin Grady


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 include.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

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 memory which might be more important than
processing power as web apps tend to be memory-hungry more than processor
hungry.  I'm guessing loading the functions would take more memory than
calling by string.

In the end, I don't think it will matter in any app.  One should probably
pay attention to what's in their functions more than how they load them.
That's where the real problems are going to be.

On 7/10/07, Kevin Menard <[EMAIL PROTECTED]> 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.
> >
> > 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 string which saves me from loading 7 functions that I'm not
> using.
> >  If I import them all at the top, I'm importing functions that may have
> > nothing to do with rendering the current page.  Of course, the impact on
> > resources is probably minimal to none, but it still means writing less
> code
> > to call by string.
>
> Sorry to be taking this a bit OT, but you raised an interesting point.
> Do you happen to know what the cost impact is for importing a
> function into the current scope VS the cost of introspectively looking
> up a function?  Is either cached or is this done on a per request
> basis?
>
> As an aside, I prefer the pythonic way because PyDev is able to give
> me some help with auto-completion, which tends to mean less errors due
> to stupid typos.
>
> --
> Kevin
>
> >
>

-- 
www.PovertyFighters.com

If you knew you could fight hunger and poverty, conserve the environment,
empower women, combat AIDS, improve labor standards and win a national
competition for your university--all with only two clicks a day--would you do
it?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: mod_python: Why use req.uri, not req.path_info?

2007-07-10 Thread Graham Dumpleton

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 to do that (aside from breaking backwards 
> > compatibility)?
>
> I'm certainly no expert in this area, but keep in mind thatmod_python
> is just one available option for deploying Django. There would have to
> be some equivalent in the other situations, such as FastCGI, in order
> for this to be taken seriously.
>
> Above all, I think the intent here is consistency. It's hardly a Good
> Idea to have one way to lay out your URLs formod_pythonand a
> different one for the rest. I'm not saying it's impossible to do (I
> don't know enough to say that), just that they all need to work the
> same way.
>
> So ifmod_pythonends up being the only one that supports this, I'd be
> very opposed to making changes for themod_pythoncase.

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 application. A well behaved WSGI application should not
be ignoring it and should really allow URLs to be expressed relative
to the mount point, thus making it easily relocatable. Where a full
absolute URL is required, an application should be using SCRIPT_NAME
in part of the calculations.

I grumble a bit about the problems in:

  http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

Referenced in there are a number of Django tickets which relate to the
problem.

  http://code.djangoproject.com/ticket/285
  http://code.djangoproject.com/ticket/2407
  http://code.djangoproject.com/ticket/1516

Thus, not only mod_python is affected and since development server
expects things to be mounted at root and this is only thing not
possibly affected, would seem that no solution quite works as one
would expect where not mounted at root. FWIW, I personally don't see
using mod_rewrite hacks as a suitable solution.

Graham

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

2007-07-10 Thread Chris Heisel


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 matching doesn't read as bad as it might sound :-)

Chris

On 7/10/07, Sean Patrick Hogan <[EMAIL PROTECTED]> wrote:
> 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 memory which might be more important than
> processing power as web apps tend to be memory-hungry more than processor
> hungry.  I'm guessing loading the functions would take more memory than
> calling by string.
>
> In the end, I don't think it will matter in any app.  One should probably
> pay attention to what's in their functions more than how they load them.
> That's where the real problems are going to be.
>
>
> On 7/10/07, Kevin Menard <[EMAIL PROTECTED]> 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.
> > >
> > > 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 string which saves me from loading 7 functions that I'm not
> using.
> > >  If I import them all at the top, I'm importing functions that may have
> > > nothing to do with rendering the current page.  Of course, the impact on
> > > resources is probably minimal to none, but it still means writing less
> code
> > > to call by string.
> >
> > Sorry to be taking this a bit OT, but you raised an interesting point.
> > Do you happen to know what the cost impact is for importing a
> > function into the current scope VS the cost of introspectively looking
> > up a function?  Is either cached or is this done on a per request
> > basis?
> >
> > As an aside, I prefer the pythonic way because PyDev is able to give
> > me some help with auto-completion, which tends to mean less errors due
> > to stupid typos.
> >
> > --
> > Kevin
> >
> >
> >
> >
>
>
>
> --
> www.PovertyFighters.com
>
> If you knew you could fight hunger and poverty, conserve the environment,
> empower women, combat AIDS, improve labor standards and win a national
> competition for your university--all with only two clicks a day--would you
> do it?
>  >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Ticket 3505, Authentication backend

2007-07-10 Thread mario__


   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 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ned Batchelder's hyphenate

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.
> If we decide to properly internationalize humanize, then I am fine
> with that as well. (you don't use commas in German, you use periods
> for instance).

Don't decide that this hinges on "fully internationalize humanize or it
shouldn't go there". Incremental changes are good.

> There are four reasons why I feel it is better to have this as part of
> the core:
> 1. Hyphenation is a media standard and crucial for non-html templates.
> Sites which want to generate printable PDF's of say conference
> programs, or in a standard news media style will want this as much as
> they want pluralize, widthratio, rjust, and center. This is more than
> a template filter, but is a text utility.

Not seeing why that does or doesn't support your argument. It's not
something you need all the time (more appropriate to print layout than
HTML, as a rule), so including it by default, given that HTML output is
the common case, isn't a requirement (and saves on memory usage when its
not included, for example). Having it in contrib/ puts it exactly one
import away.

> 2. reduce duplication of code and confusion
> The actual code being duplicated is extremely minimal, but having two
> text wrappers in very different locations is confusing to both
> developers and users. For template filters, it would be better to have
> them documented together.
> 
> 3. Internationalization
> To properly implement this we need to integrate with the
> internationalization code and have the core language developers help
> with maintaining the hyphenation rules. It does not feel DRY to have a
> separate internationalization system in humanize, and it does not seem
> right to have sections of the core only used by a contrib module
> (though this is done for admin).

This is a based on a mistaken assumption, it look like. Everything in
contrib is already supported by translators.

However, there's another consideration here, too: it's highly unlikely
that a normal translator will be able to maintain the hyphenation
databases. They are very technical data structures.

> 
> In the end if those wiser than I decide it should be in humanize I
> have no problem changing the patch and writing up the doc and unit
> tests. I will need help with the internationalization parts. I do not
> have enough experience with the i18n system to make the proper
> architectural decisions.

I was thinking about this a bit yesterday. It shouldn't be too hard. I'm
a few days away from implementing anything, since I'm not going to
instantly bump this to the top of my list, but it's a solvable problem.

For my money, if we include this, putting it in contrib somewhere feels
better. It will also make maintenance easier, since we can give Ned (or
designated sock puppet) commit access to that part of the tree for
ongoing bug fixes.

Regards,
Malcolm

-- 
The early bird may get the worm, but the second mouse gets the cheese. 
http://www.pointy-stick.com/blog/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables


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 the URL conf, it loads them
all.

Regards,
Malcolm


-- 
If Barbie is so popular, why do you have to buy her friends? 
http://www.pointy-stick.com/blog/




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

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" way?

In your case, whichever works for you. In my case, whichever works for
me.

> 
> i'm always using the "pythonic" way (import the view function, and give 
> it to the urlconf), and assumed that this is the recommended way.
> 
> but what always worried me is that you still have to enter that 
> "string-prefix", which is of course an empty-string in my case, but 
> still, it's quite ugly there.

If that was really a problem for you, then (a) you don't have enough
problems to worry about, or they must be really tiny problems and (b) it
would be trivial to write yourself a patterns() replacement that didn't
require the empty string:

lambda my_patterns(*args): patterns('', *args)

> 
> so i wondered whether the pythonic-way is really the preferred one.
> 
> so i went to check the django-documentation...
> 
> the documentation on the django-site:
> 
> http://www.djangoproject.com/documentation/tutorial03/#design-your-urls
> 
> uses the string-based syntax.
> 
> but the django-book:
> 
> http://www.djangobook.com/en/beta/chapter03/
> 
> uses the pythonic-syntax.
> 
> so:
> 
> 1. which is the preferred way?
> 2. will django support both ways "forever"?
> 3. would it make sense to make the tutorial and the book more consistent 
>   by using the same urlconf-style?

I like the fact that there are some variations like that between Adrian
and Jacob's book and the main documentation. Too many people obsess over
whether they are doing things The One True Way to the point of being
afraid to just try something. Showing that there are alternative
strategies isn't the end of the world. Not a strong argument to always
have differences, but it is an argument against trying to stamp them out
all over the place.

Note one good argument against using function references: reverse URL
lookups are much less flexible. If you are using function references,
you either have to import your functions in *exactly* the same way as
urls.py does (which can be hard to work out) or add a URL pattern name.
This is because reverse lookups are done using identity matching and
because of the way __import__ works and some subtleties of Python
importing and sys.modules, two different import paths might not lead to
the same function object. In reality, this isn't a big deal at all:
adding a pattern name is easy. I have one last trick up my sleeve to try
and make this more robust and in a few weeks I might even try it out,
but it's very low priority since it's quite tricky and very low reward
to work in that area of the code.

Regards,
Malcolm

-- 
Honk if you love peace and quiet. 
http://www.pointy-stick.com/blog/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: mod_python: Why use req.uri, not req.path_info?

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 application

I guess this is the best post to reply to in the thread: Most of the
problems mentioned here sort of hinge of this issue that Graham raises.
At some point I want to work out a fix for that in a way that doesn't
break every existing installation on the planet (I have a bad feeling
it's going to add another setting, unfortunately). If I was ever rude
enough to create a "most annoying things about Django" list, this would
be near the top for me, but it's a matter of finding time to work on it
and coming up with a non-sucky design.

So, yeah, it's a wart and I personally would like to fix it. Before 1.0.
It's certainly on my list.

Regards,
Malcolm

-- 
Depression is merely anger without enthusiasm. 
http://www.pointy-stick.com/blog/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ticket 3505, Authentication backend

2007-07-10 Thread Russell Keith-Magee

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 a unit test - just a clear set of instructions for how to
generate they type of error that your patch proposes to catch? I can
see the general problem that this ticket is working on, but I can't
see how the patch you provide fixes that problem.

Yours,
Russ Magee  %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

what do you guys think of Storm by Canonical?

2007-07-10 Thread bedros


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 to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ned Batchelder's hyphenate




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:
> > 1. Hyphenation is a media standard and crucial for non-html templates.
> > Sites which want to generate printable PDF's of say conference
> > programs, or in a standard news media style will want this as much as
> > they want pluralize, widthratio, rjust, and center. This is more than
> > a template filter, but is a text utility.
>
> Not seeing why that does or doesn't support your argument. It's not
> something you need all the time (more appropriate to print layout than
> HTML, as a rule), so including it by default, given that HTML output is
> the common case, isn't a requirement (and saves on memory usage when its
> not included, for example). Having it in contrib/ puts it exactly one
> import away.
wordwrap, center, rjust, and widthratio (for most uses) are more
appropriate for print layout than HTML. The proper way to implement
these in HTML is with CSS, yet they are all part of the existing
default filters. When it comes to the templates, this is just a
specialized form of wordwrap. If the argument is that this is more for
printed forms and not of real general use for the most common html
generation and take up memory and adds bloat, then I question the
inclusion of these other filters, django.utils.text.wrap and other
utilities as well. At least that was my point (and admittedly a weak
one :-) The astute will notice that I left off my fourth argument (it
was just too weak).

> > I will need help with the internationalization parts. I do not
> > have enough experience with the i18n system to make the proper
> > architectural decisions.
>
> I was thinking about this a bit yesterday. It shouldn't be too hard. I'm
> a few days away from implementing anything, since I'm not going to
> instantly bump this to the top of my list, but it's a solvable problem.
I welcome any and all help!!! I don't see this as anything crucial or
time sensitive.
For my part I want this feature for a project, and at worst can
include the code as an app there. I just believe it should be part of
the django distribution instead of some third party addon.

-Doug


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: what do you guys think of Storm by Canonical?