On 1/17/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/17/06, kmh <[EMAIL PROTECTED]> wrote:
> > My original idea for django.shortcuts was to hold the functions that
> > wrap up a bunch of Django functionality into a one-liner
> > (render_to_response, render_to_string, get_object_or_404,
On 1/17/06, kmh <[EMAIL PROTECTED]> wrote:
> My original idea for django.shortcuts was to hold the functions that
> wrap up a bunch of Django functionality into a one-liner
> (render_to_response, render_to_string, get_object_or_404,
> get_list_or_404). If we are going to go for the "from
> module
Joseph Kocherhans wrote:
> Here's what I've come up with for django.shorcuts.views. Anything I've
> missed? Anything that should *not* be included? I think this covers
> basic to advanced views and should really simply the first 10 lines of
> most people's view modules. I've left out any kind or a
from django.core.exceptions import ObjectDoesNotExist, PermissionDenied
?
I raise this if somebody GETs to a POST-only view or vice-versa.
On a related note (but probably on the wrong list), what exceptions
do people raise to push errors back to the browser? I have a RESTful
application w
Here's what I've come up with for django.shorcuts.views. Anything I've
missed? Anything that should *not* be included? I think this covers
basic to advanced views and should really simply the first 10 lines of
most people's view modules. I've left out any kind or auth
decorators/exceptions/etc. I'
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I like this a lot! SimpleContext is good...Other thoughts?
BaseContext?
On 1/13/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> On 1/13/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
> > Hm, I actually liked RequestContext and Context :
>
> +1
Anything's better than DjangoContext. Except maybe DjangoFrameworkContext.
Let's go with Context and RequestCo
On 1/13/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Hm, I actually liked RequestContext and Context :
+1
> "Simple" implies to me that it is "for the same purpose" as other things
> called *Context, but has an easier to understand/trivial implementation.
> This isn't really true - its for a d
Adrian Holovaty wrote:
> On 1/12/06, kmh <[EMAIL PROTECTED]> wrote:
>
>>Good idea to rename DjangoContext. My favorite alternative:
>>
>>DjangoContext --> Context
>>Context --> PlainContext or SimpleContext
>
>
> I like this a lot! SimpleContext is good...Other thoughts?
>
> Adrian
>
> --
>
Adrian Holovaty wrote:
I like this a lot! SimpleContext is good...Other thoughts?
I'd say BaseContext. It's now just a base class for other actually
useful contexts.
Adrian Holovaty wrote:
> On 1/12/06, kmh <[EMAIL PROTECTED]> wrote:
> > Good idea to rename DjangoContext. My favorite alternative:
> >
> > DjangoContext --> Context
> > Context --> PlainContext or SimpleContext
>
> I like this a lot! SimpleContext is good...Other thoughts?
Now I like EmptyConte
On 1/12/06, kmh <[EMAIL PROTECTED]> wrote:
> Good idea to rename DjangoContext. My favorite alternative:
>
> DjangoContext --> Context
> Context --> PlainContext or SimpleContext
I like this a lot! SimpleContext is good...Other thoughts?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.c
On 1/12/06, kmh <[EMAIL PROTECTED]> wrote:
>
> > Let's go ahead with this one: django.core.template becomes
> django.template.
> >
> > While we're at it, let's rename DjangoContext to something that
> > reflects the fact that you pass in an HttpRequest object and it has
> > context processors. Re
On 13 jan 2006, at 03.32, Adrian Holovaty wrote:
While we're at it, let's rename DjangoContext to something that
reflects the fact that you pass in an HttpRequest object and it has
context processors. RequestContext, SuperContext, FlexContext,
AdvancedContext -- those ideas are all pretty lame.
> Let's go ahead with this one: django.core.template becomes
django.template.
>
> While we're at it, let's rename DjangoContext to something that
> reflects the fact that you pass in an HttpRequest object and it has
> context processors. RequestContext, SuperContext, FlexContext,
> AdvancedContex
On 1/12/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > > django.core.template -> django.template
> > > - includes Context/DjangoContext
Let's go ahead with this one: django.core.template becomes django.template.
While we're at it, let's rename DjangoCo
On 1/12/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > One thing, with all of changes, the django.db.models thing ends up being
> > quite deep for such a core part. Thoughts?
>
> I think django.models sounds nice, although it would be confusing for
> existing users (aside from the 5-ish peop
On 1/11/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> This all sounds good to me ( although I care less about this than some
> ). Good to compress the name churn into a short time period if possible,
> ie all in magic removal
>
> One thing, with all of changes, the django.db.models thing ends
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:
>
> > django.core.template -> django.template
> > - includes Context/DjangoContext
>
> +1. Another great change.
>
>
> > django.core.formfields -> django.fo
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> The reasoning behind using the same docs for the latest release (0.91)
> and SVN is that we make a *lot* of documentation improvements, and
> users of 0.91 should benefit from those -- i.e., the docs for 0.91
> shouldn't be frozen.
Fair enou
On 1/12/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> The current docs reflect the 0.91 release, which I think is where the
> emphasis should lie.
> Next to that we should have a copy of the 0.91 in a development
> location for people tracking the development version.
>
> djangopr
On 1/12/06, Tim Keating <[EMAIL PROTECTED]> wrote:
> One quick question -- are you guys making the corresponding changes to
> the docs? (The tutorials, especially.) If not, I may be able to do some
> of that.
We've done some of the changes to the docs, but not all. If you're
interested in helping
On 1/12/06, Tim Keating <[EMAIL PROTECTED]> wrote:
> One quick question -- are you guys making the corresponding changes to
> the docs? (The tutorials, especially.) If not, I may be able to do some
> of that.
The current docs reflect the 0.91 release, which I think is where the
emphasis should lie
One quick question -- are you guys making the corresponding changes to
the docs? (The tutorials, especially.) If not, I may be able to do some
of that.
This all sounds good to me ( although I care less about this than some
). Good to compress the name churn into a short time period if possible,
ie all in magic removal
One thing, with all of changes, the django.db.models thing ends up being
quite deep for such a core part. Thoughts?
On 1/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I've got a patch ready to commit that moves django.utils.httpwrappers
> > to django.http and updates all the dependencies and docs. I'd move
> > Http404 in another commit. Also,
Adrian Holovaty wrote:
> Let's go with the http package, with an __init__.py in it, simply
> because it makes it more flexible to put stuff in there in the future.
This raises an issue of coding style: my feeling, though PEP 8 (the
python style guide) doesn't rule on it, is that __init__.py is
i
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> I've got a patch ready to commit that moves django.utils.httpwrappers
> to django.http and updates all the dependencies and docs. I'd move
> Http404 in another commit. Also, if we are going to rename the classes
> in here, (as suggested by
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:
> > django.utils.httpwrappers -> django.http
>
> +1. I'm a big fan of this. django.http would get that'd get the
> current contents of django.utils.httpwrappers, plus the Http404 and
> Http500 exce
Joseph Kocherhans wrote:
> On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > On 1/11/06, Radek Svarz <[EMAIL PROTECTED]> wrote:
> > > Could you follow some uniform way of the pluralization of module names?
> > >
> > > I mean why there is django.shortcuts.views (plural) and django.form
>
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Hmm... what about django.template (singular) becoming django.templates
> (plural)? Any strong preferences? I think templates makes more sense.
django.templates suggests a collection of templates. django.template
suggests a library, imo.
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> On 1/11/06, Radek Svarz <[EMAIL PROTECTED]> wrote:
> > Could you follow some uniform way of the pluralization of module names?
> >
> > I mean why there is django.shortcuts.views (plural) and django.form
> > (singular)?
> >
> > I hate thos
On 1/11/06, Radek Svarz <[EMAIL PROTECTED]> wrote:
> Could you follow some uniform way of the pluralization of module names?
>
> I mean why there is django.shortcuts.views (plural) and django.form
> (singular)?
>
> I hate those code mistakes when just one s is forgotten.
You're right. 'forms' fi
Could you follow some uniform way of the pluralization of module names?I mean why there is django.shortcuts.views (plural) and django.form (singular)?
I hate those code mistakes when just one s is forgotten.
RadekOn 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
On 1/8/06, Adrian Holovaty <[
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Let's get some more feedback quickly and move forward with this. Also,
> is anybody interested in implementing this code in magic-removal?
I've added a new page to the wiki [1] (and a link to that page [2])
describing what decisions were m
Fair enough. Somebody had to resist being a +1 sheep :-)
On 1/9/06, Tim Keating <[EMAIL PROTECTED]> wrote:
> Well, how about this.
>
> >From a user (and ease-of-entry) standpoint the simplest possible
> syntax would be
>
> from django import *
A vehement "no" to this. I strongly, strongly dislike the ambiguity of
"import *" statements. Plus, there
Well, how about this.
>From a user (and ease-of-entry) standpoint the simplest possible
syntax would be
from django import *
I don't know about most of you, but I'm already importing pretty much
all of Django anyway, so I'm not sure this is as expensive as it
sounds. With this approach, yo
hugo wrote:
> >I like this idea, but I think that shortcuts of whatever should use
> >explicit imports such as
> [...]
> >This makes it a lot easier to tell what exactly you'll get if you
> >import django.shortcuts.
>
> Yes, most definitely. The "simplified API importer" should only do
> explicit
Hi Adrian,
Your opinion of the my suggestions fits pretty closely with mine.
Adrian Holovaty wrote:
> On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:
> > django.utils.httpwrappers -> django.http
>
> +1. I'm a big fan of this. django.http would get that'd get the
> current contents of django.utils.htt
>I like this idea, but I think that shortcuts of whatever should use
>explicit imports such as
[...]
>This makes it a lot easier to tell what exactly you'll get if you
>import django.shortcuts.
Yes, most definitely. The "simplified API importer" should only do
explicit imports of the stuff that s
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> > django.core.extensions -> django.shortcuts
> > - includes render_to_string
>
> +1. "django.shortcuts" is a *perfect* name for this module.
I like this idea, but I think that shortcuts of whatever shoul
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:> django.core.exceptions -> django.error+1We have a lot of django.http
, django.shortcuts, django.form, django.contrib: single depth names, so we should allow this too, though I prefer django.excepti
On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:
> django.utils.httpwrappers -> django.http
+1. I'm a big fan of this. django.http would get that'd get the
current contents of django.utils.httpwrappers, plus the Http404 and
Http500 exceptions.
> django.core.template -> django.template
>
Jacob Kaplan-Moss wrote:
> One altertative to your proposal that Adrian and I tossed around at
> one point was to alias certain "normal" modules into a set of
> "tasks." That way writing a view would become::
This would certainly be a vast improvement from an end-user's
perspective and it would
"Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> One altertative to your proposal that Adrian and I tossed around at one
> point was to alias certain "normal" modules into a set of "tasks." That
> way writing a view would become::
+1. I think this is the w
>One altertative to your proposal that Adrian and I tossed around at
>one point was to alias certain "normal" modules into a set of
>"tasks." That way writing a view would become::
+1 from me - that would allow to provide "simplified" namespaces by
still keeping the basic structure in place (as
On Jan 7, 2006, at 6:54 AM, kmh wrote:
As Aaron says, it is not obvious to the outsider what the underlying
structure of the package hierarchy is. I suspect this is a common
problem in projects that have evolved to meet the needs of a busy
production environment.
Yeah, this is a very good poi
Aaron Swartz is no diplomat but he made some good points in this rant:
http://www.aaronsw.com/weblog/rewritingreddit
The magic-removal branch addresses the ORM issues he raised. A
remaining problem is the disorientating namespace.
View modules typically begin with ugly boilerplate like:
---
49 matches
Mail list logo
