Re: Free Django hosting

[James Bennett]

This list is for discussion of the development of Django, not for
discussing uses of Django.

Also, generally it's a good idea to use Google to search for an answer
to questions like this.


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

Free Django hosting

[Tsolmon Narantsogt]

Hello everybody

i've a question. Have any free django hosting site ?

Kind Regards
Tsolmon

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

Re: Looking for Django vs. Joomla comparison

[John]

On Jun 14, 10:59 am, Hooshyar  wrote:
> Hello all,
>
> I am new to this group, although I am 4 years old with Django. I have
> a question. If this is not the right place, I apologize in advance.
> Please refer me to a proper mailing list. Please reply here or you can
> e-mail me directly, if you wish. my e-mail address is
> hfn1...@yahoo.com
>
> My question is do you know any reference, link or white paper that
> compares Joomla to Django? I know how wrong this comparison could be,
> but an avid Joomla/PHP vendor is making it.
>
> Also, if you know a reference material to compare Django to PHP, that
> would be fine too, although even this comparison might not come across
> as an apple-to-apple comparison.
>
> Thank you in advance for your help.
>
> Hoosh.

You compare django to cakePHP.
You compare a django based cms (django-cms or maybe pinax) to joomla
You compare python to php.

You can't compare a framework to a cms it doesn't make any sense.
It's like damn this car sure gets me to the grocery store faster than
this 1 ton block of steel.

But yeah this is better placed on django-users once you think about
what you are really asking.  You seem to realize the comparison makes
no sense so don't know what to tell you.

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

Re: 'exists' parameter for pre_save signal

[Jeremy Dunck]

On Tue, Jun 15, 2010 at 10:46 AM, George Sakkis  wrote:
> ...In the current save_base()
> implementation, pre_save is sent before the instance's existence is
> determined, so I'm not sure if postponing it would break existing
> code. If there is no backwards compatibility issue, I can open a
> ticket and send a patch for it.

Well, a significant difference is that pre_save right now can cancel a
save before a query to determine existence is needed (0 vs 1 or 2
queries).  I'm not sure how many people really use pre_save's
cancellation feature, but I think we'd need some confidence that
moving wouldn't cause a problem for people counting on the 0-query
cancellation that's available right now.

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

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Graham Dumpleton]

On Jun 16, 8:01 am, Gustavo Narea  wrote:
> Hello.
>
> Russell said:
>
>
>
>
>
> > > It should be easy, specially since you already use WSGI middleware in
> > > that server internally (i.e., the AdminMediaHandler).
>
> > > In runserver.py, you could replace:
> > >    try:
> > >        handler = AdminMediaHandler(WSGIHandler(), admin_media_path)
>
> > > with:
> > >    wsgi_app_str = getattr(settings, "WSGI_APPLICATION",
> > >                           "django.core.handlers.wsgi.WSGIHandler")
> > >    wsgi_app = import_object(wsgi_app_str)
>
> > >    try:
> > >        handler = AdminMediaHandler(wsgi_app, admin_media_path)
>
> > If this is all we need to do, then why didn't you say so? My
> > understanding of your original proposal was that we needed to
> > integrate Paste for some reason -- but if we just need to open up a
> > configuration point, then I don't have any particular objections.
> > Write up a patch, docs and tests and lets get it into trunk.
>
> That change simply makes using WSGI middleware possible in the development
> server.
>
> > My only caveat on this is that I want to make sure we do it right.
> > Graham Dumpleton recently(ish) blogged about Django configuration
> > within mod_wsgi [1]. His comments largely concern inconsistencies
> > between the development server and deployment. I still need to fully
> > digest what he has written; if there's any action required or
> > appropriate on our part, I want to make sure we've integrated those
> > changes before we start encouraging widespread use of new WSGI
> > configuration points.
>
> > [1]http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
>
> Inconsistencies between the development server and production environments
> wouldn't be solved with that patch.
>
> Any Django-agnostic development server, like Paste's, would solve it because
> developers will get the same behavior across environments.

Paste has its own problems. Paste server itself does process
environment setup that isn't done by other WSGI hosting mechanisms.
Specifically, it initialises Python logging in a way suited to Paste
based applications. Like with Django development server, you can
develop a Paste based application on Paste server which will then not
work on other WSGI hosting mechanisms.

> This is one of the
> reasons why I recommended Paste Script.
>
> I think Graham is trying to fix a wider problem related to deployment. The
> inconsistency issue in particular could be avoided if the development server
> didn't perform Django-specific routines at startup which no other WSGI gateway
> would do: Not importing any module at startup time; do it lazily instead.

There certainly is a larger problem I also want to address beyond
pointing out the issues with Django deployment, but I haven't even
mentioned them in these posts and don't intend to.

What you are trying to do with using Paste Script/Deploy is tinkering
at the edges of a larger issue you probably don't even know exists or
don't appreciate. Paste Script/Deploy will not solve that larger issue
as there are lots of things it doesn't do. Adopting it will only make
it harder to solve the real problems later on.

Trying to address the bigger issue is going to need some cooperation
between all frameworks and hosting solution authors to come up with a
consistent way of doing certain stuff. Right now though I don't have
time to lay out properly what the issues are or implement a proof of
concept which illustrates the direction one could take to solve the
problem. It may be the case that Paste Script/Deploy could be adapted
to meet that requirement at some point, but by itself, because the
focus of Paste Deploy is more about constructing WSGI components
together to create an application, as opposed to solving the problem
of deployment on a specific hosting mechanism, I feel right now it is
a poor choice.

If time allows I hope to talk to Russell about some of this stuff when
he is at PyCon in Sydney, but it will still need a lot more work after
that.

Ultimately if something doesn't get done to address the bigger issues,
the WSGI deployment (distinct from composing together WSGI components
into an application), will continue to be a dogs breakfast.

Graham

> When called, the "manage" script imports the modules in INSTALLED_APPS to
> generate the list of management commands which triggers other actions which
> would not happen under other servers. Put simply, running the development
> server within the "manage" script is the cause of the inconsistencies.
>
> The other solution I can think of would be doing exactly the opposite: Make
> the WSGIHandler trigger the actions caused by the "manage" script (e.g.,
> importing all the INSTALLED_APPS at startup time, validate models).
>
> > > import_object() is a function I just made up; I'm not sure if there's
> > > something like that in Django already. We could either implement it on
> > > top of importlib or do something 

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Graham Dumpleton]

On Jun 16, 8:11 am, Gustavo Narea  wrote:
> Hello, Graham.
>
> Graham said:
>
> > From what I remember of this thread, haven't been following it too
> > closely though, I would think the idea of relying on WebOb and Paste
> > Deploy is a bad idea.
>
> > There are bigger issues around WSGI deployment that need to be solved
> > and using Paste Deploy as it is now would only make those larger
> > deployment issues even harder to solve in a clean way.
>
> Initially, I suggested Paste Script as a replacement for the development
> server because it doesn't do any Django-specific thing at startup time, which
> then may lead to inconsistencies on deployment.
>
> I did suggest Paste Deploy, but not to solve said inconsistencies. It was
> because of the INI configuration which also supports adding WSGI middleware
> declaratively.
>
> But both of them were ruled out in this thread.
>
> Could you please elaborate on why relying on WebOb would be a bad idea?

Django is how it is. It strives to be self contained as much as
possible. As much as that may cause some people problem as far as
flexibility to do some stuff, in the main it is probably better for
the majority that it is like that.

Also, WebOb isn't the only request/response object package around,
there is also Werkzeug and others. Who is to judge which is really the
best even if one was contemplated for Django as a dependency. Overall,
given Django's goal of being as self contained as possible, why would
it be wrong for Django to modify their existing request object to be
more compatible with a WSGI architecture. I certainly see no middle
ground where all the existing request/response object packages authors
are going to cooperate together and come up with one best practice
implementation that becomes a standard, they cant even agree what to
do about WSGI on Python 3.

End result is that if you choose one third party package over another
you are always going to piss off some people, it is politically a much
easier path for Django to do this sort of stuff itself to achieve
better WSGI interoperability around ability to reuse WSGI components.
By doing so you also avoid the whole problem of release management
where dependent on third party packages and Django authors can stay in
control and dictate their own destiny.

I also look at TurboGears as a an extreme example of where what you
want to do can go and have to shake my head sometimes. The large
number of dependencies that can result in a TurboGears application
sees a huge amount of third party modules being imported, often with
many not actually being used or only minimally used. All this does is
to bloat out the process and causes significant load times for the
applications when first started up causing restrictions on how it can
be hosted. This large dependency graph also causes problems at time
with ensuring you have the exact required versions of all modules for
things to work properly which goes back to the release management
problems.

So, as much as you may see the change as minimal, it is the thin end
of the wedge and Django is doing well with its current approach, so I
really don't see the need to change if the current way of doing things
is working for what Django is trying to provide.

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

Re: Ticket #2594

[Russell Keith-Magee]

On Tue, Jun 15, 2010 at 5:23 AM, Jack Shedd  wrote:
> Back during one the last Chicago bash, I coded up a fix for Ticket 2594, 
> which would ensure template tags collapsed on themselves within the final 
> source of a rendered template.
>
> http://code.djangoproject.com/ticket/2594
>
> Just wondering if anyone's looked at it, if it sucked, etc.

I haven't taken a detailed look at the patch, but I just had a quick
look, and on first inspection it looks reasonably good. The
performance stats are promising, too.

I can see a couple of minor areas for improvement; I've left a comment
on the ticket.

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

Re: Project-wide cache prefix (low-level API)

[Giuseppe Ciotta]

On Wed, Jun 16, 2010 at 1:04 AM, Giuseppe Ciotta  wrote:
> On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck  wrote:
>> On Sun, Jun 13, 2010 at 7:18 AM, lenz  wrote:
>>> Could you share your code with us?
>>> Thanks you!
>>
>> This might help:
>> http://gist.github.com/425403
>
> I have some similar code here: http://gist.github.com/439868
>
> It might be better because it wraps an arbitrary cache backend adding
> prefix handling, it's not limited to memcache.

Uhm, http://gist.github.com/425403 does indeed support an arbitrary
backend, there's just a call to _get_memcache_timeout() which should
be changed in order to make it completely backend agnostic. I left
"*args, **kwargs" signatures everywhere to avoid dealing with
parameters.

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

Re: Project-wide cache prefix (low-level API)

[Giuseppe Ciotta]

On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck  wrote:
> On Sun, Jun 13, 2010 at 7:18 AM, lenz  wrote:
>> Could you share your code with us?
>> Thanks you!
>
> This might help:
> http://gist.github.com/425403

I have some similar code here: http://gist.github.com/439868

It might be better because it wraps an arbitrary cache backend adding
prefix handling, it's not limited to memcache.

It omits the prefix if the key name starts with the domain of the
current Site. This is important for us because sometimes we want to
share cache keys with other clients, and in this situation they
shouldn't be aware of the particular prefix in use.

It lacks coverage of new cache methods added in 1.2.

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

Re: Session overload

[Jeremy Dunck]

On Fri, Jun 11, 2010 at 1:43 PM, Jan Murre  wrote:
> On Fri, Jun 11, 2010 at 3:13 PM, Tom Evans  wrote:
>> On Fri, Jun 11, 2010 at 11:41 AM, jjmurre  wrote:
>>> Hi,
>>>
>>> I am using long living session in the database backend. Because of
>>> Robots I am getting a huge amount of sessions. I googled if there is
>>> some kind of Session middleware that does user-agent blacklisting and
>>> does not create new sessions in the database for Robots accessing the
>>> site. I did not find anything. Would this be possible at all?

FWIW, sessions should only be written to the DB if they are modified,
and you can avoid that by checking User.is_authenticated first.

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

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello, Graham.

Graham said:
> From what I remember of this thread, haven't been following it too
> closely though, I would think the idea of relying on WebOb and Paste
> Deploy is a bad idea.
> 
> There are bigger issues around WSGI deployment that need to be solved
> and using Paste Deploy as it is now would only make those larger
> deployment issues even harder to solve in a clean way.

Initially, I suggested Paste Script as a replacement for the development 
server because it doesn't do any Django-specific thing at startup time, which 
then may lead to inconsistencies on deployment.

I did suggest Paste Deploy, but not to solve said inconsistencies. It was 
because of the INI configuration which also supports adding WSGI middleware 
declaratively.

But both of them were ruled out in this thread.

Could you please elaborate on why relying on WebOb would be a bad idea?

Cheers.
-- 
Gustavo Narea .
| Tech blog: =Gustavo/(+blog)/tech  ~  About me: =Gustavo/about |

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

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello.

Russell said:
> > It should be easy, specially since you already use WSGI middleware in
> > that server internally (i.e., the AdminMediaHandler).
> > 
> > In runserver.py, you could replace:
> >try:
> >handler = AdminMediaHandler(WSGIHandler(), admin_media_path)
> > 
> > with:
> >wsgi_app_str = getattr(settings, "WSGI_APPLICATION",
> >   "django.core.handlers.wsgi.WSGIHandler")
> >wsgi_app = import_object(wsgi_app_str)
> > 
> >try:
> >handler = AdminMediaHandler(wsgi_app, admin_media_path)
> 
> If this is all we need to do, then why didn't you say so? My
> understanding of your original proposal was that we needed to
> integrate Paste for some reason -- but if we just need to open up a
> configuration point, then I don't have any particular objections.
> Write up a patch, docs and tests and lets get it into trunk.

That change simply makes using WSGI middleware possible in the development 
server.


> My only caveat on this is that I want to make sure we do it right.
> Graham Dumpleton recently(ish) blogged about Django configuration
> within mod_wsgi [1]. His comments largely concern inconsistencies
> between the development server and deployment. I still need to fully
> digest what he has written; if there's any action required or
> appropriate on our part, I want to make sure we've integrated those
> changes before we start encouraging widespread use of new WSGI
> configuration points.
> 
> [1] http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html

Inconsistencies between the development server and production environments 
wouldn't be solved with that patch.

Any Django-agnostic development server, like Paste's, would solve it because 
developers will get the same behavior across environments. This is one of the 
reasons why I recommended Paste Script.

I think Graham is trying to fix a wider problem related to deployment. The 
inconsistency issue in particular could be avoided if the development server 
didn't perform Django-specific routines at startup which no other WSGI gateway 
would do: Not importing any module at startup time; do it lazily instead.

When called, the "manage" script imports the modules in INSTALLED_APPS to 
generate the list of management commands which triggers other actions which 
would not happen under other servers. Put simply, running the development 
server within the "manage" script is the cause of the inconsistencies.

The other solution I can think of would be doing exactly the opposite: Make 
the WSGIHandler trigger the actions caused by the "manage" script (e.g., 
importing all the INSTALLED_APPS at startup time, validate models).


> > import_object() is a function I just made up; I'm not sure if there's
> > something like that in Django already. We could either implement it on
> > top of importlib or do something different.
> 
> Django has django.utils.importlib.load_module, which mirrors the
> importlib tools available in Python 2.7. This method is used
> extensively in Django as a way of implementing extensions and backends
> for various features.

Good, I'll keep that in mind.


> > I did *not* say Django or the current request objects were "less
> > mature". I called "less mature" any potential *change* *in* *Django*
> > in order to solve problems WebOb already solves.
> 
> We have two choices here:
>  * A small set of (possibly complex) changes to fix bugs in Django's
> request layer.
>  * A large set of changes to replace Django's request layer with WebOb.
> 
> I simply don't accept that (1) is necessarily more complex than (2).
> Replacing core infrastructure is *never* a trivial activity, and in
> this case, replacing a piece of core infrastructure means introducing
> a major dependency into Django as a framework. Simply stating "WebOb
> is better" won't convince me here -- you'll need to demonstrate why.

>From a WSGI/interoperability side of things, it's better because it's 
stateless. Every change you make is propagated/applied to the WSGI environ, 
not kept to itself.

As for Django-specific things, I think the HttpRequest object should set 
environ['REMOTE_USER'] to request.user.username when request.user is set to an 
authenticated user... for example.

>From a broader non-WSGI-specific perspective, WebOb also provides getters and 
setters that proxy the environ to many things not covered by 
HttpRequest/WSGIRequest in Django: In Django requests, the headers are 
available under request.META["HTTP_*"] and their values are *always* 
*strings*. WebOb lets you handle then using appropriate Python types; e.g., 
the content length is an integer, the Date header is a datetime object.

Here's the complete list of getters/setters:
http://pythonpaste.org/webob/class-webob.Request.html
and, just in case, here's the source code:
http://bitbucket.org/ianb/webob/src/tip/webob/request.py#cl-88

If these reasons are not enough to add WebOb as a dependency, I'm still 
willing to provide a 

Feature request: coalesce for aggregates

[David Gouldin]

I would love to see the aggregate classes (Sum, Avg, etc) take an
optional second parameter that becomes the value in a coalesce
statement in the resulting query.  Basically, this would function a
lot like dict.get.  Right now the only option is to resolve to None.

If, for instance, you could say Sum('foo', 0), it would turn into
COALESCE("foo", 0) as "foo__sum" and result in a return of
{'foo__sum': 0} where no matching records with non-null values for
column "foo" were fetched by the query.

Thoughts?

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

Re: Imports in the tutorial

[Brian Luft]

This topic came up in discussion today and Peter pointed us here.
Kudos to Andrew for showing initiative.

Short of new tutorials, I think the best service we could do for the
(beginner) community is to at least call out a sidebar that provides
some brief context around whether or not to namespace by project.
Since this is a matter of personal preference the responsible thing is
for the documentation to make people aware of the choices and what the
associated trade-offs are. It seems like this could be done in a few
paragraphs and would serve to concisely indicate that:

* there are different ways to do it
* each has its (subjective) pros/cons
* Django isn't endorsing a particular style but has chosen one for the
sake of convenience in the tutorial

-Brian
.
On Jun 12, 7:34 am, Andrew Godwin  wrote:
> On 12/06/2010 01:03, Russell Keith-Magee wrote:
>
> > What - very very quickly? I don't see the problem :-)
>
> Well, that wasn't quite the quality I was going for, but you never know.
>
> >> Problem is there's several things that could go in a part 5 (in addition 
> >> to all of those there currently), like:
>
> >>   - Making your apps reuseable (so things like removing project name 
> >> imports, adding a setup.py, general python packaging theory)
> >>   - Using virtualenv to run multiple copies of apps/projects/Django 
> >> side-by-side on a development box
> >>   - Basic deployment onto servers (this is kind of covered elsewhere, so 
> >> perhaps just a pointer, or refine those docs with more common pitfalls)
>
> > That sounds like three potential tutorials to me. Better get your
> > pencil nice and sharp :-)
>
> > Honestly - getting a good first draft is the hardest part. Working out
> > a good example, working out a seizable order for presentation within
> > he tutorial, and getting even a rough first cut at the text is the
> > biggest hurdle. Once we have that, it's relatively simple to knock a
> > draft into shape and fit it into a bigger picture
>
> Right, but I really think reuseability, packaging and virtualenv is a
> combination that could be worked into one tutorial part (they tend to be
> quite long, but I'm not sure if that's an overwhelmingly good thing).
>
> If nobody has any particular suggestions, I'll try to cook up a very
> basic outline/first draft this week, and see what people think. I'm
> unfortunately not that much of a heavy virtualenv user, so I might just
> take a stab at the first part, but I feel like there really does need to
> be a bit more tutorial after all these years. I find it even funnier
> that the section I'm proposing to add isn't one of those in the "Coming
> Soon" section.
>
> Andrew

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

Re: Class based generic views in 1.3?

[Nick Fitzgerald]

Another option that hasn't come up is to just have a custom __setattr__ that
won't let users write to self (therefore providing primitive thread safety).
I don't think it is a /good/ option, but I am just throwing it out there for
completeness.

_Nick_



On Tue, Jun 15, 2010 at 7:10 AM, Patryk Zawadzki wrote:

> If you don't mind, I'll talk a bit more to myself.
>
> On Tue, Jun 15, 2010 at 3:38 PM, Patryk Zawadzki 
> wrote:
> > I really don't think we should add anti-moron filters at the framework
> > level past documenting "taking care to ensire immutability of view
> > instances".
>
> This came out a bit harsh. What I mean is: teach users how to write
> thread-safe views (classes or not) and ignore those who refuse to do
> it. They either know what they're doing or there is really no point in
> forcing the help upon them.
>
> --
> Patryk Zawadzki
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

'exists' parameter for pre_save signal

[George Sakkis]

Apologies if this has come up before, I didn't find anything related
in the archives.

As Model.save() is called both for inserts and updates, it would
sometimes be useful for pre_save listeners to know whether the
instance exists or not. This information is sent with post_save but by
then it may be too late (e.g. under some conditions you may want to
prevent an insertion from happening). In the current save_base()
implementation, pre_save is sent before the instance's existence is
determined, so I'm not sure if postponing it would break existing
code. If there is no backwards compatibility issue, I can open a
ticket and send a patch for it.

George

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

Re: [gsoc] app loading status + questions

[Karen Tracey]

On Tue, Jun 15, 2010 at 10:46 AM, Arthur Koziel wrote:

> 4. Also in the same changeset, the 'nesting_level' and 'can_postpone'
> variables were introduced. These fixed a problem where the package is still
> being imported by Python and the model module isn't available yet. Again, I
> couldn't reproduce this problem.


Don't think I know anything about the other questions, but nested calls to
load_app I've seen. See:

http://code.djangoproject.com/ticket/13335

and its fix.

Karen

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

Re: [gsoc] app loading status + questions

[Alex Gaynor]

On Tue, Jun 15, 2010 at 9:46 AM, Arthur Koziel  wrote:
> Hey there,
>
> I'm making some progress on the app loading gsoc project. I'm still in the 
> process of writing tests for the AppCache. It took me longer than I've 
> thought. However, I'm really confident that I'll finish the testing stuff 
> this week and move on to writing the new App class. There are still some 
> things that I don't understand. I've written them down below, and would 
> really appreciate it if someone could take a look at them.
>
> 1. The AppCache is initialized early when the test cases are run, which means 
> that not everything can be tested properly. I'm currently using a standalone 
> script, but it would be better if Django's test runner could run the tests 
> without initialized the AppCache. Are there already plans to change this 
> (maybe in the testing improvement gsoc project?)
>

So my one thought here is to allow the AppCache to work with a custom
installed apps list, rather than a settings provided one, that way it
can be formally unittested, without respect to it's enviroment (the
issue here is the borg pattern, as you mention, frankly I think that
code is doing more harm than good if it impedes good testing, as you
say, who is actuall instantiating app caches?).

> 2. Some methods are using a lock in order to be thread-safe[0]. I haven't 
> found a good way to test this nor can I reproduce the threading problems when 
> removing the locks. Is there a good way in Python to test concurrency 
> problems? (should such problems even be tested at all?)
>

Concurrency problems are hard, and it's not just a Python problem.
Frankly, I suspect some of the methods are threadsafe even wtihout the
locks, but of course I'm not sure I can prove that.

> 3. Changeset 5919[1] modified the AppCache class to use the Borg/Monostate 
> pattern. However, I haven't found a single case where there is more than one 
> instance created. Does someone know a case?
>
> 4. Also in the same changeset, the 'nesting_level' and 'can_postpone' 
> variables were introduced. These fixed a problem where the package is still 
> being imported by Python and the model module isn't available yet. Again, I 
> couldn't reproduce this problem. As Malcolm Tredinnick notes in the comments 
> to Ticket 1796 [3], writing a test case for this is difficult as the problem 
> is dependent on hardware/OS/etc. Has anyone here run into similar problems or 
> can reliably reproduce the error? (and is there any way to contact Malcolm?)
>
> 5. The app_errors attribute/the get_app_errors method doesn't seem to be used 
> at all. Is there a reason why it's still there?
>
> Arthur
>
> [0]: 
> http://code.djangoproject.com/browser/django/trunk/django/db/models/loading.py#L124
> [1]: http://code.djangoproject.com/changeset/5919
> [2]: http://code.djangoproject.com/ticket/1796#comment:65
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

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

Re: Class based generic views in 1.3?

[Patryk Zawadzki]

If you don't mind, I'll talk a bit more to myself.

On Tue, Jun 15, 2010 at 3:38 PM, Patryk Zawadzki  wrote:
> I really don't think we should add anti-moron filters at the framework
> level past documenting "taking care to ensire immutability of view
> instances".

This came out a bit harsh. What I mean is: teach users how to write
thread-safe views (classes or not) and ignore those who refuse to do
it. They either know what they're doing or there is really no point in
forcing the help upon them.

-- 
Patryk Zawadzki

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

Re: Class based generic views in 1.3?

[Patryk Zawadzki]

After giving it more thought:

The supposed View class is a pure utility class that is close to a
module. It does not represent a state in an application, it takes
input and returns output, none of it should outlive a "__call__" call.
Therefore I see no reason for a proper implementation to not be
thread-safe. Just treat "self" as immutable past "__init__". In other
words, don't treat "self" as a junkyard for temporary variables.

This is WRONG:

class View(object):
def greet(self):
return HttpResponse('Hi %s' % self.request.POST.get('hello', ''))
def __call__(self, request):
self.request = request
return greet(self)

This is CORRECT and not any harder to design/implement:

class View(object):
def greet(self, request):
return HttpResponse('Hi %s' % request.POST.get('hello', ''))
def __call__(self, request):
return greet(self, request)

I really don't think we should add anti-moron filters at the framework
level past documenting "taking care to ensire immutability of view
instances".

A true moron will always outsmart us with creativity. It's perfectly
possible to write thread-unsafe code without using classes:

req = None

def greet(self, request):
global req
req = request
# ...
return HttpResponse('Hi %s' % req.POST.get('hello', ''))

or even:

def greet(self, request):
greet.foo = request
# ...
return HttpResponse('Hi %s' % greet.foo.POST.get('hello', ''))

:)

-- 
Patryk Zawadzki

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