Re: ManyRelatedManager with explicit intermediary model
On Sep 20, 2011, at 5:50 PM, Tom Evans wrote: On Tue, Sep 20, 2011 at 4:12 PM, Roald de Vries wrote: I don't see how this is different from the create method on the intermediary model. Cheers, Roald PS: I found an open ticket on this, https://code.djangoproject.com/ticket/9475 Here is the function definition for add() on related object manager: add(obj1[, obj2, ...]) As you can see, it can be used to add multiple objects to the relationship in one go, and therefore the arguments to this function would need to change to support what you propose. This would require going through the whole deprecation procedure (2/3 major releases before it is gone), and I guess the pain outweighs the gain on that one. add(*objs, **kwargs) is backward compatible with add(*objs), so that's not the reason a deprecation procedure is needed. The thing that might be considered backward incompatible is the fact that with this new feature, the 'add' method is also defined on ManyRelatedManagers with explicit intermediary models. create() takes **kwargs, but those arguments relate to the instance being created on the other end of the relationship, there would still be no way to specify non-default values for the intermediate model. You would have to do something similar to passing a defaults dictionary to create(), which then makes it different to how create() on an object manager works, and introduces another field that you would have to do some magic to work around. I guess the main thing is what's the point? The argument is over which of these is prettier: model_a_instance.modelb_set.add(model_b_instance) and Intermediate.objects.create(model_a=model_a_instance, model_b=model_b_instance) Beauty contests in code are rather pointless - the documentation has for a long time said that the latter is the only way you can do it, and most developers are now used to that. I don't want to forbid the second form, you may still use it if you like it better. For me, it seems more consistent (which I think is more beautiful) to create a relation between 2 instances from one of the instances, because I always access the other instance through the ManyRelatedManager on the one. If there are enough people that like the first form, then that's the point. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Re-opening 5617?
Heya,
Thanks for the feedback. I quite like the explicit 'STATIC_URL' only
approach, although I think a lot of users would still run into a problem
there, because 'request' isn't also added in explicitly to the Context...
For context, my particular use case is a simple '500.html' template, that
extends a 'base.html' template. I don't use any other context in the base
template other than 'request' and 'STATIC_URL'. In the case of a 500 error,
I'd see the template render correctly, except that it'd look like the user
isn't logged in. Coming across that as a dev that'd confuse the hell out of
me the first time I came across it unless I already understood the 500
Context behavior, and it's not ideal from the end-user perspective either.
I'd imagine that plenty of other setups would have a similar setup, so you
could argue that returning this:
Context({'STATIC_URL': settings.STATIC_URL, 'request': request})
would be an okay thing to do in the default 500 handler.
Personally I think that'd probably be absolutely fine (and the most
sensible default 500 view), although the obvious counter argument is that
that's getting into the realms of special-case, rather than default-case.
(That's not my opinion, but it'd be a valid argument.)
What do you reckon?
Cheers,
Tom
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/Ac1EeU-n6xAJ.
To post to this group, send email to django-developers@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: Django test documentation example not respecting xUnit convention
On 21 September 2011 02:01, Russell Keith-Magee wrote:
>
> For what it's worth, I also think the "convention" is bass ackwards...
> you write "if variable == value", but you write "assertEqual(value,
> variable)"? Where's the consistency in that?
>
My guess is that the choice is somehow connected to Yoda conditions,
where you actually write:
if(5 == x) { ... }
to avoid assigning 5 to x by mistake. If you write all your conditions
like that, then the assert order makes sense.
But Python thankfully doesn't need any of that Jedi stuff.
--
Łukasz Rekucki
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django test documentation example not respecting xUnit convention
On 21 September 2011 07:13, schinckel wrote: > It isn't 'enforced' by Python at a language level, but as dmoisset stated, > it makes the failure messages actually make sense: > "Expected 'foo', got 'bar'". > (paraphrasing failure message: don't have any failing tests to look at right > now. YAY! :) > Matt. My Python 2.7 says: self.assertEqual(result['active'], 2) AssertionError: 1 != 2 So, no. The message in Python is order agnostic. -- Łukasz Rekucki -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Re-opening 5617?
On 21.09.2011, at 11:14, Tom Christie wrote:
> Heya,
>
> Thanks for the feedback. I quite like the explicit 'STATIC_URL' only
> approach, although I think a lot of users would still run into a problem
> there, because 'request' isn't also added in explicitly to the Context...
>
> For context, my particular use case is a simple '500.html' template, that
> extends a 'base.html' template. I don't use any other context in the base
> template other than 'request' and 'STATIC_URL'. In the case of a 500 error,
> I'd see the template render correctly, except that it'd look like the user
> isn't logged in. Coming across that as a dev that'd confuse the hell out of
> me the first time I came across it unless I already understood the 500
> Context behavior, and it's not ideal from the end-user perspective either.
>
> I'd imagine that plenty of other setups would have a similar setup, so you
> could argue that returning this:
>
> Context({'STATIC_URL': settings.STATIC_URL, 'request': request})
>
> would be an okay thing to do in the default 500 handler.
Passing STATIC_URL to the 500.html template is not needed anymore
now that we've added a new {% static %} template tag:
https://docs.djangoproject.com/en/dev/releases/1.4/#static-template-tag
I strongly believe this ticket shouldn't be reopened because of that.
Jannis
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Re-opening 5617?
On 21.09.2011, at 11:24, Jannis Leidel wrote:
> On 21.09.2011, at 11:14, Tom Christie wrote:
>
>> Heya,
>>
>> Thanks for the feedback. I quite like the explicit 'STATIC_URL' only
>> approach, although I think a lot of users would still run into a problem
>> there, because 'request' isn't also added in explicitly to the Context...
>>
>> For context, my particular use case is a simple '500.html' template, that
>> extends a 'base.html' template. I don't use any other context in the base
>> template other than 'request' and 'STATIC_URL'. In the case of a 500 error,
>> I'd see the template render correctly, except that it'd look like the user
>> isn't logged in. Coming across that as a dev that'd confuse the hell out of
>> me the first time I came across it unless I already understood the 500
>> Context behavior, and it's not ideal from the end-user perspective either.
>>
>> I'd imagine that plenty of other setups would have a similar setup, so you
>> could argue that returning this:
>>
>> Context({'STATIC_URL': settings.STATIC_URL, 'request': request})
>>
>> would be an okay thing to do in the default 500 handler.
>
> Passing STATIC_URL to the 500.html template is not needed anymore
> now that we've added a new {% static %} template tag:
>
> https://docs.djangoproject.com/en/dev/releases/1.4/#static-template-tag
Oh, I forgot to say, there is of course also a non-staticfiles version
of the {% static %} template tag in case you don't use the contrib app
staticfiles:
https://docs.djangoproject.com/en/dev/ref/templates/builtins/#static
Jannis
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: confusing things in Trac UI (was: Design decision for #1625...)
Just thought it might be worth mentioning in this thread that django- ticketeer is coming along nicely. (For those who don't know, django- ticketeer is a django front-end for trac installations which was spawned during the djangocon sprints). It now supports viewing & editing tickets, adding tickets, and searching tickets, though a lot of specific aspects of those actions are not yet supported. If anyone is interested in contributing, that would be great - especially people who love front-end work. The project was started because Trac... doesn't provide the best user experience. Ticketeer should. https://github.com/melinath/django-ticketeer Best, Stephen Burrows -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ManyRelatedManager with explicit intermediary model
2011/9/20 Łukasz Rekucki :
> On 20 September 2011 15:52, Roald de Vries wrote:
>> Hi all,
>>
>> Is there a fundamental reason that I'm missing (other than "nobody's taken
>> the trouble of writing it") that I can't do the following? If there isn't
>> I'll create a ticket for it.
>>
>> class R(Model):
>> user = ForeignKey(User)
>> my_model = ForeignKey('MyModel')
>> comment = CharField(max_length=100, blank=True)
>>
>> class MyModel(Model):
>> users = ManyToManyField(User, through=R, null=True)
>>
>> m = MyModel.objects.create()
>> u = User.objects.create_user('roald', 'downa...@gmail.com', 'password')
>>
>>
>> # these things I can't do:
>> m.users.add(u)
>> m.users.add(u, comment='Blablabla')
>>
>> Cheers, Roald
>>
>
> I'm 100% sure there's *at least one* ticket for this. You just need to
> search for it and you'll probably find the discussion of this too.
There certainly is "at least one" ticket :-)
There's the original ticket that introduced m2m intermediate models:
https://code.djangoproject.com/ticket/6095
And there's this one:
https://code.djangoproject.com/ticket/9475
which asks for this feature specifically.
Back when the feature was added (#6095), we discussed add() with
intermediate models that have extra data. If you read the full ticket
history for #6095, and #9475, you can see the edge cases that existed
at the time. Ultimately, we punted on the issue in the interest of
delivering *something*.
I'm certainly interested in the idea, as long as the edge cases can be
managed and/or explained.
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
How to solve MultiValueDictKeyError
Hello friends,
I don't know why Django is so unstable.
Before restarting my computer everything works fine. Django could parse a
simple
POST request without complaining KeyError.
I'm simply making a POST request like this:
curl -v -H "Content-Type: application/json" -A 'Mozilla' -X POST --data
'fees={"fees":{"status":"pending","timeout":5},
"hostel":{"status":"pending","timeout": 3}}'
http://127.0.0.1:8000/api/transaction/add/ > post_data.txt
I also have it in valid dict format like this:
curl -v -H "Content-Type: application/json" -X POST --data
'fees={"fees":[("status","pending"),("timeout",5)],
"hostel":[("status","pending"),("timeout", 3)]'
http://127.0.0.1:8000/api/transaction/add/ > post_data.txt
This worked throughout yesterday. Just hoping to continue from where I left
off, and I can't progress as I would love to.
Trace:
Environment:
Request Method: POST
Request URL: http://127.0.0.1:8000/api/transaction/add/
Django Version: 1.3
Python Version: 2.7.1
Installed Applications:
['django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.admin',
'django.contrib.humanize',
'axes',
'webapp',
'djangorestframework',
'django_tables',
'django_tables.app',
'pagination',
'south',
'djcelery']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'djangoflash.middleware.FlashMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'axes.middleware.FailedLoginMiddleware',
'audit_log.middleware.UserLoggingMiddleware')
Traceback:
File
"C:\Python27\lib\site-packages\django-1.3-py2.7.egg\django\core\handlers\base.py"
in get_response
111. response = callback(request, *callback_args,
**callback_kwargs)
File "C:\wamp\www\edupay\api\views.py" in add_transaction
44. req_fees = json.loads(QueryDict(request.POST.__getitem__('fees')))
File
"C:\Python27\lib\site-packages\django-1.3-py2.7.egg\django\utils\datastructures.py"
in __getitem__
256. raise MultiValueDictKeyError("Key %r not found in %r" %
(key, self))
Exception Type: MultiValueDictKeyError at /api/transaction/add/
Exception Value: 'Key \'fees\' not found in '
The problem is simply understandable, but why didn't Django say this when I
worked on it yesterday. This is not fair Djanjo. It is not!
Somebody please help me.
Thanks
--
Odeyemi 'Kayode O.
http://www.sinati.com. t: @charyorde
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: How to solve MultiValueDictKeyError
Hi, please post in django-users, this mailinglist is about the development of django itself, not about enduser problems. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/x4TGJNjIK8YJ. To post to this group, send email to django-developers@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: RFC: "universal" view decorators
Hi all, Haven't seen a comment on this topic for a few days, so was wondering if a core dev can make a design decision yet. I have some spare time in the remainder of this week, so if the (universal) decorator- approach is chosen, I should be able to finish it shortly (the mixin- approach is a bit harder to estimate). Cheers, Roald On Sep 17, 2011, at 4:32 AM, Alex Gaynor wrote: On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft > wrote: unittest.skip isn't a Mixin, it turns the class into an exception and raises it. It doesn't *turn* a class into anything, it simply returns a function, instead of a new class, and the function raises SkipTest, the point wasn't the implementation detail, but rather the syntax and pattern at work. django.test.utils.override_settings is a mixin and it's terrible, it dynamically creates a new subclass, and overrides 2 methods. It's magic and more complex then need be. a) it's not a mixin b) yes, it creates subclasses, because the alternative is mutating the original class, which isn't how people generally expect decorators to work, we expect them to be syntactic sugar for: A = wrap(*args)(A) such that we can also do B = wrap(*args)(A) and have two classes (or functions). c) I'm not sure how it's magic, but certainly if it's too complex we'd take patches to simplify the implementation. On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote: On Fri, Sep 16, 2011 at 9:47 PM, James Bennett wrote: We have the following constraints: 1. Django supports class-based views. 2. Django supports function-based views (ultimately these are the same thing, which is that Django supports anything as a 'view' so long as it's callable, accepts an HttpRequest as its first positional argument when being called and either returns an HttpResponse or raises an exception). 3. The natural way to add processing in/around a class is subclassing and either overriding or mixing in. 4. The natural way to add processing in/around around a function is decorating. Any solution to this needs to address those constraints, and allow code to look and feel natural. Based on that, some arrangement which allows the same basic logic to exist in a "mixin" (I dislike that word) for classes and a decorator for functions seems most appropriate, even if it does mean having two ways to do things -- that's a distinction I think we can live with, as people will appreciate that it doesn't result in strange-looking code. I agree with all your points, except #3, I think it's an over simplification. There's another way to change a class: class decorators. And there's ample precedent for their use in such a manner, unittest's skip decorators, our own decorators for swapping settings during testing, etc. Alex Alex -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Re-opening 5617?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/21/2011 03:24 AM, Jannis Leidel wrote:
> On 21.09.2011, at 11:14, Tom Christie wrote:
>> I'd imagine that plenty of other setups would have a similar setup,
>> so you could argue that returning this:
>>
>> Context({'STATIC_URL': settings.STATIC_URL, 'request': request})
>>
>> would be an okay thing to do in the default 500 handler.
>
> Passing STATIC_URL to the 500.html template is not needed anymore now
> that we've added a new {% static %} template tag:
>
> https://docs.djangoproject.com/en/dev/releases/1.4/#static-template-tag
Ah, thanks, I'd forgotten about the new {% static %} tag. I agree that
this makes adding STATIC_URL to the handler500 context unnecessary.
Adding the request is a non-starter, IMO; the "request" context
processor isn't even in the default list of TEMPLATE_CONTEXT_PROCESSORS,
so this would mean adding something to the 500 page context that isn't
even added by RequestContext by default. If you want the request object
in your 500 page, you're well into custom handler500 territory.
(IMO it's poor practice to have the 500 template inherit from your
site's normal base template; even if it works now, it's easy to
introduce things into your base template that could break under certain
500 error conditions. Better to have the 500 template standalone.
Likewise with having the 500 template display logged-in status: that
depends on the full session/auth stack, which likely depends on some
kind of external session store - the 500 error could easily be due to
that external store being unavailable in the first place!)
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk553OYACgkQ8W4rlRKtE2e4FwCcDRh9kZZO7syAP4BxfJF+0w2u
xhIAnAu9cYF9Mve4vVMIfkeSeTsOBhKx
=tnRL
-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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Re-opening 5617?
Hey Jannis,
> https://docs.djangoproject.com/en/dev/releases/1.4/#static-template-tag
That's rather nice.
> Adding the request is a non-starter, IMO; the "request" context
> processor isn't even in the default list of TEMPLATE_CONTEXT_PROCESSORS,
> so this would mean adding something to the 500 page context that isn't
> even added by RequestContext by default. If you want the request object
> in your 500 page, you're well into custom handler500 territory.
Yeah, that's me being stupid! I should really have been talking about
having 'user' available, given that
'django.contrib.auth.context_processors.auth' _is_ enabled in
TEMPLATE_CONTEXT_PROCESSORS.
So you _could_ argue that returning 'Context({'user': request.user})' would
be a more useful default than the current empty context.
However I think I'm convinced by Carls point that attempting to do things
with 'user' inside a 500 view might not be best practice in any case.
Thanks for the input both. I've linked from the bugs to here. Should be
nice and clear for anyone hitting them again in the future.
I'm considering making the doc's on the 500
viewmore
obviously explicit about the use of Context, not RequestContext, as
it's a bit of a gotcha, and reasonably easy to miss. IE, putting the text
"...is
rendered with an empty Context..." into a Note block to make it more
obvious. I'll submit a separate bug and patch for that when I've got a
moment.
Cheers,
Tom
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/j2p7-vE7ZM0J.
To post to this group, send email to django-developers@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.
DJango doesn't work with Oracle 11g on Windows 8
Good morning, Unfortunately DJango doesn't work with Oracle 11g Express on Windows 8 x64. DJango error: http://pastebin.com/8tAzsjYh (summary: "No module named cx_Oracle") pip install cx_Oracle output: http://pastebin.com/6Y61PqSM easy_install cx_Oracle output: http://pastebin.com/rCsY63RS Summary: "Unable to find vcvarsall.bat" How can I make DJango work with my Oracle 11g Express database? Thanks for all suggestions, Alec Taylor -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DJango doesn't work with Oracle 11g on Windows 8
http://lmgtfy.com/?q=vcvarsall.bat -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/v6EuZV0jI6AJ. To post to this group, send email to django-developers@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: RFC: "universal" view decorators
I just got my wisdom teeth removed so i'm not exactly feeling the greatest, however I committed what I've done so far and pushed to my copy of django on github. The goal is to provide a Mixin for class based views, a decorator for class based views, a decorator for methods, and a decorator for functions, all from the same codebase. Currently I have the decorator for classes working, and the mixin working. I have the places where the other 2 will go but from a combination of not being very good at decorators, and not feeling well I haven't finished it yet. Anyways here's what I've gotten so far: https://github.com/dstufft/django/compare/master...universal-mixin-decorators On Wednesday, September 21, 2011 at 8:26 AM, Roald de Vries wrote: > Hi all, > > Haven't seen a comment on this topic for a few days, so was wondering if a > core dev can make a design decision yet. I have some spare time in the > remainder of this week, so if the (universal) decorator-approach is chosen, I > should be able to finish it shortly (the mixin-approach is a bit harder to > estimate). > > Cheers, Roald > > > On Sep 17, 2011, at 4:32 AM, Alex Gaynor wrote: > > On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft > (mailto:donald.stu...@gmail.com)> wrote: > > > unittest.skip isn't a Mixin, it turns the class into an exception and > > > raises it. > > > > > > > It doesn't *turn* a class into anything, it simply returns a function, > > instead of a new class, and the function raises SkipTest, the point wasn't > > the implementation detail, but rather the syntax and pattern at work. > > > > > django.test.utils.override_settings is a mixin and it's terrible, it > > > dynamically creates a new subclass, and overrides 2 methods. It's magic > > > and more complex then need be. > > > > > > > > > a) it's not a mixin > > b) yes, it creates subclasses, because the alternative is mutating the > > original class, which isn't how people generally expect decorators to work, > > we expect them to be syntactic sugar for: > > > > A = wrap(*args)(A) > > > > such that we can also do > > > > B = wrap(*args)(A) > > > > and have two classes (or functions). > > > > c) I'm not sure how it's magic, but certainly if it's too complex we'd take > > patches to simplify the implementation. > > > > > > > > On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote: > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 16, 2011 at 9:47 PM, James Bennett > > > (mailto:ubernost...@gmail.com)> wrote: > > > > > We have the following constraints: > > > > > > > > > > 1. Django supports class-based views. > > > > > > > > > > 2. Django supports function-based views (ultimately these are the > > > > > same > > > > > thing, which is that Django supports anything as a 'view' so long as > > > > > it's callable, accepts an HttpRequest as its first positional > > > > > argument > > > > > when being called and either returns an HttpResponse or raises an > > > > > exception). > > > > > > > > > > 3. The natural way to add processing in/around a class is subclassing > > > > > and either overriding or mixing in. > > > > > > > > > > 4. The natural way to add processing in/around around a function is > > > > > decorating. > > > > > > > > > > Any solution to this needs to address those constraints, and allow > > > > > code to look and feel natural. > > > > > > > > > > Based on that, some arrangement which allows the same basic logic to > > > > > exist in a "mixin" (I dislike that word) for classes and a decorator > > > > > for functions seems most appropriate, even if it does mean having two > > > > > ways to do things -- that's a distinction I think we can live with, > > > > > as > > > > > people will appreciate that it doesn't result in strange-looking > > > > > code. > > > > > > > > I agree with all your points, except #3, I think it's an over > > > > simplification. There's another way to change a class: class > > > > decorators. And there's ample precedent for their use in such a manner, > > > > unittest's skip decorators, our own decorators for swapping settings > > > > during testing, etc. > > > > > > > > Alex > > Alex > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, v
Re: DJango doesn't work with Oracle 11g on Windows 8
Please ask questions about using Django (which includes getting things configured to run properly on various different platforms/DBs) on the django-users mailing list. The topic of this list is the development of Django itself. 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-developers@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: Django test documentation example not respecting xUnit convention
On Wed, Sep 21, 2011 at 2:13 AM, schinckel wrote: > It isn't 'enforced' by Python at a language level, but as dmoisset stated, > it makes the failure messages actually make sense: > > "Expected 'foo', got 'bar'". > > Actually that's not the message in Python's unittest (but I've seen messages with that formatting in other xUnit frameworks for other languages) D. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DJango doesn't work with Oracle 11g on Windows 8
On Wed, Sep 21, 2011 at 10:41 AM, Simon Charette wrote: > http://lmgtfy.com/?q=vcvarsall.bat C'mon, that's totally rude and really not OK. If you have the time to answer someone's question then please do so, but if you don't simply telling people to "google for it" or "RTFM" is just impolite. "lmgtfy" in particular mocks the person asking a question. That's unacceptable behavior around here. If you don't have something nice to say, say nothing at all. Jacob -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DJango doesn't work with Oracle 11g on Windows 8
Hi, You should just download and install cx_Oracle directly instead of trying to build it. In theory it should work on Windows 8 without needing a rebuild. :-) http://cx-oracle.sourceforge.net/ If you do actually need to rebuild because of Windows 8 you can use the platform development kit available from Microsoft which includes the compilers and set the environment variable DISTUTILS_USE_SDK=1 Without that you need a copy of Visual Studio installed on your machine. Hope that helps. Anthony On Wed, Sep 21, 2011 at 9:25 AM, Alec Taylor wrote: > Good morning, > > Unfortunately DJango doesn't work with Oracle 11g Express on Windows 8 x64. > > DJango error: http://pastebin.com/8tAzsjYh (summary: "No module named > cx_Oracle") > > pip install cx_Oracle output: http://pastebin.com/6Y61PqSM > > easy_install cx_Oracle output: http://pastebin.com/rCsY63RS > > Summary: "Unable to find vcvarsall.bat" > > How can I make DJango work with my Oracle 11g Express database? > > Thanks for all suggestions, > > Alec Taylor > > -- > 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 > 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-developers@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: is it time to start deprecating parts of contrib
I saw enough +1 on deprecating databrowse that I've opened a ticket: https://code.djangoproject.com/ticket/16907 further action can happen there. -Preston -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django test documentation example not respecting xUnit convention
Yeah, I saw that later when I wrote some tests. I'm sure I saw the style of failure message with some django app tests I wrote ages ago: maybe my brain has failed that test and it was a ruby unit test. Matt. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/vZFC4lC3hUIJ. To post to this group, send email to django-developers@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: DJango doesn't work with Oracle 11g on Windows 8
Thanks Anthony, unfortunately although I made progress, I am still unable to proceed due to an error. manage.py syncdb error: http://pastebin.com/syqxF4m6 On Thu, Sep 22, 2011 at 3:47 AM, Anthony Tuininga wrote: > Hi, > > You should just download and install cx_Oracle directly instead of > trying to build it. In theory it should work on Windows 8 without > needing a rebuild. :-) > > http://cx-oracle.sourceforge.net/ > > If you do actually need to rebuild because of Windows 8 you can use > the platform development kit available from Microsoft which includes > the compilers and set the environment variable > > DISTUTILS_USE_SDK=1 > > Without that you need a copy of Visual Studio installed on your machine. > > Hope that helps. > > Anthony > > On Wed, Sep 21, 2011 at 9:25 AM, Alec Taylor wrote: >> Good morning, >> >> Unfortunately DJango doesn't work with Oracle 11g Express on Windows 8 x64. >> >> DJango error: http://pastebin.com/8tAzsjYh (summary: "No module named >> cx_Oracle") >> >> pip install cx_Oracle output: http://pastebin.com/6Y61PqSM >> >> easy_install cx_Oracle output: http://pastebin.com/rCsY63RS >> >> Summary: "Unable to find vcvarsall.bat" >> >> How can I make DJango work with my Oracle 11g Express database? >> >> Thanks for all suggestions, >> >> Alec Taylor >> >> -- >> 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 >> 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-developers@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-developers@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: DJango doesn't work with Oracle 11g on Windows 8
You're welcome. This can be due to a number of things -- one of them might be the difference between 64-bit and 32-bit -- not sure which one you are using, of course. Everything has to match -- Python, Oracle and cx_Oracle. You might be able to find something out using "Process Explorer" which will tell you what problems you have with loading a particular executable (or DLL in this case -- which is what a PYD file is in any case). Hope some of that helps! Anthony On Wed, Sep 21, 2011 at 9:58 PM, Alec Taylor wrote: > Thanks Anthony, unfortunately although I made progress, I am still > unable to proceed due to an error. > > manage.py syncdb error: http://pastebin.com/syqxF4m6 > > On Thu, Sep 22, 2011 at 3:47 AM, Anthony Tuininga > wrote: >> Hi, >> >> You should just download and install cx_Oracle directly instead of >> trying to build it. In theory it should work on Windows 8 without >> needing a rebuild. :-) >> >> http://cx-oracle.sourceforge.net/ >> >> If you do actually need to rebuild because of Windows 8 you can use >> the platform development kit available from Microsoft which includes >> the compilers and set the environment variable >> >> DISTUTILS_USE_SDK=1 >> >> Without that you need a copy of Visual Studio installed on your machine. >> >> Hope that helps. >> >> Anthony >> >> On Wed, Sep 21, 2011 at 9:25 AM, Alec Taylor wrote: >>> Good morning, >>> >>> Unfortunately DJango doesn't work with Oracle 11g Express on Windows 8 x64. >>> >>> DJango error: http://pastebin.com/8tAzsjYh (summary: "No module named >>> cx_Oracle") >>> >>> pip install cx_Oracle output: http://pastebin.com/6Y61PqSM >>> >>> easy_install cx_Oracle output: http://pastebin.com/rCsY63RS >>> >>> Summary: "Unable to find vcvarsall.bat" >>> >>> How can I make DJango work with my Oracle 11g Express database? >>> >>> Thanks for all suggestions, >>> >>> Alec Taylor >>> >>> -- >>> 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 >>> 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-developers@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-developers@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-developers@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: DJango doesn't work with Oracle 11g on Windows 8
Hi Anthony, I'm running 64-bit Python 2.7, with 64-bit cx_Oracle. On Thu, Sep 22, 2011 at 2:16 PM, Anthony Tuininga wrote: > You're welcome. This can be due to a number of things -- one of them > might be the difference between 64-bit and 32-bit -- not sure which > one you are using, of course. Everything has to match -- Python, > Oracle and cx_Oracle. You might be able to find something out using > "Process Explorer" which will tell you what problems you have with > loading a particular executable (or DLL in this case -- which is what > a PYD file is in any case). Hope some of that helps! > > Anthony > > On Wed, Sep 21, 2011 at 9:58 PM, Alec Taylor wrote: >> Thanks Anthony, unfortunately although I made progress, I am still >> unable to proceed due to an error. >> >> manage.py syncdb error: http://pastebin.com/syqxF4m6 >> >> On Thu, Sep 22, 2011 at 3:47 AM, Anthony Tuininga >> wrote: >>> Hi, >>> >>> You should just download and install cx_Oracle directly instead of >>> trying to build it. In theory it should work on Windows 8 without >>> needing a rebuild. :-) >>> >>> http://cx-oracle.sourceforge.net/ >>> >>> If you do actually need to rebuild because of Windows 8 you can use >>> the platform development kit available from Microsoft which includes >>> the compilers and set the environment variable >>> >>> DISTUTILS_USE_SDK=1 >>> >>> Without that you need a copy of Visual Studio installed on your machine. >>> >>> Hope that helps. >>> >>> Anthony >>> >>> On Wed, Sep 21, 2011 at 9:25 AM, Alec Taylor wrote: Good morning, Unfortunately DJango doesn't work with Oracle 11g Express on Windows 8 x64. DJango error: http://pastebin.com/8tAzsjYh (summary: "No module named cx_Oracle") pip install cx_Oracle output: http://pastebin.com/6Y61PqSM easy_install cx_Oracle output: http://pastebin.com/rCsY63RS Summary: "Unable to find vcvarsall.bat" How can I make DJango work with my Oracle 11g Express database? Thanks for all suggestions, Alec Taylor -- 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 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-developers@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-developers@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-developers@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-developers@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: DJango doesn't work with Oracle 11g on Windows 8
Hi Anthony, Hi Alec, It's great that you're making progress on this issue, but as Karen already noted your discussion is off-topic for this list. So please move it to either django-users or some private channel. Thanks in advance, Lukasz Rekucki -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: "universal" view decorators
On Sep 21, 8:44 am, Donald Stufft wrote: > > The goal is to provide a Mixin for class based views, a decorator for class > based views, a decorator for methods, and a decorator for functions, all from > the same codebase. > > Currently I have the decorator for classes working, and the mixin working. I > have the places where the other 2 will go but from a combination of not being > very good at decorators, and not feeling well I haven't finished it yet. I like the overall direction of this approach (mixin class as the root container of functionality) - but a number of technical issues still need to have a resolution demonstrated (ie the decorating function behavior) One, perhaps pony, of a universal approach, would be to convert the decorator kwargs into class attributes, so that they could be overriden in subclasses of a decorated parent, something easy to do with mixins as the starting point. Also on a somewhat related note, a better option for middleware process_view to interact with class based views -Preston -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
