New Uvicorn release. (Alternative to Daphne for Django Channels)

[Tom Christie]

Hi folks,

I've been putting a lot of work into Uvicorn lately.
It's an ASGI server, similar to Daphne, and can be used as the server to 
run Django channels (amongst other things).

https://www.uvicorn.org/

It's got lots of nice behavior around resource limiting, graceful restarts, 
support for pypy and windows, fast uvloop/httptools or wsproto/wsaccel 
options for cpython, etc...

I think we're getting towards the point that it might be worth adding 
alternate servers to the official Django channels documentation,
but I'd like to get a bit more feedback from folks using the server for 
channels, on if there are any integration issues that I'm not aware of.

(I expect that most folks using uvicorn at the moment are using it with API 
Star, rather than channels.)

There's also another ASGI webserver, Hypercorn...

https://github.com/pgjones/hypercorn

I'd also be keen to get any feedback from folks running django channels 
with either `uvicorn` or `hypercorn`.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3f02a37b-3d18-44d7-b70a-a63c73427ba9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rest Framework and Swagger

[Tom Christie]

https://github.com/marcgibbons/django-rest-swagger

On Saturday, 5 November 2016 16:17:10 UTC, pradam.programming wrote:
>
> Hi Guys,
>  Please I need an advice on the best approach to take on the following 
> issues.
>
> How can i Implement Swagger for CBV and FBV in rest framework ...?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/19d26fb5-9875-4388-9a29-4438720dbd54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django 1.9, migrations SUCK

[Tom Christie]

I'd suggest using `country = forms.ChoiceField(choices=[])` in the form 
declaration itself, and having the form `__init__()` method populate the 
*actual* set of choices. That way the allowable set of choices will always 
reflect whats currently in the DB at the point that the view runs.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/288ec271-0118-46f5-93ba-089343e11cf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Rest Framework Custom Viewsets.

[Tom Christie]

Good stuff - make sure to add it to the django packages grid, 
here: https://www.djangopackages.com/grids/g/django-rest-framework/

You could also create a docs pull request to add a "Third Party Packages" 
to the viewsets section, 
here: http://www.django-rest-framework.org/api-guide/viewsets/#viewsets

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/99abb4b4-b91c-4356-9bf2-1d175f5a0170%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No Downtime Code Releases

[Tom Christie]

I'd also recommend against splitting your models into a separate repo.

There's a decent article on migrations without downtime 
here: http://pankrat.github.io/2015/django-migrations-without-downtimes/

Essentially "don't run your migrations at the same time as you deploy" and 
"split deployment/migration process into multiple steps, so you don't ever 
need to be in maintenance mode". Doing this is more work, so weigh those 
costs against your costs from being in maintenance mode for a few seconds 
every now and then, and figure out which is more important from a business 
point of view.

For your other consideration of "smaller releases" I'd strongly recommend 
feature flags. Together with a well-tested codebase they'll make it far 
easier to get to continuous integration and release.

Small, frequent releases also require good monitoring. I'd recommend taking 
a look at opbeat on that front.

Cheers,

   Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/80cfacb0-5282-4148-8b5e-f69768639c22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Domain Driven Development

[Tom Christie]

Hi Alex,

I've written previously about encapsulation and Django models 
, and I think 
that's kinda relevant here.
If you apply the policy "never write to a model or call .save() directly" 
then yes, you can ensure that the only access points
for modifying the state of eg 'line items', is eg the owning 'order' 
instance.

In some cases there may not be an order instance as such (eg if you simply 
have an order id against the line items, but no fully fledged 'order' table 
in your database) in which case you'd apply the encapsulation either in the 
LineItem manager class, or in a helper class that represents and interacts 
with orders, but does not map directly to a database table itself.

A final consideration here is that these sorts of case *might* map well to 
cases where you want an element of document-structure in your data models, 
rather than relational  structure. (eg. a JSON field against the order that 
stores line item data) that call depends on what information you're going 
to need to index aggregate etc. Probably not what you need, but worth 
mentioning as an option.

Hope that helps give some food for thought.


  T.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e390b879-21c3-4f93-935c-768d4b89ae8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django + microservices: What's correct approach?

[Tom Christie]

> Create a Django project for each micro-service or all using the same 
project?

Different projects.

> Micro-services must communicate themselves using the same REST API, some 
way for better approach?

The API *is* the service boundary yup.

> How to deploy the project: Running "python manage.py runserver" or 
something like "python manage.py start MY_MICROSERVICE"?

Same way you'd deploy any other Django service.

>  How to communicate the services for reduce response time and using async 
way?

Just use requests, and don't worry about this.

But finally and most importantly:

Almost certainly *don't bother*. Micro-services have a large up-front cost, 
and they're not worth it unless you've got a good reason to do so (eg you 
have a large service and you know that you need to scale different 
components independently, and ensure distributed reponsibilities across a 
large engineering team)

Unless you know that you've got an issue like that and you can pinpoint it, 
it's unclear why a microservices approach would be preferable. (If you're 
purely looking at this as a learning exercise then that's slightly 
different)   

A single project providing an API for your front end is *far* more likely 
to be what you're actually looking for.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7a3005a8-0ecc-4b6e-b614-c5d536b610dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django + microservices: What's correct approach?

[Tom Christie]

Django REST framework is a general purpose API toolkit, and more than 
capable of building microservice-type services. Likewise there are plenty 
of frameworks in alternative languages that are also suitable for building 
APIs that could be characterized as 'microservice'.

The reason you're finding it hard to discover much on the subject is 
probably due to microservices being an architectural style, rather than a 
framework choice.

Are there any *specific* technical issues that you're looking for help 
with? What sort of service are you building, and is this for a Web App 
frontend, a native client, both or something else?

Aside: Unless you've got automated deployments nailed, great monitoring, a 
heavily used service with a really nicely designed separation of concerns, 
and a culture of personal responsibility for the engineers taking 
code-to-deployment then the microservices probably (as a super-rough rule 
of thumb) isn't worth the extra up-front infrastructure it requires.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f74af5ce-8344-47c9-b9b1-aed1edd135a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about subdomains.

[Tom Christie]

> Are these 3 different apps in 1 project, or 3 different projects.

Either are possible. It depends on the application.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a4e4bca6-fbdb-4442-81e5-c52c6b6881f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Securing Browseable API & Mocking Models

[Tom Christie]

Hi Ari,

It looks like Django REST swagger has an `is_admin` flag you can use...

http://django-rest-swagger.readthedocs.org/en/latest/settings.html#is-superuser

You'll probably also want to disable the browsable API by removing it from 
the 'DEFAULT_RENDERER_CLASSES' key in the 'REST_FRAMEWORK' settings 
dictionary.

> Also, in unit tests (particularly of views) I'd like to mock the model, 
rather than have the models call against the database.

That's an interesting one. I've actually started to more properly consider 
doing this throughout the REST framework codebase, and probably also 
introduce some supported API for mock objects and mock querysets.

There's actually very little you need to do for this...

* Querysets should be any list-like structure. If you're mocking a detail 
view, they'll also need to implement a `.get(...)` method.
* Some of the filter classes require the queryset to expose a 
`.filter(...)` or `.order_by(...)` method. If you're not testing that you 
probably won't need it.

Also if you've any ModelSerializers or Serializer.save() code that's under 
test you'd need to mock those method to prevent any actual database saves, 
that's probably a bit more awkward, but for many test cases you could 
probably avoid that (eg pass a different serializer class to the view under 
test)

Couple of places we do similar things in the REST framework tests:

https://github.com/tomchristie/django-rest-framework/blob/master/tests/utils.py#L5-30
https://github.com/tomchristie/django-rest-framework/blob/version-3.1/tests/test_pagination.py#L454-481
 
(version-3.1 branch)

Nothing very consistent there yet, but probably worth a look.

Hope that helps!

On Monday, 2 February 2015 14:21:22 UTC, Ari King wrote:
>
> Hi,
>
> In the last couple of days I started experimenting with Django and Django 
> Rest Framework. Using the excellent documentation and ViewSets I was able 
> to create a PoC API in a very short time. I was also able to add Django 
> Rest Swagger  for 
> documentation of the API. However, at this point I'd like to secure access 
> to the Swagger API documentation, but I'm unclear on how to limit access to 
> Django 'superusers.' I'd appreciate clarification on how to do so. 
>
> Also, in unit tests (particularly of views) I'd like to mock the model, 
> rather than have the models call against the database. Are there any Django 
> "conventions" or best practices for doing so?
>
> Thanks.
>
> Best,
> Ari
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1175785d-dc78-4c81-9bfb-99bf8953e846%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: read GET and POST simultaneously?

[Tom Christie]

Absolutely no problem at all doing that.
The only thing that's confusing here is that `request.GET` is a misleading 
name.
The query parameters are available on any request, regardless of the HTTP 
method.

> Is this reliable behavior across browsers?

Yes.

> Is it a dumb idea for reasons I haven't thought of? 

No.

Cheers,

  Tom

On Tuesday, 27 January 2015 03:26:52 UTC, Eric Abrahamsen wrote:
>
> As far as I can tell (testing with the Conkeror web browser), it's 
> possible to read both GET and POST at once: if a user POSTs to a URL 
> containing GET parameters, you can get them both in the view. 
>
> Is this reliable behavior across browsers? Is it a dumb idea for reasons 
> I haven't thought of? 
>
> A bit of background, in case there's simply a better approach to this: 
>
> I'm using GET parameters to create custom model formsets: depending on 
> those parameters, I construct different initial data, and set some of the 
> form fields to use hidden input -- this makes it much easier for users 
> to input bulk model instances without having to mess with endless 
> drop-down menus. 
>
> But I need the same initial data when handling the POST request, which 
> means I either need to re-read the GET parameters in the POST method 
> (I'm not sure that's reliable), or I need to otherwise store the values 
> of those parameters (ie in the session), and read them again from there 
> during POST. 
>
> URL arguments would be stable, but there are many different possible 
> parameters, half of which won't even be present for any given formset, 
> and I don't know how to handle that using URL segments. 
>
> I'd be interested in hearing any thoughts on this! 
>
> Thanks, 
> Eric 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e86ddccc-8068-4d73-bbff-cb6e2a3ec8b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use django rest framework with dynamoDB

[Tom Christie]

Maybe take a look at 
this... https://github.com/gtaylor/django-dynamodb-sessions

>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a25478b0-5b52-4975-a4b7-5c255bb60d1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Seeking for advise on usage MySQL together with MongoDB

[Tom Christie]

Thanks Cal. If you do get the time that'd be fab, positive criticism is 
always useful. Equally please don't feel obligated - sure you weren't 
expecting to have to give a blow-by-blow breakdown of pain points you 
found. :p

May be worth taking any further convo over to the django-rest-framework 
list, but either forum works for me.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/12f78416-ab39-4646-a89c-286668d3fa64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Seeking for advise on usage MySQL together with MongoDB

[Tom Christie]

Hi Cal,

> DRF has it's own problems and (again imho) does not solve the problems it 
was originally designed to fix. Attempting to build anything beyond "out of 
the box CRUD" requires hacky/unclean workarounds, with most of your time 
spent fighting against the shortcomings of DRF rather than working with it.

I'm slightly at a loss to understand what set of pain points could have 
left you with that impression, but it'd be helpful to get a better idea.

Perhaps some of the awkwardnesses in 2.x serializers that have been 
addressed with the 3.0 release?
Perhaps a misunderstanding that viewsets/routers are intended to be the 
canonical way to use REST framework?

The 'build anything beyond "out of the box CRUD"' comment is particularly 
surprising to me because of all the work I do in REST framework *none* of 
it is CRUD, and the design decisions in REST framework are very explicitly 
towards it being an agnostic Web API toolkit, that just *happens* to also 
have easy support if basic CRUD stuff *does* happen to be what you want. Eg:

* Validation that's cleanly decoupled from Django's ORM, but that can also 
work seemlessly with it if that's what you need.
* Works just fine with regular views, but has a minimal set of pre-provided 
generic views if simple CRUD operations are what you need.
* Viewsets and routers for projects that fit well with a very standard URL 
style, or drop down to views and explicit URL conf otherwise.

I don't want to jump on and just criticize the view point you've presented 
- whatever it is that's left you with that impression is clearly a useful 
data point for me.

What other API toolkits would you look towards as more mature, well 
supported, nicely designed solutions?
Which shortcomings were you fighting against, and what do you think the 
project should be doing differently?

Cheers,

  Tom

On Friday, 12 December 2014 18:05:02 UTC, Cal Leeming wrote:
>
> Hi Collin, 
>
> Just a few comments;
>
> On Fri, Dec 12, 2014 at 5:42 PM, Collin Anderson  > wrote:
>>
>> Hi,
>>
>> Re: the hacker news thread, (sorry for getting a little off topic,) I 
>> just wanted to mention a few places where we've tried to improve some of 
>> those things recently:
>> - The ORM is still slow, but we've added prefetch_related() and improved 
>> select_related() which allows you do use fewer queries. 
>>
> - We've pulled out some of components into separate projects: 
>> django-localflavor, django-contrib-comments, django-formtools, and I 
>> imagine more in the future.
>> - You can now use custom user models.
>>
>
> Custom models is (imho) still unnecessarily complex, something as simple 
> as not requiring a username field requires a lot of work. There have been 
> several instances where migrations had to be scraped due to weird edge 
> cases with custom user models.
>  
>
>> - We're working on an official public API for the model._meta internals 
>> and working towards components only using that. It also means it will be 
>> easier to use non-django models in the admin.
>> - We're working on de-coupling django templates, allowing them to be used 
>> on their own, and making it much easier to use other template engines like 
>> Jinja2.
>> - There's are also quite a lot of people using django-rest-framework for 
>> creating REST apis, which was one thing the thread said django was not good 
>> at.
>>
>
> DRF has it's own problems and (again imho) does not solve the problems it 
> was originally designed to fix. Attempting to build anything beyond "out of 
> the box CRUD" requires hacky/unclean workarounds, with most of your time 
> spent fighting against the shortcomings of DRF rather than working with it.
>
> Building a clean RESTful API in Django is possible, but it requires a lot 
> of custom libs/hacks to make it work properly. For example, you have to 
> create your own method dispatcher/router, which in turn breaks 
> class/dispatch decorators due to the way those are loaded. Or you could 
> throw it all into a single class and split out the functionality using 
> get/post/put, but this is really unclean because each HTTP method is 
> essentially it's own view. Another way is to not use decorators of course. 
> Then you have partial form handling, which I already touched on in another 
> thread [1], so I won't repeat here.
>
> These are just a few examples of annoyances which hinder productivity. 
> That being said, Django is still quite good at a lot of things, and again 
> it comes down to "the right tool for the job". It's all about knowing the 
> strength/weaknesses of your options, and making an appropriate choice based 
> on your use case, making sacrifices dependant on your needs etc.
>
> [1] https://groups.google.com/forum/#!topic/django-users/pZCk4cFVcSI
>
>
>
>> Collin
>>
>> On Wednesday, December 10, 2014 3:21:07 PM UTC-5, Cal Leeming wrote:
>>>
>>> If you're using Django, then there isn't really an alternative, as it's 
>>> really a key selling point of Django.
>>>
>>> Some people

Re: Django Project Website inaccesible

[Tom Christie]

Seconding Larry. I don't see any issue.

On Monday, 27 October 2014 18:06:17 UTC, Dan wrote:
>
> I've been trying to access https://www.djangoproject.com 
> 
>  
> since Friday, but no matter what browser I use on server different systems 
> the connection fails.
>
> There appears to be something wrong the the SSL configuration at the main 
> Django Project website.
>
> Does anyone know if someone is trying to fix it?
>
> --
> Dan
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7ec48dd4-b953-4bb8-8e39-1f813238a938%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

HTML 5 input

[Tom Christie]

See the discussion here: https://code.djangoproject.com/ticket/16630#comment:11

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6e7b76ad-5593-4133-8c1d-15f2ce532426%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Change GFK to FK

[Tom Christie]

You'll probably want to take this approach:

* Create a schema migration, adding the FK.
* Create a data migration, populating the FK data.
* Create a schema migration, removing the GFK.

On Sunday, 28 September 2014 23:15:22 UTC+1, sacrac wrote:
>
> Hi, is posible to change GenericForeingnKey to ForeignKey without losing 
> data?
>
> any link to explain the trick?
>
> I have an old application with GFK but now I want to FK moment but I will 
> not lose data
>
> this is example my models old and below the new models
>
> http://pastebin.com/ym6Scrmd
>
> Cheers
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3730a43f-b926-48d4-be5f-5bcfa2914220%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django REST framework 3 Kickstarter.

[Tom Christie]

Hi all,

I've just launched a Kickstarter project aimed at funding development for a 
major new version of Django REST framework.

There's a whole bunch of really exciting stuff that I'd like to be able to 
work on, including:

   - Faster, simpler and easier-to-use serializers.
   - An alternative admin-style interface for the browsable API.
   - Search and filtering controls made accessible in the browsable API.
   - Alternative API pagination styles.
   - Documentation around API versioning.
   - Triage of outstanding tickets.
   - Improving the ongoing quality and maintainability of the project.

This is only really going to be feasible if I can get some full-time 
development work set aside for the project - hence the kickstarter.

You can checkout the full project details 
here: https://www.kickstarter.com/projects/tomchristie/django-rest-framework-3

We're off to a great start so far, with over 50% funding in just 3 hours!

Thanks to everyone who's been supportive of the project to date, it means a 
lot.

Many thanks,

  Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8b04704c-6ca8-4571-a77c-535250ba6b48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Security release for Django REST framework: 2.3.14.

[Tom Christie]

Cross-posting this 
 
for the benefit of any Django REST framework users who aren't on the REST 
framework mailing list...

The 2.3.14 version of REST framework has just been released to PyPI.

Most importantly this includes a serious security fix related to the 
browsable API, and all users are advised to upgrade as soon as possible.

When generating the login and logout links on the browsable API the request 
path is included as part of the URL, allowing the application to redirect 
back to the original URL after performing the login/logout.  The request 
path here was not being escaped, allowing an attacker to create a link that 
when clicked by the user would run javascript in the context of the 
browsable API.

This exploit appears to work against the latest version of Firefox, but not 
against the latest versions of Chrome, Safari and Internet Explorer.

In summary:

* Users of the current version of firefox, and of some older versions of 
other browsers may be vulnerable.
* The attack requires the user to follow a link that has been generated by 
the attacker.
* The vulnerability requires the browsable API to be enabled, and the user 
to be authenticated in the browser.

Many thanks to the reporter of the issue, Dan Peled (BugSec/CyberSpear).

As always if you believe you have found a security issue with REST 
framework, please raise the issue on the private security mailing list: 
rest-framework-secur...@googlegroups.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/537be97f-f491-4e50-ad5a-ac8031937d4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django response with two HTTP 'WWW-Authenticate' headers

[Tom Christie]

No, I don't believe that Django's response class supports that slightly 
esoteric usage.

As explained by the stackoverflow answer 
here,
 
repeated headers should be treated as being the same as a single header 
containing a comma separated list of values.
That answer appears to indicate that it's valid for the WWW-Authenticate 
header to be used in this way, so 'Negotiate, Basic relam= '.

Also see RFC 2616, Sec 
14 "if more 
than one WWW-Authenticate header field is provided, the contents 
of a challenge itself can contain a comma-separated list of authentication 
parameters.", however I wouldn't be at all surprised if some client 
libraries don't correctly interpret that for you.

Hope that helps...

  Tom

On Monday, 20 January 2014 07:51:05 UTC, Alexey Gusev wrote:
>
> Im developing small intranet web service. I want authenticate users over 
> kerberos in MS AD or with basic auth. For that reason i need to set two 
> 'WWW-Authenticate' http headers in response 401. How can i do it with 
> Django ?
>
> Should be something like this:
>
> Client: GET www/index.html
> Server: HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Negotiate
> WWW-Authenticate: Basic realm="corp site"
>
> This code overwrite header:
>
> def auth(request):
> response = None
> auth = request.META.get('HTTP_AUTHORIZATION')
> if not auth:
> response = HttpResponse(status = 401)
> response['WWW-Authenticate'] = 'Negotiate'
> response['WWW-Authenticate'] = 'Basic realm="  trolls place basic 
> auth"'
>
> elif auth.startswith('Negotiate YII'):
> ...
>
> return response
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b6837442-469c-4c09-bb60-33ee324f0fbb%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Weekend Cardiff

[Tom Christie]

Thanks for that Daniele - will be looking forward to that.
Will make sure to promote it at the next Brighton and London meetups, and 
I'd probably be interested in talking and/or giving a tutorial.
What's the best forum for staying in the loop re. conf organization?

Cheers,

  Tom

On Wednesday, 13 November 2013 23:11:27 UTC, Daniele Procida wrote:
>
> (With apologies if you have already seen this on another email list or 
> newsgroup.) 
>
> The UK's first-ever Django conference will take place on the 7th-9th 
> February 2014 in Cardiff, Wales. 
>
>  
>
> The programme for the event: 
>
> Friday: tutorials and demonstrations (also open to the public) 
> Saturday: talks 
> Sunday: code sprints and clinics 
>
> The conference is Django-focused, but all of all aspects of Python fall 
> within its remit - particularly in the tutorials and workshops. 
>
> A venue has been booked at Cardiff University. 
>
> Registration and ticket sales will open soon, as well as a call for 
> papers. 
>
> To be a success, the conference needs the support of: 
>
> *   people in Wales, the UK and beyond who will participate as attendees 
> or volunteers 
> *   speakers who'd like to give talks or conduct tutorials 
> *   organisations locally and internationally willing to provide 
> sponsorship or other support 
>
> If you can offer support, please get in touch. 
>
> One of the aims of the conference is to establish it as an annual event 
> that will raise the profile in Wales of open-source software in general and 
>  Python in particular, and also bolster the local open-source software 
> community here. 
>
> Above all, however, the intention is to establish the Django Weekend in 
> Cardiff as a meaningful and enjoyable date in the Django/Python calendar. 
>
> We'll publish updates on our website, our Twitter account <
> https://twitter.com/DjangoWeekend> and elsewhere as appropriate. 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/bca169c2-4413-4544-8d71-6de598ed95a0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Geo support with Django Rest Framework

[Tom Christie]

Hi Sanjay,

I would take a look at these two repos:

https://github.com/dmeehan/django-rest-framework-gis
https://github.com/mjumbewu/django-rest-framework-gis

You might also try searching the REST framework issue list as it's likely 
either or both of these were at some point discussed there.
Also try searching the archives for the REST framework discussion group, 
here:

https://groups.google.com/forum/#!forum/django-rest-framework

Hope that helps!

  Tom

On Sunday, 20 October 2013 15:06:26 UTC+1, Sanjay Bhangar wrote:
>
> Hi all, 
>
> I'm developing an app using GeoDjango that requires me to create an 
> API. Ideally, I would output GeoJSON at various API end-points and 
> support a few geo-queries like "within bounding box", etc. 
>
> I have done something similar before without Django Rest Framework and 
> just writing vanilla views, but I thought it would be nice to make use 
> of a lot of the niceties that the framework provides. 
>
> Just wondering if something has dealt with serialization / 
> deserialization of geo models using Django Rest Framework and has any 
> pointers / code to share (or advice on why this is a bad idea :)). A 
> fair amount of internet searching did not turn up anything for me. 
>
> Looking through the docs, it seems like there are reasonable hooks to 
> write custom Serializer, Renderer and Filter classes - just wondering 
> if someone has gone down this road before - and also, potentially, if 
> someone else may find this useful and then I could think about making 
> whatever solution I come up with more generalizable .. 
>
> Also, if there's a better place to discuss this, please let me know :) 
>
> Thanks, 
> Sanjay 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/71f87a56-b0ff-4ff7-9d4c-b47f4bb525f3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Pagination

[Tom Christie]

Hi Hélio,

It looks like you're applying pagination to the rendered JSON string itself.
You want to be paginating the queryset itself.

queryset = Player.objects.filter(name=namepost)
paginator = Paginator(queryset, 20)
return json.dumps([item.to_dict() for item in paginator.object_list])

Hope that helps.

On Thursday, 3 October 2013 14:34:18 UTC+1, Hélio Miranda wrote:
>
> Hi guys.
>
> I'm here with a problem that does not quite know how to solve.
> I have this query:
> result = json.dumps([a.get_json() for a in 
> Player.objects.filter(name=namepost)])
>
> But now I want to return the result with paging, and do not really know 
> how to do ... I've been seeing in the documentation to use the Paginator.
>
> But for example when I do this
> p = Paginator(result, 2)
> print p.count
>
> Gives 1609 ... and the result of the query is 3 records.
>
> Someone can help me?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ee66f864-30c7-450d-806a-763f12313c89%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Error when loading application server

[Tom Christie]

Hi Helio,

  Something somewhere is expecting an integer but receiving an empty string 
instead.
This could be the result of a missing component in the URL eg 
`http://example.com/users//`,
or a field in a JSON or form data request that's missing a value, eg:

{
  "score": ""
  ...
}

Hope that helps.

  Tom

On Wednesday, 3 July 2013 13:13:35 UTC+1, Hélio Miranda wrote:
>
> Hi
> I have a Django application, I am using the tastypie too.
> What happens when meth is my application server, I get this error on a 
> page:
>
> *"error_message": "invalid literal for int() with base 10: ''"*
>
>
> Someone can explain me why?
>
> What do I fix?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Filter more than one level in the related field

[Tom Christie]

Hi Hélio,

  As mentioned 
before, 
it's not really appropriate to consistently cross-post your questions. 
 Folks on either list won't be aware if there question has already been 
answered by someone else, it's more difficult for others to follow the 
threads, and it spams people who follow both lists.
I see this post on both the `tastypie` and `django developers` mailing 
lists - please try to just choose one appropriate forum and post there.

Many thanks,

  Tom

On Friday, 28 June 2013 15:38:51 UTC+1, Hélio Miranda wrote:
>
> is supposed to do research in the related field, as shown here, the 
> documentation
> http://django-tastypie.readthedocs.org/en/v0.9.15/interacting.html
>
> Would filter Entrepreneur by country named Portugal
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: delete file in GridFS by its id

[Tom Christie]

 

Hi Hélio,

  I see that you've posted this question separately on each of the `django 
users`, `mongoengine users`, and `mongoengine developers`.

Please don't cross post questions on mailing lists - pick one appropriate 
mailing list and use that.  If you cross post questions there's every 
chance that other community members will spend time trying to help you out, 
without realizing that you've already resolved the issue in another thread 
on another list.  Posting to a single list is also more helpful for anyone 
else having the same issue later, as they can follow the replies in a 
single thread.

Also please keep in mind when posting to the lists that hundreds or 
thousands of people are going to spend a little bit of time reading and 
considering your questions.  The open source community tends to be very 
generous with its time, but cross-posting to multiple lists means you're 
demanding lots of attention to your questions, when just choosing the right 
list would mean that a smaller number of people would be able to consider 
your question and help you out.

This question is probably most appropriate for `mongoengine users`, so in 
this case just post there.

Many thanks,

  Tom

On Tuesday, 25 June 2013 10:38:08 UTC+1, Hélio Miranda wrote:
>
> Hi
> I have a problem that is how to delete a file from GridFS by its id.
> I am using django and mongoengine.
> To delete files of a certain record I'm doing this:
>
> *marmot = Animal.objects.get(id='51c80fb28774a715dc0481ae')*
> *marmot.photo.delete()*
>
> Now just to delete a file by its id, was trying like this:
>
> *marmot = Animal.objects.get(id='51c86ae18774a70fec1a9fb7')*
> *marmot.photo(id='51c86ae18774a70fec1a9fb5').delete()*
>
> But it gives me the following error: *'GridFSProxy' object is not callable
> *
> Someone can help me? What am I doing wrong?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Newbie CSRF protection questions

[Tom Christie]

One minor correction worth pointing out...

"The first defense against CSRF attacks is to ensure that GET requests are 
>> side-effect free." What's meant by "side effect free"?
>
>  

It means that the request must be idempotent - that if you make the same 
> request on the server multiple times, that you get the same result each 
> time.


That should read: "It means that the request must be 
`safe` 
- that if you make a request it does not modify, create or delete data on 
the server".

If the request is 
idempotent or 
not isn't relevant.  In particular PUT and DELETE requests should be 
idempotent, but they are not safe, and do require CSRF protection.

Cheers,

  Tom

On Saturday, 13 April 2013 02:07:47 UTC+1, testbac...@gmail.com wrote:
>
> Russ,
>
> This is a really great explanation of CSRF vulnerabilities, and I think I 
> have a handle on what I need to do now.
>
> Thanks for taking to time to spell things out for me.
>>
>>
> Best,
>
> Spork
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 CBV - DeleteView - CustomQuery

[Tom Christie]

> Is there a site, where I can found such things like What happens in a CBV 
View?

http://ccbv.co.uk is really great resource.  Can't recommend it highly 
enough.


On Thursday, 21 March 2013 13:23:05 UTC, Christian Schmitt wrote:
>
> Hi, yeah that definitly helps.
> I didn't found a good site where CBVs getting described in that way.
> Is there a site, where I can found such things like
>
> What happens in a CBV View? It's way easier to understand the whole CBV 
> thing. 
> Btw. FBVs are way easier than CBVs but with FBVs I need to copy & paste 
> things like the MarkDeleteClass while in CBVs I could inherit from it.
>
> Am Donnerstag, 21. März 2013 14:11:44 UTC+1 schrieb Tom Christie:
>>
>> In cases like this, rather than rely on overriding the default behavior 
>> of the DeleteView,
>> I'd recommend writing your own base class.
>>
>> It'll be more explicit and more obvious exactly what is going on...
>>
>> from django.views.generic import View
>>
>> class MarkDeletedView(View):
>> """
>> Base class for marking a model instance as deleted.
>> """
>> model = None
>> redirect_url = None
>>
>> def delete(self, request, *args, **kwargs):
>> assert self.model, "model attribute must be set"
>> assert self. redirect_url, "redirect_url attribute must be 
>> set"
>>
>> object = get_object_or_404(self.model, pk=kwargs['pk'])
>> if object.date_deleted is not None:
>> raise Http404
>> now = datetime.datetime.utcnow().replace(tzinfo=utc)
>> object.date_deleted = now.strftime("%Y-%m-%d %H:%M:%S")
>> object.save()
>> return HttpResponseRedirect(self.redirect_url)
>>
>> Then you can create a different view for each model you need this 
>> behavior on, like so...
>>
>> class CustomerDeleteView(MarkDeletedView):
>> model = Customer
>> redirect_view = reverse('customer-list')
>>
>> Hope that helps.
>>
>>   Tom
>>
>> On Thursday, 21 March 2013 12:39:34 UTC, Christian Schmitt wrote:
>>
>>> Hello guys,
>>> I have a question about the django CBV DeleteView, I want to use it but 
>>> not delete the element, i just want to set a delete_date so that it isn't 
>>> visible anymore.
>>>
>>> With FBV my view looked like this:
>>>
>>> def delete(request, customer_id):
>>> customer = get_object_or_404(Customer, pk=customer_id)
>>> if customer.date_deleted is not None:
>>> raise Http404
>>> now = datetime.datetime.utcnow().replace(tzinfo=utc)
>>> customer.date_deleted = now.strftime("%Y-%m-%d %H:%M:%S")
>>> customer.save()
>>> return HttpResponseRedirect()
>>>
>>> but know I want to change all my Views with CBVs but I really don't 
>>> understand how I could change the default query on DeleteView. Is there 
>>> somebody who could help me with it?
>>>
>>> I mean it is way easier than to Delete items, since I have one 
>>> DeleteView where I could use to Delete all items.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 CBV - DeleteView - CustomQuery

[Tom Christie]

Actually you'll probably want the `delete` method to be a `post` instead,
but either way hopefully it'll give you the right idea.

On Thursday, 21 March 2013 13:11:44 UTC, Tom Christie wrote:
>
> In cases like this, rather than rely on overriding the default behavior of 
> the DeleteView,
> I'd recommend writing your own base class.
>
> It'll be more explicit and more obvious exactly what is going on...
>
> from django.views.generic import View
>
> class MarkDeletedView(View):
> """
> Base class for marking a model instance as deleted.
> """
> model = None
> redirect_url = None
>
> def delete(self, request, *args, **kwargs):
> assert self.model, "model attribute must be set"
> assert self. redirect_url, "redirect_url attribute must be set"
>
> object = get_object_or_404(self.model, pk=kwargs['pk'])
> if object.date_deleted is not None:
> raise Http404
> now = datetime.datetime.utcnow().replace(tzinfo=utc)
> object.date_deleted = now.strftime("%Y-%m-%d %H:%M:%S")
> object.save()
> return HttpResponseRedirect(self.redirect_url)
>
> Then you can create a different view for each model you need this behavior 
> on, like so...
>
> class CustomerDeleteView(MarkDeletedView):
> model = Customer
> redirect_view = reverse('customer-list')
>
> Hope that helps.
>
>   Tom
>
> On Thursday, 21 March 2013 12:39:34 UTC, Christian Schmitt wrote:
>
>> Hello guys,
>> I have a question about the django CBV DeleteView, I want to use it but 
>> not delete the element, i just want to set a delete_date so that it isn't 
>> visible anymore.
>>
>> With FBV my view looked like this:
>>
>> def delete(request, customer_id):
>> customer = get_object_or_404(Customer, pk=customer_id)
>> if customer.date_deleted is not None:
>> raise Http404
>> now = datetime.datetime.utcnow().replace(tzinfo=utc)
>> customer.date_deleted = now.strftime("%Y-%m-%d %H:%M:%S")
>> customer.save()
>> return HttpResponseRedirect()
>>
>> but know I want to change all my Views with CBVs but I really don't 
>> understand how I could change the default query on DeleteView. Is there 
>> somebody who could help me with it?
>>
>> I mean it is way easier than to Delete items, since I have one DeleteView 
>> where I could use to Delete all items.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 CBV - DeleteView - CustomQuery

[Tom Christie]

In cases like this, rather than rely on overriding the default behavior of 
the DeleteView,
I'd recommend writing your own base class.

It'll be more explicit and more obvious exactly what is going on...

from django.views.generic import View

class MarkDeletedView(View):
"""
Base class for marking a model instance as deleted.
"""
model = None
redirect_url = None

def delete(self, request, *args, **kwargs):
assert self.model, "model attribute must be set"
assert self. redirect_url, "redirect_url attribute must be set"

object = get_object_or_404(self.model, pk=kwargs['pk'])
if object.date_deleted is not None:
raise Http404
now = datetime.datetime.utcnow().replace(tzinfo=utc)
object.date_deleted = now.strftime("%Y-%m-%d %H:%M:%S")
object.save()
return HttpResponseRedirect(self.redirect_url)

Then you can create a different view for each model you need this behavior 
on, like so...

class CustomerDeleteView(MarkDeletedView):
model = Customer
redirect_view = reverse('customer-list')

Hope that helps.

  Tom

On Thursday, 21 March 2013 12:39:34 UTC, Christian Schmitt wrote:

> Hello guys,
> I have a question about the django CBV DeleteView, I want to use it but 
> not delete the element, i just want to set a delete_date so that it isn't 
> visible anymore.
>
> With FBV my view looked like this:
>
> def delete(request, customer_id):
> customer = get_object_or_404(Customer, pk=customer_id)
> if customer.date_deleted is not None:
> raise Http404
> now = datetime.datetime.utcnow().replace(tzinfo=utc)
> customer.date_deleted = now.strftime("%Y-%m-%d %H:%M:%S")
> customer.save()
> return HttpResponseRedirect()
>
> but know I want to change all my Views with CBVs but I really don't 
> understand how I could change the default query on DeleteView. Is there 
> somebody who could help me with it?
>
> I mean it is way easier than to Delete items, since I have one DeleteView 
> where I could use to Delete all items.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 & Python 3 - porting packages to Python3

[Tom Christie]

Hi Thomas,

There's movement on getting Py3k compatibility into pillow.
See this, 
and associated tickets: https://github.com/python-imaging/Pillow/issues/61

> Are there any focus in the community on getting packages ready for 
python3?

Sure, I'm seeing several projects recently updated or actively working on 
it now.

I'm sure there'll be a lot of acceleration on Py3k compatible Django 
packages now that 1.5 has been released. :)

Cheers,

  Tom


On Friday, 15 February 2013 08:35:36 UTC, Thomas Weholt wrote:
>
> Hi, 
>
> As a Norwegian user of Django and python user I've spent countless 
> hours dealing with unicode-problems. As I ported DSE to Python 3 a 
> while ago I also discovered that all my unicode problems were solved 
> if I started using Python 3. Probably old news to most of you, or 
> maybe not even relevant, but it's a make-or-break-situation for me and 
> my potential users and customers. So all my latest django-based 
> projects have been developed using Python 3.3 with great success. 
>
> But the only problem now is the lack of python-packages supporting 
> Python 3, mainly PIL ( or the pil-fork pillow ), django-debug-toolbar, 
> django-celery etc. 
>
> Are there any focus in the community on getting packages ready for 
> python3? 
>
> -- 
> Mvh/Best regards, 
> Thomas Weholt 
> http://www.weholt.org 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: define form in yaml file

[Tom Christie]

Also, you might want to take a look at the Django Forms in an API 
world
 talk.
A large portion of that is about serializing form definitions into JSON, 
for use by both HTML and non-HTML clients. (eg mobile)
The project it talks about is 
here: https://github.com/WiserTogether/django-remote-forms
I don't think it does anything wrt. to the direction you need, of taking a 
serialized description and restoring a Form class from it, but it might 
give you some useful pointers all the same.

Cheers,

  Tom

On Thursday, 24 January 2013 20:02:53 UTC, Adrian Andreias wrote:
>
> Hello,
>
> I need a way to define a django form through a yaml file (or another text 
> format).
> Is there some code that already does this?
> I'm trying to not reinvent the wheel.
>
> I can't use simple python classes, since this would user input and would 
> be a security risk and I need a simpler and limited format.
>
> Thanks
>
>

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

Re: Generic views and url issues

[Tom Christie]

Hi Amy,

I'd suggest you check the following...

* Your 
ROOT_URLCONFsetting
 is correct.
* If the `urls.py` module you're referring to here is a project URL conf 
and not the root URL conf, make sure that it is being included by the root 
URL conf.  (This seems like the most likely cause)
* If it is being included by the root URL conf, check if it's being 
included with a `namespace` argument, and if so make sure to prefix the 
reverse with the appropiate namespace, eg if it's namespaced as 'myapp', 
then use 'myapp:addcalls'.

You've already made things really simple, the URL conf as you've declared 
it looks correct, so this...

   Reverse for 'adcalls' with arguments '()' and keyword arguments '{}' not 
found.

Suggests that 'adcalls' simply isn't included part of the URL conf of the 
application.

Cheers,

  Tom

On Thursday, 24 January 2013 14:01:30 UTC, Amy Cerrito wrote:
>
> Thanks for your response!
>
> Unfortunately, your suggestion did not eliminate the NoReverseMatch error.
>
> NoReverseMatch at /testadcall/
>
> Reverse for 'detail' with arguments '()' and keyword arguments '{'object_id': 
> 1}' not found.
>
>
> I have another example where I request the list view, which does not 
> expect arguments, to keep it even simpler.
>
> urls.py
>
> queryset = {'queryset': Adcall.objects.order_by('name')}
>
> urlpatterns = patterns('django.views.generic.list_detail',
> url(r'^$','object_list', queryset, name="adcalls"),
> url(r'^(?P\d+)/detail/$', 'object_detail', queryset, 
> name="detail"),
> )
>
>
> template:
>
> EDIT TEMPLATE
> {% load url from future %}
> {% csrf_token %}
> {{ form.as_p }}
> 
> 
>
> Back to adcall list
>
>
> Error:
> NoReverseMatch at /testadcall/1/detail/
>
> Reverse for 'adcalls' with arguments '()' and keyword arguments '{}' not 
> found.
>
>
>
>
>
> On Thu, Jan 24, 2013 at 2:53 AM, 
> > wrote:
>
>> On 24/01/2013 10:39 AM, amy.c...@cbsinteractive.com  wrote:
>>
>>> I've been trying to understand how to use generic views.  I've followed 
>>> some tutorials, and read through Django docs, but I can't get the url 
>>> function to work in my templates.
>>>
>>> I get the error
>>> NoReverseMatch at /testadcall/
>>> Reverse for 'detail' with arguments '(1,)' and keyword arguments '{}' 
>>> not found.
>>>
>>> in my urls.py
>>>
>>> queryset = {'queryset': Adcall.objects.order_by('name'**)}
>>>
>>> urlpatterns = patterns('django.views.**generic.list_detail',
>>> url(r'^$','object_list', queryset, name="adcalls"),
>>> url(r'(?P\d+)/**detail/$', 'object_detail', queryset, 
>>> name="detail"),
>>> )
>>>
>>> in my template for the list view:
>>>
>>> {% load url from future %}
>>> {% if object_list %}
>>> 
>>> {% for adcall in object_list %}
>>> {{ 
>>> adcall.name}}
>>> {% endfor %}
>>> 
>>> {% endif %}
>>>
>>> I've tried no quotes, single quotes, and double quotes around the url 
>>> name "detail", with no apparent effect.
>>>
>>> Am I wrong in thinking that this should work?
>>>
>>>  
>> The problem is a mismatch between your urls.py pattern and the parameters 
>> you give to the url templatetag - note in the error message that it 
>> mentions both arguments and keyword arguments (with your example having a 
>> single non-keyword argument). However, in your url pattern for the "detail" 
>> url, you use a named capture (object_id). In this case, you must use a 
>> keyword argument to match:
>>
>> {% url 'detail' object_id=adcall.id %}
>>
>> Regards,
>> Michael.
>>
>
>
>
> -- 
> Amy Cerrito
> Engineering Manager, AdOps Technology
> T 617.284.8697 
> 55 Davis Sq, Somerville, MA 02143
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/1sLMU3EDLH0J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django/Python vs Grails/Groovy

[Tom Christie]

I'm not in a position to draw a comparison between the Grails and Django, 
but I would say that Django's package ecosystem, and in particular for your 
use case it's API frameworks, are really rather great.

Again, I've no idea how Grails compares, but Django 
TastyPie and 
Django REST framework  are both 
excellent and could save you stacks of time.

Regards,

   Tom

On Sunday, 13 January 2013 19:37:20 UTC, tapan pandita wrote:
>
> Hey Guys,
>
> We have an initial version of our product ready on Grails. However, before 
> we move forward, we want to make a call between using Django or Grails. The 
> product is basically an API and some templating. The team comprises of 
> people who are comfortable with both frameworks and can easily make the 
> switch from one to the other. Based on the research I've done online, I 
> feel both frameworks are essentially the same. Groovy is just about as easy 
> to develop in as python and ecosystem-wise Java doesn't have any advantage 
> over Python (at least as far as the web is concerned). Also, Grails can do 
> pretty much everything that Django can do (including schema migrations now 
> which people seem to complain about earlier). Personally, I am a django guy 
> and haven't developed a lot in Grails (just basic stuff). What would be 
> some compelling arguments to switch to Django over grails or should we 
> stick with grails?

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

Re: Django community, is it active?

[Tom Christie]

> Is this worth going? --- http://2013.djangocon.eu

Yes, yes, yes, yes, and yes.  I've been to two DjangoCons, both have been 
incredible, and have reaffirmed how proud I am to work in this industry, 
and to be a part of this community.

> Who are the top blogs people within the Django community who should I be 
following, blogs feed etc.

http://www.planetdjango.org/ is an aggregated news feed for Django posts.

Some folks who write regularly...

Daniel Greenfeld (aka pydanny) - http://pydanny.com/
Reinout van Rees - http://reinout.vanrees.org/weblog/
Nick Coghlan - http://www.boredomandlaziness.org/

If you haven't already I'd recommend getting yourself tapped into twitter 
and follow some of the core devs and other python/django folks.

Also, a tip - I'd stay well away from the free bear.
Might look cute at first, but man, those things can get vicious.
The free beer however, does come recommended.

Cheers,

  Tom

On Wednesday, 19 December 2012 13:02:12 UTC, Cal Leeming [Simplicity Media 
Ltd] wrote:
>
> Sorry, slightly misworded!
>
> Don't /just/ drink the free bear, help out as well.
>
> Cal
>
> On Wed, Dec 19, 2012 at 3:02 AM, Chris Cogdon 
> > wrote:
>
>> But I _want_ to drink the free bear.
>>
>> On Tuesday, December 18, 2012 3:19:59 PM UTC-8, Cal Leeming [Simplicity 
>> Media Ltd] wrote:
>>>
>>>  Don't drink the free bear though, ...
>>>
>>
>>
>>>   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-users/-/Je-VbEdMmoQJ.
>>
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-users...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>

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

Re: Authenticate User with Django 1.5

[Tom Christie]

> A custom authentication backend isn't required; the ModelBackend should 
adapt to any well-defined User model.

Thanks Russ, I hadn't realized the ModelBackend tied in nicely with those 
changes.

> Have you tried changing USERNAME_FIELD to 'email'? 

+1, looks like that's the OP's issue.

On Sunday, 16 December 2012 01:12:14 UTC, Quartic wrote:
>
> On 15/12/12 11:18, sebastie...@gmail.com  wrote: 
> > Hi, i've an authenticate problem with Django 1.5 
> > All informations are 
> > herehttp://
> stackoverflow.com/questions/13883539/authenticate-with-django-1-5 
> > but i'll resume the situation : 
> > 
> > I've a custum user model which looks like : 
> > 
> > class User(AbstractBaseUser): 
> >  email = models.EmailField(unique=True) 
> >  activation_key = models.CharField(max_length=255) 
> >  is_active = models.BooleanField(default=False) 
> >  is_admin = models.BooleanField(default=False) 
> > 
> >  objects = UserManager() 
> > 
> >  USERNAME_FIELD = 'username' 
> > 
>  
> > 
> > 
> > The probleme is that user = authenticate(username=email, 
> > password=password) gives me None as return. 
> > According to the doc, authenticate takes an usersname, not an email as 
> > arg. But how can i use authenticate because my User model desn't support 
> > Username. 
> > Is there a solution with Django 1.5 ? 
> > 
>
> Have you tried changing USERNAME_FIELD to 'email'? 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/kz4lo-mJWMUJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Authenticate User with Django 1.5

[Tom Christie]

I believe you'll need a custom authentication backend to tie in with your user 
model.

Take a look at the docs here:

https://docs.djangoproject.com/en/dev/ref/authbackends/

Here's an example of an auth backend that takes email/password instead of 
username/password:

https://github.com/dabapps/django-email-as-username/blob/master/emailusernames/backends.py

Hope that helps.

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

Re: Forbidden (403)

[Tom Christie]

You don't need the `c.update` etc... lines, since it's not actually being 
used anywhere by your view.
Also you should probably just use `render` instead of `render_to_response`, 
since `render` will always use a RequestContext.

https://docs.djangoproject.com/en/dev/topics/http/shortcuts/

On Tuesday, 13 November 2012 14:08:51 UTC, Nebros wrote:
>
> Edit: first error was TypeError at /portal/... i realyzed now, the error 
> is for the next page...
>  
>
>> TypeError at /kundendaten/
>>
>> pop expected at least 1 arguments, got 0
>>
>>  
>>
>> i tryed the post from this page:
>> http://stackoverflow.com/questions/7678231/problems-with-csrf-token
>>
>>  
>>
>> now i have the error, when i press my send button, why is that?
>> here the error...--
>>
>> TypeError at /kundendaten/
>>
>> pop expected at least 1 arguments, got 0
>>
>> Request Method:POSTRequest URL:http://127.0.0.1:8000/kundendaten/Django 
>> Version:1.4.1Exception Type:TypeErrorException Value:
>>
>> pop expected at least 1 arguments, got 0
>>
>> Exception Location:C:\Python27\lib\site-packages\django\template\loader.py 
>> in render_to_string, line 178Python Executable:C:\Python27\python.exePython 
>> Version:2.7.3
>>
>>
>> -
>>
>

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

Re: Forbidden (403)

[Tom Christie]

Could you include your 'kundendaten' view too, please.
Any error text on the 403 page would also be useful.

On Monday, 12 November 2012 15:54:50 UTC, Nebros wrote:
>
> When i put in a variable in my type="text" and push type="submit" (by the 
> step to next page)...
>  
>
> Am Montag, 12. November 2012 16:52:20 UTC+1 schrieb Vibhu Rishi:
>
>> When is it that you are getting the 403 ? 
>>
>>
>> On Mon, Nov 12, 2012 at 7:30 PM, Nebros  wrote:
>>
>>> I know this is an old problem with many answers... but no one helps me. 
>>> ^^
>>> what i have:
>>>  
>>> Settings
>>> MIDDLEWARE_CLASSES = (
>>> 'django.middleware.csrf.CsrfViewMiddleware',
>>> 'django.middleware.common.CommonMiddleware',
>>> 'django.contrib.sessions.middleware.SessionMiddleware',
>>> 'django.contrib.auth.middleware.AuthenticationMiddleware',
>>> 'django.contrib.messages.middleware.MessageMiddleware',
>>> # Uncomment the next line for simple clickjacking protection:
>>> # 'django.middleware.clickjacking.XFrameOptionsMiddleware',
>>> )
>>> ---
>>>  
>>> urls--
>>> from django.conf.urls import patterns
>>> from klasse.views import portal, kundendaten
>>> urlpatterns = patterns('',
>>> (r'^portal/$', portal),
>>> (r'^kundendaten/$', kundendaten),
>>> )
>>> ---
>>>  
>>> views---
>>> from django.shortcuts import render_to_response
>>> from django.core.context_processors import csrf
>>> from django.views.decorators.csrf import csrf_protect
>>> import datetime
>>> import pyodbc
>>> @csrf_protect
>>> def portal(request):
>>> now = datetime.datetime.now()
>>> return render_to_response('portal.html', {'current_date': now})
>>> 
>>>  
>>> portal.html--
>>> 
>>> {% csrf_token %}
>>> 
>>> Anfrage
>>> Bitte Kundennamen eingeben
>>> 
>>> >> required="required">
>>> 
>>> 
>>> 
>>> >> href="kundendaten">
>>> 
>>> 
>>> 
>>>  
>>> I tryed a lot of variants to fix my "post" problem, but without success. 
>>> can anybody help me? ^^
>>> thx
>>> *pls ignore my englisch fails
>>>  
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django users" group.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msg/django-users/-/iMXtpFVaRp8J.
>>> To post to this group, send email to django...@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> django-users...@googlegroups.com.
>>> For more options, visit this group at 
>>> http://groups.google.com/group/django-users?hl=en.
>>>
>>
>>
>>
>> -- 
>> Simplicity is the ultimate sophistication. - Leonardo da Vinci
>> Life is really simple, but we insist on making it complicated. - Confucius
>>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/GTvp3a-tJ58J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How many developers have moved to class-based views?

[Tom Christie]

If you're working with the generic CBVs, I would strongly recommend taking 
a look at the documentation provided by the Classy CBV project - 
http://ccbv.co.uk/.  Because of the way it's auto-generated it allows you 
to see at a glance exactly what set of methods and attributes are 
implemented by an given class or mixin, and makes it frictionless to skip 
between the documentation and the source implementation.  It makes it much 
easier to get an idea of how everything fits together.

  - Tom

On Monday, 12 November 2012 04:16:51 UTC, Kurtis wrote:
>
> I use them!
>
>
> On Sun, Nov 11, 2012 at 2:05 PM, Kevin >wrote:
>
>> Wow, the dev docs are much more informative and actually explains the 
>> best way to alter a form before saving it.  I was using a different method, 
>> but the method mentioned in the dev docs are much more cleaner than what I 
>> was doing.  Many thanks for this.
>>
>>
>> On Sunday, 11 November 2012 12:54:45 UTC-6, Lee Hinde wrote:
>>
>>> The dev docs are much more informative.
>>>
>>>
>>> On Sun, Nov 11, 2012 at 10:45 AM, Arnold Krille wrote:
>>>

 Docs on CBV in django1.4 are a bit sparse to say the least.

>>>  
>>>

 Have fun,

 Arnold

>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-users/-/jZ8_sGjQpkoJ.
>>
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-users...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/AEQsS3r-ZuoJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

ANN: Django REST framework 2 released.

[Tom Christie]

Hi all,

I'm incredibly pleased to announce the release of Django REST framework 2.

REST framework 2 is a comprehensive reworking of the original project.
Because this is a major re-design, rather than an incremental release, 
we've skipped 1.x entirely, and called this version 2.

Some of the things it includes:

* A completely redesigned, and really-rather-nice serialization API that 
mirrors Django's Forms/ModelForms 
* Ties in cleanly and simply with Django's class-based-views.
* Virtually every aspect of the design has been worked on - the end result 
is beautifully decoupled and simple. 
* The (seriously awesome) browsable API gets a snazzy, fresh, new theme. 
* The documentation has had a ton of love, is now built from markdown 
source and gets a custom bootstrap style.

It has been an absolutely *huge* amount of work to get this over the line.
I'm very proud indeed of the result, and I'd love it if you'd take a look.

The full announcement & documentation is available here: 
http://django-rest-framework.org/topics/rest-framework-2-announcement.html

Thank you to everyone who's contributed to the project and helped make this 
happen,

  Tom

NB. There's also a post on http://hackerne.ws/ if anyone fancies up-voting!


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/6Sm-297NsbgJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 1.5: syntax of AUTH_USER_MODEL

[Tom Christie]

You don't mention 'app1.MyUser', which is what I think it should be.

On Monday, 29 October 2012 14:50:15 UTC, Anil wrote:
>
> I have the following filesystem structure:
>
> project
> project/app1
> project/app1/models.py <--- class MyUser(AbstractBaseUser)
> project/project
> project/project/settings.py
> project/project/urls.py
> ...
>
> I set my AUTH_USER_MODEL to 'project.app1.models.MyUser', I get error:
>
> auth.user: AUTH_USER_MODEL is not of the form 'app_label.app_name'.
>
> I tried also doing something like '..app1.models.MyUser', but that didn't 
> work either or simply 'project.MyUser'. None of these are working.
> In the settings.py file, is my model in the path? How do I reference it?
>
> Thanks
>
>
>
>

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

Re: Using email instead of username for registration and login

[Tom Christie]

This should cover it:

  https://github.com/dabapps/django-email-as-username

For compatibility with django-registration you'll also want to take a look 
at the thread on this ticket:

  https://github.com/dabapps/django-email-as-username/issues/17

Cheers,

  Tom

On Tuesday, 25 September 2012 02:57:20 UTC+1, Bill Beal wrote:
>
> Hi all,
>
> I want to use the email address as the username for registration and 
> login.  I'm using django-registration for 2-stage registration.  I'm 
> looking for an easier way than what I've come up with so far.  I can modify 
> registration and activation, but then django.contrib.auth.views.login has a 
> 30-character limit on the username.  I'm not looking forward to making 
> username act like an email address.  Any quick fixes?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/pm-WyxpvirMJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Release: django-email-as-username

[Tom Christie]

Okay, I know there are a handful of other apps that already do this, but I 
wasn't quite happy with anything that was out there.

I've pushed the django-email-as-username package to PyPI.

Source and docs available 
here: https://github.com/dabapps/django-email-as-username

I think it's pretty comprehensive...

1. Provides an email auth backend and helper functions for creating users.
2. Patches the Django admin to handle email based user authentication.
3. Overides the `createsuperuser` command to create users with email only. 
 (Eg during initial `syncdb`)
4. Treats email authentication as case-insensitive.

There's a few outstanding tickets for extra little tweaks to improve things 
even more, such as providing a migration for adding it to existing projects 
and so on.
Would appreciate any forks/ideas for improvements etc.etc.

Cheers,

  Tom

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

django-private-views

[Tom Christie]

Useful little package for y'all, written by Julien Phalip, which I've 
packaged and pushed to PyPI.

django-private-views - https://github.com/dabapps/django-private-views

Inverts the usual @login_required logic, and instead makes all your views 
private by default, and gives you a @login_not_required.
(And a few other useful bits and pieces.)

Hope it's useful.  Let me know if there's any problems.

Cheers,

  Tom

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

Re: django tests. where to create users

[Tom Christie]

What's wrong with just creating them in the .setUp()?

Don't sweat the small amount of time it'll take to re-create the users on 
each test run, it's almost certainly not worth worrying about.

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

Re: Integrating Selenium tests into Django unit tests.

[Tom Christie]

This...

https://code.djangoproject.com/attachment/ticket/2879/django_live_server_1.0.2.diff

With changes to reflect the fact that the database settings layout has 
changed since 1.0, like so...

=
 # Must do database stuff in this new thread if database in memory.
 from django.conf import settings

-if ( settings.DATABASE_ENGINE == 'sqlite3' and 
-(not settings.TEST_DATABASE_NAME 
- or settings.TEST_DATABASE_NAME == ':memory:') ):
+database = settings.DATABASES['default']
+
+if ( database.get('ENGINE', None).split('.')[-1] == 'sqlite3' and
+(not database.get('TEST_NAME', None)
+ or database.get('TEST_NAME') == ':memory:') ):
 from django.db import connection
 db_name = connection.creation.create_test_db(0)
 # Import the fixture data into the test database.
===

If possible I'll try to find some time to:

1. Package this up into a usable form on PyPI
2. Update the ticket with a working patch, and perhaps try to push it along 
some.
(If you wanted to help make sure that it makes it into trunk that'd be 
great!)

  Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/5-5AtUJiq2kJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Integrating Selenium tests into Django unit tests.

[Tom Christie]

I just had to do the same thing. Tried to use the django-sane-testing package, 
but didn't have much success there. In the end this ticket here: 
https://code.djangoproject.com/ticket/2879 pretty much did the trick, with a 
bit of updating as it didn't quite work with >= 1.2. I'll see if I can get a 
snippet to ya some time shortly (or drop me a mail off-list: 
t...@tomchristie.com)
Cheers,
  T.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/6A-k53jGSd8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: django-pdb on PyPI

[Tom Christie]

Thanks for that! Yeah there's nothing very complicated about it, but makes for 
a useful little package.
  T.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/2YRroHhYj1EJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

django-pdb on PyPI

[Tom Christie]

I've thrown up the django-pdb package on PyPI - hopefully some of y'all will 
find it a useful little tool.

PyPI: http://pypi.python.org/pypi/django-pdb/0.1.1
GitHub: https://github.com/tomchristie/django-pdb

Suggestions and contributions are of course very welcome.


Here's the basic README...

Make debugging Django easier
==

Adding pdb.set_trace() to your source files every time you want to break 
into pdb sucks.

Don't do that.

Do this.

Installation


Install using `pip`, add to your INSTALLED_APPS:
pip install django-pdb

INSTALLED_APPS = (
...
'django_pdb',
)

Usage
=

manage.py runserver
Drops into pdb at the start of a view if the URL includes a 'pdb' GET 
parameter

manage.py runserver --pdb
Drops into pdb at the start of every view

manage.py test --pdb
Drops into pdb on test errors/failures

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/5gg7RyxmnIAJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Creating REST APIs in Django...advice

[Tom Christie]

  The obvious big difference with REST framework is that the API is entirely 
web browse-able. To me that's quite a big deal - your API can be genuinely self 
documenting, and it's massively easier to browse, work with, and debug, than it 
would be if your working from the command line all the time.

  There's a bunch of other things I think it does well, from really nice error 
handling, using Django's class based views with mixin classes, and treating 
form and json etc input equally as regards validation, but I really need to sit 
down and write that stuff up properly sometime. (not got the time to go into it 
right now)

  And, yeah I would def use hidden form fields to set the method if you need 
web browser support for DELETE/PUT etc. It's a pretty common pattern, and it's 
much better than polluting your URL space specifically to cope with browser 
limitations.

  Cheers,
  Tom

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

Creating REST APIs in Django...advice

[Tom Christie]

I've been working on this with some folks:

http://django-rest-framework.org

Released 0.1 a few weeks ago, and it's coming along *really* nicely. It's under 
v active development ATM. The auto-generated API browser is particularly cool. 
Really would advise anyone taking a look at building web APIs in python to take 
a look at it.

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

Re: What is the best server for Django

[Tom Christie]

And again, +1 webfaction, they really do rock.

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

Announce: Django REST framework

[tom christie]

Hey all,

  I'm superpleased to announce the release of Django REST framework 0.1.
http://django-rest-framework.org/

  The project is another mini-framework aimed at making it easy to
build well-connected, self-describing RESTful web APIs,
in the same vein as django-piston and django-tastypie.  (There's even a bit
of piston code in there too)

Some of the stand out features:

   - The APIs that it creates are automatically browseable via the awesome
   admin-styled interface, allowing them to be self documenting, and allowing
   you to read, create, update and delete resources via the browser. Eg:
   http://api.djangorestframework.org/
   -  The framework uses Django's new class based views, with the various
   functionality separated into MixIn classes, making it really flexible - you
   can use parts of the framework in your own View classes, even if you don't
   use the core Resource and ModelResource classes it provides.
   - Nice simple Resource and ModelResource classes, with default handler
   methods on the ModelResource class and automatic input validation using
   ModelForms.
   - And a whole bunch of stuff really...

Creating new resources can be as simple as adding a couple of lines to your
URLconf...

from django.conf.urls.defaults import patterns, url
from djangorestframework import ModelResource, RootModelResource
from models import MyModel

urlpatterns = patterns('',
url(r'^$', RootModelResource.as_view(model=MyModel)),
url(r'^(?P[^/]+)/$', ModelResource.as_view(model=MyModel),
name='my-model'),
)

(For anything beyond that head on over to the docs...)

Thoughts or feedback always appreciated.

Cheers,

  Tom

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