Hi Paul,
I'd love to have time to play with this, but I don't at the moment. It's
something I've been interested in for a while though, and also something
that I want to take a long hard look at pretty soon. Have you seen:
http://jeroen.concept-q.com/projects/djangoalchemy/? Maybe something you
co
Marty Alchin wrote:
> I'll preface my thoughts with the disclaimer that I have authority
> here, I'm just somebody who's been watching this discussion.
I could care less about "favicon", but do care about the polices. If all you
care about is coding, move on to the next thread.
I have watched
Before anyone gets to excited, I'm going to state up front that I have
*not* replaced django's ORM.
But I do have a small project that gives proof of concept for
automatically integrating SQL Alchemy ORM into the Django ORM. I've
been kicking the idea around for a bit, and after going through the
On 10/5/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> I'll preface my thoughts with the disclaimer that I have authority
> here, I'm just somebody who's been watching this discussion.
I am in such a position, and let me say +1 to everything you said.
Thanks for saving me the effort of having to
On 10/4/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-10-04 at 15:15 -0500, Jeremy Dunck wrote:
> [...]
> > Is there any interest in a patch that modifies Django's built-in
> > decorators to use functools.wraps in order to preserve things like
> > view function doc strings?
>
On 10/4/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > While I'm at it, I think aliasing functools.partial to
> > functional.curry would be good, assuming functools is available.
>
> Providing the functionality is identical. Otherwise it's really, really
> painful to work out why things
On Thu, 2007-10-04 at 15:15 -0500, Jeremy Dunck wrote:
[...]
> Is there any interest in a patch that modifies Django's built-in
> decorators to use functools.wraps in order to preserve things like
> view function doc strings?
Definitely interest from me. It's a bit of a bug at the moment that we
> Since Django already includes curry, which is roughly the same as
> functools.partial, it'd be pretty easy to back-port "wraps" to Django.
>
> Is there any interest in a patch that modifies Django's built-in
> decorators to use functools.wraps in order to preserve things like
> view function doc
It's fairly well-known that decorators are useful, but raises some issues.
Example:
==
def decorate(f):
def wrap(*args, **kwargs):
print "called"
return f(*args, **kwargs)
return wrap
@decorate
def add_to(augend, addend):
"Adds stuff"
return augend + a
Hello all,
Yesterday I had posted an inquiry to django-users about how to make
use of class_prepared. [0] Malcolm gave me a helpful reply, including
a suggestion of adding a hook to allow pre-runtime setup to occur
before executing a shell or request handler.
I have opened a ticket and coded an
Hello all,
I'm the creator of this mess as I'm the issuer of the ticket 3867. I like
django very much, I'm not that great at python yet to contribute so that was
my try to help you guys. If I would only know how much time would be wasted
on this discussion I wouldn't raise that call at all. So sor
I'll preface my thoughts with the disclaimer that I have authority
here, I'm just somebody who's been watching this discussion.
First, this isn't a bug in any sense of the word. It has nothing to do
with any breakage of code. It's a feature request. Let's just get that
straight. Feature requests
On 10/4/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> Just let it go already, and turn your time and attention to a real bug.
But see, it is a real bug, at least to people with a certain work style, and
not one they can fix themselves by runnig their own patched django, since
it's a "bug" with
On Oct 4, 5:41 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> If the ticket was closed by a lead developer, and the decision has so
> far survived many other people begging and pleading on the mailing
> list, it's a safe bet that continuing that process is not likely to
> lead to a favorable out
On 10/4/07, Mikkel Høgh <[EMAIL PROTECTED]> wrote:
> The reason I have not reopened that particular ticket is that I don't
> know
> how you do things in the Django community. I assume that the one that
> closed the ticket was Jacob Kaplan-Moss, and since I respect his
> opinion,
> I considered it
On 10/4/07, Peter Nixon <[EMAIL PROTECTED]> wrote:
> I tried to open the following ticket but it thinks my IP is a spammer, so I
> am sending to the list:
If you create an account in Trac, it won't apply spam filtering to you.
--
"Bureaucrat Conrad, you are technically correct -- the best kind
On Thu, 2007-10-04 at 18:10 +0300, Peter Nixon wrote:
> I tried to open the following ticket but it thinks my IP is a spammer, so I
> am sending to the list:
>
> http://django-rest-interface.googlecode.com/svn/trunk/django_restapi/resource.py
>
> tries to set "request.method = 'POST'" in order
I tried to open the following ticket but it thinks my IP is a spammer, so I
am sending to the list:
http://django-rest-interface.googlecode.com/svn/trunk/django_restapi/resource.py
tries to set "request.method = 'POST'" in order to run PUTs through
request._load_post_and_files() as POSTs as _
On Oct 4, 3:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> This is now just getting rude.
>
> There are over 700 open bugs. If nobody is against fixing them, why are
> they still open? Why hasn't anything happened yet? The horrors! Oh,
> wait, maybe it's that thing where we take small, reg
On Thu, 2007-10-04 at 06:05 -0700, Mikkel Høgh wrote:
> If no one is against this, why hasn't anything happened yet?
> If Jacob, or anyone else, is against it, I wish they would step
> forward and say so. Perhaps even argue as to why.
This is now just getting rude.
There are over 700 open bugs.
If no one is against this, why hasn't anything happened yet?
If Jacob, or anyone else, is against it, I wish they would step
forward and say so. Perhaps even argue as to why.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
On Thu, 2007-10-04 at 09:35 +0200, Gábor Farkas wrote:
> Hi,
>
> before the unicode-change, QueryDict.update handled also updating from a
> MultiValueDict (where on a key there might be several values) correctly.
>
> but now it does not support it correctly,
>
> so if you are updating a QueryD
Hi,
before the unicode-change, QueryDict.update handled also updating from a
MultiValueDict (where on a key there might be several values) correctly.
but now it does not support it correctly,
so if you are updating a QueryDict with a MultivalueDict (for example a
request.GET which contains a
23 matches
Mail list logo
