Re: Django bugfix release: 3.2.6

[Sean Carlo Bermejo]

Hi Carlton,

Seems the link refers to a different url.
https://www.djangoproject.com/weblog/2020/oct/01/django-bugfix-release-312/

On Mon, Aug 2, 2021 at 2:37 PM Carlton Gibson 
wrote:

> Details are available on the Django project weblog:
>
> https://www.djangoproject.com/weblog/2021/aug/01/bugfix-release/
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/04867089-61B2-4963-AD4B-4D0E30207413%40gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAADxw%3DPeGJjB7b4wd_XMHqe2_%3DTENbn%3DFqchnBDG1qraYiWNaA%40mail.gmail.com.

Re: Improving MSSQL and Azure SQL support on Django

[Sean Martz]

Hello,

It seems like this issue has lost momentum. Is this still something that's 
on anyones radar? It looks like django-pyodbc-azure is not actively 
maintained anymore (it looks like Michaya has taken a hiatus from GitHub). 
It also looks like there's a small community potentially popping up that's 
interested in first class MSSQL Server support for Django. 
(https://github.com/FlipperPA/django-mssql-backend). Is Microsoft still 
interested in committing resources to this goal? In my situation, it would 
be a lot easier to sell stakeholders and decision makers on Django if it 
had first class support for MSSQL Server.

For what it's worth, Django-pyodbc-azure is still working well.

Cheers,
Sean

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/873b16af-8953-4caf-a4f2-7a3a8309378c%40googlegroups.com.

Re: Automatic prefetching in querysets

[Sean Brant]

I wonder if a solution similar to [1] from the rails world would satisfy
this request. Rather then doing anything 'magical' we instead log when we
detect things like accessing a related model that has not been pre-fetched.

[1] https://github.com/flyerhzm/bullet

On Tue, Aug 15, 2017 at 5:14 PM, Luke Plant  wrote:

> I agree with Marc here that the proposed optimizations are 'magical'. I
> think when it comes to optimizations like these you simply cannot know in
> advance whether doing extra queries is going to a be an optimization or a
> pessimization. If I can come up with a single example where it would
> significantly decrease performance (either memory usage or speed) compared
> to the default (and I'm sure I can), then I would be strongly opposed to it
> ever being default behaviour.
>
> Concerning implementing it as an additional  QuerySet method like
> `auto_prefetch()` - I'm not sure what I think, I feel like it could get
> icky (i.e. increase our technical debt), due to the way it couples things
> together. I can't imagine ever wanting to use it, though, I would always
> prefer the manual option.
>
> Luke
>
>
>
> On 15/08/17 21:02, Marc Tamlyn wrote:
>
> Hi Gordon,
>
> Thanks for the suggestion.
>
> I'm not a fan of adding a layer that tries to be this clever. How would
> possible prefetches be identified? What happens when an initial loop in a
> view requires one prefetch, but a subsequent loop in a template requires
> some other prefetch? What about nested loops resulting in nested
> prefetches? Code like this is almost guaranteed to break unexpectedly in
> multiple ways. Personally, I would argue that correctly setting up and
> maintaining appropriate prefetches and selects is a necessary part of
> working with an ORM.
>
> Do you know of any other ORMs which attempt similar magical optimisations?
> How do they go about identifying the cases where it is necessary?
>
> On 15 August 2017 at 10:44, Gordon Wrigley 
> wrote:
>
>> I'd like to discuss automatic prefetching in querysets. Specifically
>> automatically doing prefetch_related where needed without the user having
>> to request it.
>>
>> For context consider these three snippets using the Question & Choice
>> models from the tutorial
>>  
>> when
>> there are 100 questions each with 5 choices for a total of 500 choices.
>>
>> Default
>> for choice in Choice.objects.all():
>> print(choice.question.question_text, ':', choice.choice_text)
>> 501 db queries, fetches 500 choice rows and 500 question rows from the DB
>>
>> Prefetch_related
>> for choice in Choice.objects.prefetch_related('question'):
>> print(choice.question.question_text, ':', choice.choice_text)
>> 2 db queries, fetches 500 choice rows and 100 question rows from the DB
>>
>> Select_related
>> for choice in Choice.objects.select_related('question'):
>> print(choice.question.question_text, ':', choice.choice_text)
>> 1 db query, fetches 500 choice rows and 500 question rows from the DB
>>
>> I've included select_related for completeness, I'm not going to propose
>> changing anything about it's use. There are places where it is the best
>> choice and in those places it will still be up to the user to request it. I
>> will note that anywhere select_related is optimal prefetch_related is still
>> better than the default and leave it at that.
>>
>> The 'Default' example above is a classic example of the N+1 query
>> problem, a problem that is widespread in Django apps.
>> This pattern of queries is what new users produce because they don't know
>> enough about the database and / or ORM to do otherwise.
>> Experieced users will also often produce this because it's not always
>> obvious what fields will and won't be used and subsequently what should be
>> prefetched.
>> Additionally that list will change over time. A small change to a
>> template to display an extra field can result in a denial of service on
>> your DB due to a missing prefetch.
>> Identifying missing prefetches is fiddly, time consuming and error prone.
>> Tools like django-perf-rec 
>> (which I was involved in creating) and nplusone
>>  exist in part to flag missing
>> prefetches introduced by changed code.
>> Finally libraries like Django Rest Framework and the Admin will also
>> produce queries like this because it's very difficult for them to know what
>> needs prefetching without being explicitly told by an experienced user.
>>
>> As hinted at the top I'd like to propose changing Django so the default
>> code behaves like the prefetch_related code.
>> Longer term I think this should be the default behaviour but obviously it
>> needs to be proved first so for now I'd suggest a new queryset function
>> that enables this behaviour.
>>
>> I have a proof of concept of this mechanism that I've used 

Re: CITextField base class

[Sean Brant]

Does it make sense to add a CICharField for these cases or you can just
override the form/admin.

On Wed, Feb 8, 2017 at 10:29 AM, Jon Dufresne <jon.dufre...@gmail.com>
wrote:

> I believe this will also change the default form widget from  type="text"> to . Is that also desired? IME, I most often use
> citext with short text inputs, such as email.
>
> On Wed, Feb 8, 2017 at 7:11 AM, Tim Graham <timogra...@gmail.com> wrote:
>
>> Since that's a release blocker for a feature that hasn't been released
>> yet, it's fine to reference/reopen the original ticket rather than create a
>> new one. I've created a PR, https://github.com/django/django/pull/8034.
>>
>> On Wednesday, February 8, 2017 at 7:40:02 AM UTC-5, Adam Johnson wrote:
>>>
>>> Pretty sure this is a new ticket since it's effectively a bug report
>>>
>>> On 8 February 2017 at 11:00, Mads Jensen <m...@inducks.org> wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, February 8, 2017 at 11:32:22 AM UTC+1, Adam Johnson wrote:
>>>>>
>>>>> Sounds legit, make a ticket
>>>>>
>>>>
>>>> Shouldn't https://code.djangoproject.com/ticket/26610 just be reopened?
>>>>
>>>>
>>>>> On 8 February 2017 at 00:37, Sean Brant <brant...@gmail.com> wrote:
>>>>>
>>>>>> I noticed the new postgres citext[1] field is a subclass of
>>>>>> CharField. Wouldn't it be more correct to subclass TextField?
>>>>>> Subclassing CharField means we need to add a max_length which is ignored 
>>>>>> in
>>>>>> the db.
>>>>>>
>>>>>> [1] https://github.com/django/django/blob/master/django/cont
>>>>>> rib/postgres/fields/citext.py
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to django-develop...@googlegroups.com.
>>>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>>>> Visit this group at https://groups.google.com/group/django-developers
>>>>>> .
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/django-developers/0e50eae1
>>>>>> -8806-47fc-b223-9cac7152bf1e%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/django-developers/0e50eae1-8806-47fc-b223-9cac7152bf1e%40googlegroups.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Adam
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to django-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/django-developers/e2be5fd6-3fc0-44d5-8d07-da713eb58db4%4
>>>> 0googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/e2be5fd6-3fc0-44d5-8d07-da713eb58db4%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Adam
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/cac9ac5f-cdcd-

Re: CITextField base class

[Sean Brant]

Thanks Tim. I re-opened the ticket.

On Wed, Feb 8, 2017 at 9:11 AM, Tim Graham <timogra...@gmail.com> wrote:

> Since that's a release blocker for a feature that hasn't been released
> yet, it's fine to reference/reopen the original ticket rather than create a
> new one. I've created a PR, https://github.com/django/django/pull/8034.
>
> On Wednesday, February 8, 2017 at 7:40:02 AM UTC-5, Adam Johnson wrote:
>>
>> Pretty sure this is a new ticket since it's effectively a bug report
>>
>> On 8 February 2017 at 11:00, Mads Jensen <m...@inducks.org> wrote:
>>
>>>
>>>
>>> On Wednesday, February 8, 2017 at 11:32:22 AM UTC+1, Adam Johnson wrote:
>>>>
>>>> Sounds legit, make a ticket
>>>>
>>>
>>> Shouldn't https://code.djangoproject.com/ticket/26610 just be reopened?
>>>
>>>
>>>> On 8 February 2017 at 00:37, Sean Brant <brant...@gmail.com> wrote:
>>>>
>>>>> I noticed the new postgres citext[1] field is a subclass of CharField.
>>>>> Wouldn't it be more correct to subclass TextField? Subclassing CharField
>>>>> means we need to add a max_length which is ignored in the db.
>>>>>
>>>>> [1] https://github.com/django/django/blob/master/django/cont
>>>>> rib/postgres/fields/citext.py
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to django-develop...@googlegroups.com.
>>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/django-developers.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/django-developers/0e50eae1
>>>>> -8806-47fc-b223-9cac7152bf1e%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/django-developers/0e50eae1-8806-47fc-b223-9cac7152bf1e%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Adam
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/e2be5fd6-3fc0-44d5-8d07-da713eb58db4%
>>> 40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/e2be5fd6-3fc0-44d5-8d07-da713eb58db4%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/cac9ac5f-cdcd-4e33-bba3-
> b1a9de700365%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/cac9ac5f-cdcd-4e33-bba3-b1a9de700365%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPNuhQyW9MRynUkC6ZJGxUw5BGOXebdWZHjROcFaPQ%3DvFG4vug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

CITextField base class

[Sean Brant]

I noticed the new postgres citext[1] field is a subclass of CharField. 
Wouldn't it be more correct to subclass TextField? Subclassing CharField 
means we need to add a max_length which is ignored in the db.

[1] 
https://github.com/django/django/blob/master/django/contrib/postgres/fields/citext.py

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0e50eae1-8806-47fc-b223-9cac7152bf1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding UNION/INTERSECT/EXCEPT to the ORM

[Sean Bleier]

>
> We cannot use the name "QuerySet.except()" since except is a reserved word
> in Python. Do you prefer minus() (as suggested by Florian), except_() (as
> done by SQLAlchemy), or something else?
>
>
Can I suggest using "QuerySet.difference"?   It's what python's sets use
for achieving the same functionality.

On Monday, December 26, 2016 at 6:28:15 PM UTC-5, Adam Johnson wrote:
>>
>> Yes it's different, they cannot be changed due to backwards compatibility
>> issues. They don't result in UNION in SQL, they union the filters on two
>> querysets that are on the same exact model.
>>
>> On 26 December 2016 at 21:00, Cristiano Coelho 
>> wrote:
>>
>>> Is this going to be different from the pipe ( | ) and and ( & )
>>> operators on querysets? If I'm not wrong those can already result in a
>>> union query (but not necessary, sometimes it just returns a query with an
>>> or/and condition)
>>>
>>>
>>> El viernes, 23 de diciembre de 2016, 11:12:40 (UTC-3), Florian Apolloner
>>> escribió:

 Hi,

 I have a currently WIP PR at https://github.com/django/django/pull/7727

 The usage is currently something like this:

 qs1 = User.objects.all().values('username')
 qs2 = Group.objects.all().values('name')
 results = qs1.union(qs).distinct().order_by('name')[:10]

 (order_by does not work though yet)

 So far I have a few questions:

  * Should .union/.intersect etc return a new type of queryset or stay
 with the base QuerySet class (probably less code duplication)
  * We currently have a few methods which check can_filter and error out
 accordingly (ie you cannot filter after slicing), but as the error message
 in https://github.com/django/django/blob/master/django/db/model
 s/query.py#L579 shows, this strongly relies on knowledge of the
 implementation of the filter. For combined querysets I basically need to
 limit everything aside from order by and limit/offset. Would a method like
 this make some sense (on the Query class):

 def is_allowed(self, action):
   if self.combinatorial and action not in ('set_operation', 'order_by',
 'slicing'):
 raise SomeError('Cannot use this method on an combinatorial
 queryset')
   elif action == 'filter' and (self.low_mark or self.high_mark):
 raise SomeError('Cannot filter after slicing')

  * set_operator in base.py feels a bit weird (
 https://github.com/django/django/pull/7727/files#diff-53fcf
 3ac0535307033e0cfabb85c5301) -- any better options?
  * How can I change the generated order_by clause to reference the
 columns "unqualified" (ie without table name), can I somehow just realias
 every column?

 Cheers,
 Florian

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/d38358ca-c97f-4bb0-a390-e38f3b4b8f6c%
>>> 40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/3084faa0-e097-4227-9a34-
> f870c8be6809%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Re: Making Django more PaaS-friendly

[Sean Brant]

https://github.com/joke2k/django-environ has helpers for loading most of
the backends from urls. We use it with a docker based deployment at the
moment.

On Mon, Apr 11, 2016 at 8:46 AM, Ryan Hiebert  wrote:

> I'd love to see better support for PaaS configuration, especially
> 12-factor. We use Heroku, and I've been directly exposed to the challenges
> and had to come up with some of my own solutions. Here's some thoughts I
> have on the matter, in no particular order.
>
>
> The SECRET_KEY needs to _not_ be required for the `collectstatic` command.
> I haven't tracked down why it currently _is_ required, but it means that I
> have added this line to my project, solely so that my project can be built
> on Heroku.
>
> SECRET_KEY = os.environ.get('SECRET_KEY', 'not-so-secret')
>
> SECRET_KEY is effectively optional (though I'm careful to make sure it's
> set), and I don't see a good reason that should be. Note that environment
> variables aren't normally available during slug build, since changing
> environment variables doesn't re-build the project.
>
>
> I believe that the biggest current impediment to finding a great solution
> to loading Django settings is that the settings are based on a Module.
> Django-Configurations has done an excellent job of making that into a
> class-based API instead, which allows for mixins and inheritance. Having
> built-in support for this would be an excellent way to allow 3rd party
> solutions to build up settings programatically. In the case we are
> discussing, from the environment.
>
> I believe this would make it far easier for projects like Kristian's
> django-12factor and dj-email-url to work well. dj-email-url is a good idea
> (put all the settings in 1 variable, like dj-database-url), except that all
> the settings are split up at the top-level of the module, making what's
> conceptually one multi-facted setting a multi-line pain.
>
> One possibility would be extending `DJANGO_SETTINGS_MODULE` with an
> optional class, separated with a colon, so to get a django-configurations
> style class you'd use
> `DJANGO_SETTINGS_MODULE=myproject.settings:MySettings`. Or we could change
> the variable name `DJANGO_SETTINGS`, which would allow us to avoid the
> colon: `DJANGO_SETTINGS=myproject.settings.MySettings`. Or paint the
> bikeshed some other color.
>
>
> I'd love to see some of the support for environment configurations brought
> into Django, but IMO moving away from a module based settings API is a more
> pressing concern that would enable 3rd party libraries to come up with
> elegant solutions.
>
>
> On Apr 11, 2016, at 4:32 AM, Kristian Glass <
> googleto...@doismellburning.co.uk> wrote:
>
> I wrote django12factor to do something similar. One of the things I like
> least about it is the process of actually using it from your settings.py -
> there's things in there I'd love to see in the generated default.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2D66F14E-DD71-41B6-A84D-A0C679FD72F5%40ryanhiebert.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPNuhQxbRKX%3D2FrCd-jg6MJCnO%2BuBC6HbTOpPUdQJAjQjyMDSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

[Sean Brant]

How does the new channels model handle requests with sensitive information?
Say you have a login view and the user is submitting a username/password.
Does the password get serialized into the message queue as plain text? If
so is that a security concern users should be aware of?

Sean

On Mon, Mar 21, 2016 at 7:55 AM, David Evans <drh.ev...@gmail.com> wrote:

> On the static files question, I'm about to release v3 of WhiteNoise (
> http://whitenoise.evans.io/en/latest/changelog.html) which provides the
> option to integrate via Django middlware, rather than wsgi middleware. (It
> uses the FileResponse class, which didn't exist when I first wrote
> WhiteNoise.) I'm hoping (though I haven't tested it yet) that this will
> work out of the box with Channels, as it's only using standard Django APIs.
>
> Dave
>
>
> On Thursday, 17 March 2016 16:42:05 UTC, Jacob Kaplan-Moss wrote:
>>
>> Hi folks (and especially Andrew):
>>
>> I've just completed writing an example Channels app [1] for an article
>> about Channels [2]. Overall it was a super-pleasant experience: Channels
>> seems pretty solid, the APIs make sense to me, and I couldn't be more
>> excited about the new things this'll let me do!
>>
>> In the interests of making this thing as solid as possible before we
>> merge it into Django, I do have some feedback on some of the hiccups I
>> encountered. Roughly in order of severity (as I perceive it), they are:
>>
>> 1. Debugging errors:
>>
>> I found debugging errors that happen in a consumer to be *really*
>> difficult -- errors mostly presented as things just silently not working.
>> It took a ton of messing around with logging setups before I could get
>> anything of use dumped to the console. This isn't strictly a Channels issue
>> (I've noted similar problems with AJAX views and errors in Celery tasks),
>> but I think Channels sorta brings the issue to a head.
>>
>> I think we need some better defaults, and simple, clear documentation, to
>> make sure that exceptions go somewhere useful.
>>
>> 2. Static files:
>>
>> I had trouble getting static files served. I'm used to using Whitenoise (
>> http://whitenoise.evans.io/en/stable/) for small-to-medium-ish sites
>> that don't need a proper static server, but of course it doesn't work with
>> Channels since Channels doesn't use WSGI! I found the (undocumented)
>> StaticFilesConsumer (
>> https://github.com/jacobian/channels-example/blob/master/chat/routing.py#L5-L8),
>> but that feels less than ideal.
>>
>> I think this might be an opportunity, however. If Daphne learns how to
>> serve static files (perhaps via optional integration with Whitenoise?),
>> this would actually make static media in Django a bit easier by default.
>>
>> [I would be happy to work on this if I get a thumbsup.]
>>
>> 3. WebSocket routing:
>>
>> Channels routes all WebSocket connections to a single set of consumers
>> (the `websocket.*` consumers). This means that if you want multiple
>> WebSocket URLs in a single app you need to manually parse the path. And, to
>> make things more complicated, you only get the WebSocket path passed in the
>> connection message, so you have to also use a channel session to keep track.
>>
>> This feels like a distinct step back from the URL routing we already have
>> in Django, and it was surprising to me to have to do this by hand. It
>> definitely felt like Channels is missing some sort of WebSocket URL router.
>>
>> I had a brief chat with Andrew, who indicates that he'd planned for this
>> to be a post-1.0 feature. I'm not sure I agree - it feels pretty
>> fundamental - but I'd like to hear other thoughts.
>>
>> [This is another thing I'd be interested in working on, assuming a
>> thumbs.]
>>
>> ---
>>
>> Has anyone else here played with Channels? Are there other things I'm
>> missing that might need to be included before we merge this?
>>
>> Jacob
>>
>> [1] https://github.com/jacobian/channels-example
>>
>> [2]
>> https://blog.heroku.com/archives/2016/3/17/in_deep_with_django_channels_the_future_of_real_time_apps_in_django
>> ?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
>

Re: PostGres 9.5 Upsert

[Sean Brant]

> On Jan 10, 2016, at 2:09 AM, Anssi Kääriäinen  wrote:
> 
> If I recall correctly, MySQL doesn't offer a way to specify on which index 
> you want to do the conflict resolution. This leads to problems - the upsert 
> might affect the wrong row if there are multiple unique indexes on the table.
> 
> PostgreSQL's version of upsert has a problem, too. It doesn't offer a direct 
> way to know if the result of the upsert was an insert or update, but Django 
> needs that knowledge, at least for save(). Maybe there is a way (the oid 
> return value seems promising).
> 
> For get_or_create and update_or_create the problem is that the user is free 
> to offer any condition to be used for matching, but PostgreSQL limits the 
> upsert matching to columns in unique index. So, we can use upsert only for 
> unique index cases.

I've always considered this a bug waiting to happen. I have seen many errors 
with the get operation failing because it returned more then one value. Usually 
you don't notice the error until you hit production. I always suggest the 
lookup use fields that have unique indexes.

Changing that would be backwards incompatible so maybe it's a docs issue.

> 
> The save() operation matches the semantics of upsert exactly - maybe we could 
> use upsert there?
> 
>  - Anssi
> 
>> On Sunday, January 10, 2016, Cristiano Coelho  
>> wrote:
>> I agree! Also, does this already happen for the MySQL backend? MySQL has the 
>> insert on conflict update, that could work the same way.
>> However, if I'm not wrong, the docs states that the above methods have a 
>> race condition (obvious since right now it does two operations), but if the 
>> code would actually use native database operations, the race conditions 
>> might be gone for those cases, so that should probably be documented as well.
>> 
>> El viernes, 8 de enero de 2016, 21:13:26 (UTC-3), bliy...@rentlytics.com 
>> escribió:
>>> 
>>> Hey Guys,
>>> 
>>> Postgres 9.5 has added the functionality for UPSERT aka update or insert.  
>>> Any interest in aligning UPSERT on the db layer with the get_or_create or 
>>> update_or_create functionality in django?  Sounds like my company would be 
>>> interested in doing the work if the PR will get the traction.
>>> 
>>> -Ben
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/ae38ba8e-3e79-47fb-92b9-dd305176c58e%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CALMtK1Gub-uL3AdgFSxQkdUNNe_Q47%3D7O%3DZ4qsW3Exwjhkd4ZA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/A53126E5-B9D8-4A5A-A56E-B58B77500E94%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Provide a way to pass kwargs when initializing the storage class

[Sean Brant]

+1 to these ideas. This will make injecting dependancies much cleaner. I’ve 
pointed my BACKEND settings to factory functions in the past.


def storage_factory():
return SomeStorage(some_de)


DEFAULT_STORAGE_BACKEND = ‘path.to.storage_factory'


> On Nov 7, 2015, at 7:10 AM, Shai Berger  wrote:
> 
> On Saturday 07 November 2015 14:55:20 Aymeric Augustin wrote:
>> 
>> Essentially your proposal means reformatting the current file-related
>> settings to this structure:
>> 
>> FILE_STORAGES = {
>>‘media’: {
>>‘BACKEND’: settings.DEFAULT_FILE_STORAGE,
>>‘OPTIONS’: {
>> ‘location’: settings.MEDIA_ROOT,
>> ‘base_url’: settings.MEDIA_URL,
>> # possible override of settings.FILE_CHARSET
>>},
>>},
>>‘static’: {
>>‘BACKEND’: settings.STATICFILES_STORAGE,
>>‘OPTIONS’: {
>> ‘location’: settings.STATIC_ROOT,
>> ‘base_url’: settings.STATIC_URL,
>> # replacement for STATICFILES_FINDERS and STATICFILES_DIRS
>> that would look a lot like template loaders # possible override of
>> settings.FILE_CHARSET
>>},
>> 
>>}
>> }
>> 
>> 
>> How do people feel about this alternative proposal?
>> 
> 
> This, in general, seems like the right thing to do. The only reservation I 
> have is that the 'OPTIONS' key seems superfluous -- why not put the options 
> in 
> the same dictionary as the backend?
> 
> On a related point -- I wouldn't put base_url in there. It is related to 
> files, 
> but not to their storage.
> 
> My 2KB,
>   Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/06F33052-6FEB-48E0-821F-95E34893B30A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: MigrationTestCase

[Sean Briceland]

I like Tom's initial proposition. As mentioned ours is very similar. Here 
is currently what we are using:

class MigrationTestBase(TransactionTestCase):
"""
Custom TestCase containing an extended set of asserts for testing
migrations and schema operations.
Most of this code was derived from Django's private MigrationTestBase:

https://github.com/django/django/blob/stable/1.7.x/tests/migrations/test_base.py

Notes:
If you would like to override setUp() in the test, you will want to
call super().setup() or explicitly invoke 
self.migrate_all_the_way() to
ensure a clean history at the start of each test.
"""

# MUST specify which apps we will need to test within the
app_label = None
test_migration_name = None

# last_migration_nodes is a list of tuples assigned after each time we
# migrate.
# if last_migration_node is None, we will use apps from django.apps 
which
# is the fully migrated App Registry created via our existing source 
code.
last_migration_nodes = None

@classmethod
def setUpClass(cls):
super(MigrationTestBase, cls).setUpClass()
if not cls.app_label or not cls.test_migration_name:
raise NotImplementedError('Must define class defaults: 
app_label, '
  'test_migration_name')

def setUp(self):
super(MigrationTestBase, self).setUp()
self.migrate_all_the_way()

def tearDown(self):
self.migrate_all_the_way()
super(MigrationTestBase, self).tearDown()

def migrate_to(self, app_label, migration_name):
call_command('migrate', app_label, migration_name, verbosity=0)
self.last_migration_nodes = [(app_label, migration_name)]

def migrate_to_test_migration(self):
self.migrate_to(self.app_label, self.test_migration_name)

def migrate_all_the_way(self):
call_command('migrate', verbosity=0)
self.last_migration_nodes = None

def get_current_model(self, app_label, model):
if self.last_migration_nodes is not None:
conn = connections[DEFAULT_DB_ALIAS]
loader = MigrationLoader(conn)
proj_state = loader.project_state(self.last_migration_nodes)
self.apps = proj_state.render()
return self.apps.get_model(app_label, model)
return dj_apps.get_model(app_label, model)

def get_table_description(self, table):
with connection.cursor() as cursor:
return connection.introspection.get_table_description(
cursor, table
)

def assertTableExists(self, table):
with connection.cursor() as cursor:
self.assertIn(
table,
connection.introspection.get_table_list(cursor)
)

def assertTableNotExists(self, table):
with connection.cursor() as cursor:
self.assertNotIn(
table,
connection.introspection.get_table_list(cursor)
)

def assertColumnExists(self, table, column):
self.assertIn(
column,
[c.name for c in self.get_table_description(table)]
)

def assertColumnNotExists(self, table, column):
self.assertNotIn(
column,
[c.name for c in self.get_table_description(table)]
)

def assertColumnNull(self, table, column):
self.assertEqual(
[
c.null_ok
for c in self.get_table_description(table) if c.name == 
column
][0],
True
)

def assertColumnNotNull(self, table, column):
self.assertEqual(
[
c.null_ok
for c in self.get_table_description(table)
if c.name == column
][0],
False
)

def assertIndexExists(self, table, columns, value=True):
with connection.cursor() as cursor:
self.assertEqual(
value,
any(
c["index"]
for c in connection.introspection.get_constraints(
cursor, table).values()
if c['columns'] == list(columns)
),
)

def assertIndexNotExists(self, table, columns):
return self.assertIndexExists(table, columns, False)

def assertFKExists(self, table, columns, to, value=True):
with connection.cursor() as cursor:
self.assertEqual(
value,
any(
c["foreign_key"] == to
for c in connection.introspection.get_constraints(
cursor, table).values()
if c['columns'] == list(columns)
),
)

def assertFKNotExists(self, table, columns, to, value=True):
return self.assertFKExists(table, columns, to, False)



-- 
You received this 

Re: MigrationTestCase

[Sean Briceland]

Let me run it by my CTO. But I should be able to send over our migration
test class.
On Jun 12, 2015 11:58 AM, "Tim Graham" <timogra...@gmail.com> wrote:

> Sure... what do you think of the API that Tom proposed? Did you have
> something different in mind?
>
> On Friday, June 12, 2015 at 10:23:57 AM UTC-4, Sean Briceland wrote:
>>
>> I believe Tom is referring to testing their migration files in order to
>> ensure DB is migrated accordingly.
>>
>> For example, at our company we test all of our source code & Migrations
>> are code too! Most of the time we test rolling migrations forwards and
>> backwards to ensure they will run without a hitch once deployed to
>> production.
>>
>> For data migrations we use the MigrationLoader to generate models at a
>> given state of the migration history. Then we can verify we our code within
>> the migration mutates the data as desired.
>>
>> While Django Migrations are tested, stable, & kicka$$, they do not
>> prevent developers from generating erroneous data migrations or even
>> irreversible schema migrations.
>>
>> I jumped on this post because we now have a pretty beefy Django
>> Application and as a result our Migration Tests take forever. Without
>> getting into to much detail, I want to make sure that it would be okay to
>> post here? or should I open a new thread?
>>
>> On Friday, May 8, 2015 at 12:36:48 PM UTC-4, Andrew Godwin wrote:
>>>
>>> Hi Tom,
>>>
>>> When you say "testing migrations", what do you mean exactly? The
>>> migration framework itself is heavily unit-tested, so I presume you intend
>>> to test things like custom RunPython function bodies and the like?
>>>
>>> Andrew
>>>
>>> On Thu, May 7, 2015 at 3:30 AM, Tom Linford <t...@robinhood.com> wrote:
>>>
>>>> At Robinhood, we've been using a custom in-house MigrationTestCase for
>>>> testing migrations that we'd like to contribute, but want to check the API
>>>> of it before contributing it. Here's the definition of the class:
>>>>
>>>> class MigrationTestCase(TransactionTestCase):
>>>> """
>>>> app_label: name of app (ie. "users" or "polls")
>>>> (start|dest)_migration_name: name of migration in app
>>>> (e.g. "0001_initial")
>>>> additional_dependencies: list of tuples of `(app_label,
>>>> migration_name)`.
>>>> Add any additional migrations here that need to be included in
>>>> the
>>>> generation of the model states.
>>>>
>>>> Usage:
>>>>
>>>> class TestCase(MigrationTestCase):
>>>> app_label = ...
>>>> start_migration_name = ...
>>>> dest_migration_name = ...
>>>> additional_dependencies = ...
>>>>
>>>> def setUp(self):
>>>> # Create models with regular orm
>>>> super(TestCase, self).setUp()
>>>> # Create models with start orm. Access model with:
>>>> # self.start_models[""][""]
>>>> # Note that model_name must be all lower case, you can just
>>>> do:
>>>> # ._meta.model_name to get the model_name
>>>>
>>>> def test(self):
>>>> # Still using start orm
>>>> self.migrate_to_dest()
>>>> # Now, you can access dest models with:
>>>> # self.dest_models[""][""]
>>>> """
>>>> app_label = None
>>>> start_migration_name = None
>>>> dest_migration_name = None
>>>> additional_dependencies = []
>>>>
>>>>
>>>> Let me know if this API is agreeable and I can make a PR for this
>>>> feature.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to django-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>> To view this discuss

Re: MigrationTestCase

[Sean Briceland]

I believe Tom is referring to testing their migration files in order to 
ensure DB is migrated accordingly.

For example, at our company we test all of our source code & Migrations are 
code too! Most of the time we test rolling migrations forwards and 
backwards to ensure they will run without a hitch once deployed to 
production. 

For data migrations we use the MigrationLoader to generate models at a 
given state of the migration history. Then we can verify we our code within 
the migration mutates the data as desired.

While Django Migrations are tested, stable, & kicka$$, they do not prevent 
developers from generating erroneous data migrations or even irreversible 
schema migrations.

I jumped on this post because we now have a pretty beefy Django Application 
and as a result our Migration Tests take forever. Without getting into to 
much detail, I want to make sure that it would be okay to post here? or 
should I open a new thread?

On Friday, May 8, 2015 at 12:36:48 PM UTC-4, Andrew Godwin wrote:
>
> Hi Tom,
>
> When you say "testing migrations", what do you mean exactly? The migration 
> framework itself is heavily unit-tested, so I presume you intend to test 
> things like custom RunPython function bodies and the like?
>
> Andrew
>
> On Thu, May 7, 2015 at 3:30 AM, Tom Linford  > wrote:
>
>> At Robinhood, we've been using a custom in-house MigrationTestCase for 
>> testing migrations that we'd like to contribute, but want to check the API 
>> of it before contributing it. Here's the definition of the class:
>>
>> class MigrationTestCase(TransactionTestCase):
>> """
>> app_label: name of app (ie. "users" or "polls")
>> (start|dest)_migration_name: name of migration in app
>> (e.g. "0001_initial")
>> additional_dependencies: list of tuples of `(app_label, 
>> migration_name)`.
>> Add any additional migrations here that need to be included in the
>> generation of the model states.
>>
>> Usage:
>>
>> class TestCase(MigrationTestCase):
>> app_label = ...
>> start_migration_name = ...
>> dest_migration_name = ...
>> additional_dependencies = ...
>>
>> def setUp(self):
>> # Create models with regular orm
>> super(TestCase, self).setUp()
>> # Create models with start orm. Access model with:
>> # self.start_models[""][""]
>> # Note that model_name must be all lower case, you can just 
>> do:
>> # ._meta.model_name to get the model_name
>>
>> def test(self):
>> # Still using start orm
>> self.migrate_to_dest()
>> # Now, you can access dest models with:
>> # self.dest_models[""][""]
>> """
>> app_label = None
>> start_migration_name = None
>> dest_migration_name = None
>> additional_dependencies = []
>>
>>
>> Let me know if this API is agreeable and I can make a PR for this feature.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/8818bf72-aa66-4351-9177-e6e0f6605386%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/74578134-3314-4715-ba94-b63da47c5dd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make url patterns group kwargs more simple

[Sean Bleier]

You might want to check out Surlex[1], written by Cody Soyland.  It
basically does what you want.

[1] http://codysoyland.com/projects/surlex/documentation/


On Wed, May 28, 2014 at 8:54 AM, Alexandr Shurigin <
alexandr.shuri...@gmail.com> wrote:

> Hi all.
>
> What do you think about adding some extra default and more simpler syntax
> for url patterns?
>
> Now patterns looks little bit difficult, especially if you have long urls
> with 2-3 params.
>
> For example take a look into url.
>
> url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',
> views.GameNewsItem.as_view(), name="view_news_view")
>
> This is ‘good seo url’ for big project. This url have game genre, game
> slug name, /news/ and news slug name.
>
> For example this matches path /arcade/pacman/news/new-update-2014/
>
> This is pretty cool when site have such urls and support all url subpaths,
> user can simple remove some path in url and go other pages of site catalog
> structure.
>
> In presented example i wanted to show you this url entry shard to read
> (but not so difficult to write) when you supporting your project.
>
> When you have about 20-30 same style urls in one file, this makes your
> urls file unreadable :)
>
> Maybe allow user enter url masks in simpler way by adding some magic?
>
> For django is not problem make url regexps from string with ‘meta tags’
> and process it way like it work now. But i think user will be really happy
> to enter simpler (and shorter!) urls.
>
> I mean we allow user only describe his urls simpler.
>
> For example in ruby on rails user can enter urls like
>
> get 'products/:id/purchase' => 'catalog#purchase', as: :purchase
>
> Where :id is just shortcut for regexp pattern group.
>
> I think we (or me, no difference) can do same way.
>
> We can do it 2 ways:
>
> 1. hardcode some usually used tags (for example id, day, year, slug, any
> other) and words built from them (for example we understand that :id and
> :product_id have the same path type ([0-9]+)).
> 2. Make library for registering such tags like template tag library and
> add rules from #1 to it. Allowing way for users to extend library tags with
> their own.
>
> Using this way, we can get very simple and fancy urls. For example my game
> news url will look like:
>
> url(r’^:slug_genre/:slug/news/:slug_item$', views.GameNewsItem.as_view(),
> name="view_news_view")
>
> This will make urls very short, fast-readable and writable.
>
> Also we can skip in pattern masks ?P, for example from url pattern
>
> ([^/]+)
>
> we can simple compile
> (?P[^/]+)
>
> I think a lot of users will appreciate this feature. What you think?
>
> Django urls are not simple right now for users and looks little ugly,
> because 99% users reuse standard types of masks (id like - [0-9]+, slug
> like - [a-z0-9]+, year [0-9]{4}, month [0-9]{2}, day [0-9]{2}).
>
> But of course user can combine url shortcuts with their custom regexps.
>
>
>
> --
> Alexandr Shurigin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/etPan.5386069d.57e4ccaf.406%40MacBook-Pro-dude.local
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFtT_0KEgdyusp%3DhSn0z361zp%3DQvsy0f3-AOgi0UncveNNdsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: ttl method for cache

[Sean Bleier]

Hi Piotr,

For what it's worth, I have an implementation of ttl on django-redis-cache:
https://github.com/sebleier/django-redis-cache/commit/626a3263c428cf59b1428f5fc2aa638efd77346a

It's slightly different from your snippet in that if the key does not exist
(because it is expired or didn't exist in the first place), the returned
value will be 0 instead of None.  None is reserved for non-volatile keys
with no expirations.

–Sean


On Mon, May 5, 2014 at 1:16 PM, Piotr Gosławski
<piotr.goslaw...@gmail.com>wrote:

> Hi!
>
> Since the contribution workflow is a bit confusing to me, I'll just leave
> it here.
> I think django's cache needs ttl (time to live) method that would return
> time left until specified key expires. I, for instance, needed one when
> writing
> a rate limiter. Without it I would have to store twice as much key-value
> pairs
> in cache. I ended up with a workaround that dynamically binds ttl method,
> but only for locmem and redis, since those are the backends I use.
>
> Here is my workoround, maybe it will be of some use:
> https://github.com/p-tr0/snipets/blob/master/django_cache_ttl.py
>
> I guess the proper way would be to add a method that just raises
> NotImplementedError and then cover it one backend at a time.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/07aa224a-3716-48c0-8af6-757d875c6d88%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/07aa224a-3716-48c0-8af6-757d875c6d88%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFtT_09-ERyrWR%2BukAn0EZ0dc1Kcru5K3h3JXett2GT%3D0fqRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Sean Bleier]

I like the implementation referenced in the SO thread, but I would just
point out that `.get_or_none()` should accept both *args and **kwargs. `Q`
objects can be passed in as arguments to `.get()` and `.filter()`, so it's
only natural to allow that for `.get_or_none()`.


On Thu, Mar 13, 2014 at 10:26 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Just read through all those threads/tickets, here's my conclusion.
>
> #2659 was rejected 8 years ago [1] on the basis that it's a "feature
> creep", and that it "doesn't offer anything revolutionary". However the
> same could be said for .first() and .last(), yet those were accepted.
>
> #11352 was rejected by luke plant 2 years ago [4] based on the suggested
> implementation in that ticket, which is not the same implementation as what
> I'm proposing this time round. The design of `get_object_or_none` being
> added into shortcuts is not a good approach, and was right to be rejected.
>
> #17546 was rejected 2 years ago [3] on the basis that #2659 and #11352
> were rejected, both of which I've addressed above.
>
> First argument - `first()` and `.last()` have been added, yet the
> principle behind why they were added is the same as `.get_or_none()`.
> Second argument - The implementation being suggested in this thread is not
> the same as what has been suggested in the three rejected tickets.
> Third argument - Thread [2] had mostly positive feedback, but there was no
> BDFL decision specifically on `get_or_none`.
>
> If I'm missing something here, please let me know.
>
> Cal
>
> [1] https://code.djangoproject.com/ticket/2659
> [2]
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
> [3] https://code.djangoproject.com/ticket/17546
> [4] https://code.djangoproject.com/ticket/11352
>
>
> On Thu, Mar 13, 2014 at 5:05 PM, Shai Berger  wrote:
>
>> On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd]
>> wrote:
>> > Seems this issue was brought up several years ago, though the thread was
>> > later hijacked for other functionality and get_or_none fizzled out.
>> > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
>> >
>> > In Django 1.6 there were convenience methods added for .first(), for the
>> > same principle of not having to catch an IndexError (or in this case, a
>> > DoesNotExist error);
>> >
>> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
>> > s.query.QuerySet.first
>> >
>> > This seems to be wanted by several users, as seen here;
>> >
>> http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
>> > -or-none-if-nothing-matches
>> >
>> > Seems to be quite an easy fix, just needs a proper patch.
>> >
>> > Any thoughts?
>> >
>> You linked the wrong thread.
>>
>>
>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
>>
>>
>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ
>>
>> I was (and still am) for a get_or_none() that raises an exception when
>> it finds multiple objects, but we were overruled.
>>
>> Shai.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHKQagFCyR2GGcY%2BV%2BGzdR%3DKi3P9%2BTVbT4BzVD_bDoJBN1w6Qw%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to 

Re: Predicate as suggested new feature to extend url resolver process

[Sean Bleier]

I think what Rach is suggesting is different from @require_GET,
@require_POST, etc. The patch essentially makes a view invisible if
the predicate function returns False.

I'm not sure this would be good for inclusion to django, since you are
tying url resolution to application state .  This could have negative
implications, especially for performance.  On top of that, the same
functionality could be achieved by creating a function/class to route
the request further after django has initially routed the request.
This would be preferable because the performance hit would be isolated
to the resolved routing function/class.



On Wed, May 22, 2013 at 2:37 PM, Jacob Kaplan-Moss  wrote:
> I'm not sure I understand what you're proposing here. How is this
> different from @require_GET, @require_POST, and friends?
>
> Jacob
>
> On Wed, May 22, 2013 at 11:05 AM, Rach Belaid  wrote:
>> I just did a pull request resulting of my last Django sprints for
>> adding a new feature in Django.
>>
>> https://code.djangoproject.com/ticket/20479
>>
>> The idea is being able to have more control on the url resolving
>> process.
>>
>> I have no merit behind the idea of predicate. Predicate is one of my
>> favorite feature in Pyramid/Pylons to allow more complex and flexible
>> routing.
>>
>> I will be curious about feebacks? Do you like this idea of features ?
>>
>> The implementation is probably imperfect so don't be too harsh ;) we
>> can always fix the implementation.
>>
>> For people unaware about what is a predicate, I advice to check the
>> pyramid doc here:
>> http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#predicate-arguments
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: URL dispatcher slow?

[Sean Bleier]

JKM, I'm wondering if it would benefit the community to house
djangobench under https://github.com/django to give it more
visibility.  Just a thought.

On Thu, Oct 11, 2012 at 9:45 AM, ptone  wrote:
>
>
> On Thursday, October 11, 2012 1:21:09 AM UTC-7, Russell Keith-Magee wrote:
>>
>>
>> That said - could Django be faster? Sure. *Anything* can be improved.
>>
>> So, if you've got a suggestion, make it. If you think URL resolving is
>> the source of the problem, propose a way to improve the speed of URL
>> resolvers. If you think the template language is the problem, propose
>> a fix.
>
>
> To do my part to increase the signal:noise.
>
> I'll point out that just as writing a failing test is a great way to augment
> a bug report - contributing or improving a benchmark for:
>
> https://github.com/jacobian/djangobench
>
> would be a good way to contribute to a discussion around a particular
> performance improvement you're interested in seeing happen.
>
> -Preston
>
> --
> 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/-/kI7jNl7gYwEJ.
>
> 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: GitHub migration done!

[Sean Lee]

Great job!

在 2012年4月28日星期六UTC+8上午11时08分09秒，Adrian Holovaty写道：
>
> On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty  
> wrote: 
> > We're going to do the migration to GitHub today. This means we'll no 
> > longer be committing code to our Subversion repository. Committers, 
> > please hold off on making commits until the migration is done. 
>
> OK, it's live! 
>
> https://github.com/django/django 
>
> A few quick points (though this definitely deserves a more in-depth 
> writeup): 
>
> * I renamed the old (mirror) repository to 
> https://github.com/django/django-old. We had talked about deleting it 
> outright to avoid confusion, but I realized at the last minute that 
> doing so would have deleted all the pull requests. I didn't want to 
> throw all of that out, and I think we can figure out a way to use 
> those pull requests in the new repository. 
>
> * I only migrated trunk (now called "master"), rather than including 
> all of the branches. This was the result of a bunch of discussion on 
> IRC with Brian R., et al. The thinking is that it kept the migration a 
> lot cleaner/simpler, and we can always add branches later. Of course, 
> we'll need to create the latest release branches. Otherwise, we can 
> consider the SVN branches on an individual basis. 
>
> * As expected, all forks of the old repository are now broken. Can 
> somebody volunteer to write some documentation on how to upgrade your 
> old fork to use the new upstream repo (rebase? simple patch?)? 
>
> * We're going to keep the Subversion repository around indefinitely, 
> but it'll no longer be updated. 
>
> * We're going to keep using Trac for tickets, but pull requests on 
> GitHub are also welcome. 
>
> * Clearly there are lots of bits of process that need to be updated 
> now, from the django-updates mailing list to our "contributing" 
> documentation, etc. We'll take care of all of that in the coming days, 
> and we should all expect some degree of confusion and unsettlement in 
> the community. That's totally fine, and we'll get through it. :-) 
>
> * Finally, big thanks to the folks on IRC today who helped me through 
> the process and contributed good ideas. 
>
> I'm planning to write up a blog post on how the process went, for the 
> benefit of the five open-source projects still using Subversion. 
>
> Adrian 
>

-- 
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/-/9CyF3ab4Ya4J.
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: Proposal: upgrading the choices machinery for Django

[Sean Brant]

I agree we don't really gain anything from including this in core.
Django model utils[1] has a pretty solid implementation of a choice
abstraction.

[1] https://github.com/carljm/django-model-utils

On Wed, Apr 4, 2012 at 11:41 AM, Adrian Holovaty  wrote:
> 2012/4/3 Łukasz Langa :
>> Explicit choice values::
>>
>>  GENDER_MALE = 0
>>  GENDER_FEMALE = 1
>>  GENDER_NOT_SPECIFIED = 2
>>
>>  GENDER_CHOICES = (
>>      (GENDER_MALE, _('male')),
>>      (GENDER_FEMALE, _('female')),
>>      (GENDER_NOT_SPECIFIED, _('not specified')),
>>  )
>>
>>  class User(models.Model):
>>      gender = models.IntegerField(choices=GENDER_CHOICES,
>>              default=GENDER_NOT_SPECIFIED)
>>
>>      def greet(self):
>>          if self.gender == GENDER_MALE:
>>              return 'Hi, boy.'
>>          elif self.gender == GENDER_NOT_SPECIFIED:
>>              return 'Hello, girl.'
>>          else: return 'Hey there, user!'
>>
>> This is a saner way but starts getting overly verbose and redundant. You can
>> improve encapsulation by moving the choices into the ``User`` class but that 
>> on
>> the other hand beats reusability.
>
> I don't see the immediate need for Yet Another Sub-framework, as
> described in this proposal. This is what I normally do, and it works
> fine:
>
> class User(models.Model):
>    MALE = 0
>    FEMALE = 1
>    GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
>    gender = models.IntegerField(choices=GENDERS)
>
>    def greet(self):
>        return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
>
> If people aren't understanding that, we should improve our documentation.
>
> Also, the fact that we *don't* have a sub-framework for this lets
> people do whatever they want -- including using the dj.choices module.
> So I am -1 on including this in Django proper.
>
> Adrian
>
> --
> 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: start using less (and bootstrap!)

[Sean Brant]

On Thu, Feb 2, 2012 at 4:17 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>
>
> On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty <adr...@holovaty.com> wrote:
>>
>> On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant <brant.s...@gmail.com> wrote:
>> > Is this up somewhere public? I've been fighting the urge to do this as
>> > well. Using django-compressor with less on Heroku is a non-starter
>> > since you can't install node. Having this as a Python module would be
>> > handy.
>>
>> Not yet, alas, but hopefully soon.
>>
>> Adrian
>>
>> --
>> 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.
>>
>
> Perhaps this is too far in the future looking.  But at a certain point the
> admin must become a separate project.  One of the major goals of
> newforms-admin ('lo those years ago) was to demote the admin from special
> status, with hooks inside core left and right, to "just an app".  Let's
> carry that to the logical conclusion: just an app *outside of Django*.
>
> That gives the maintainers the freedom to reinvent it, and use tools like
> less or bootstrap without it needing to be an issue of policy for all of
> Django.  Because when I first read saw this thread my thought was, "Hmm,
> what unholy mess of requirements am I going to need if I want to just run
> the test suite.  Will I still be able to write new features in forms without
> needing to learn what the hell less or compass is?".  Several years ago, I
> opposed using jQuery in the admin, on the principle that Django should be
> completely free of entangling alliances.  I made that argument more or less
> out of habit, just because I felt it was an argument that ought to be made,
> but really I was pretty happy to get to use jQuery.  Now I'm saying, it's
> pretty clear that admin 2.0 (or 3.0, or 4.0, anyone counting?) is going to
> be a beast that far outstrips almost anything else in Djanog (besides the
> ORM ;)) in complexity, with more dependencies, more associated tooling, and
> more usecases (i.e. it's not just a tool for developers to use, it's also
> something for end users of *our* users' apps to use).  Keeping that in
> Django itself is going to stunt it's growth, and it's going to suck for new
> developers to Django who, like many of us (or at least myself), were and
> still are, Python developers at heart, who can write some HTML, badly.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
> --
> 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.

+1

Given how flexible the admin is doing somethings is still pretty
annoying. I feel like if it was a external project with its own
release schedule more progress could be made. FWIW i'm experimenting
with an admin interface that relies heavily on class based views. So
far I like it. CBVs seem to have more useful hooks then the admin
currently has. At the very least I think the new admin needs to not be
backwards compatible with the current admin.

So my vote is for django-admin2 as an external project.

-- 
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: start using less (and bootstrap!)

[Sean Brant]

On Thu, Feb 2, 2012 at 2:36 PM, Adrian Holovaty  wrote:
> On Thu, Feb 2, 2012 at 2:07 PM, Idan Gazit  wrote:
>> * less.js has the distinct advantage of being easier to develop for than
>> sass for our purposes.If we go with a less.js solution (like bootstrap), we
>> might not need to require that all edits to admin "source" stylesheets
>> (less/scss) come with the recompiled CSS. This lowers the barrier to
>> contribution significantly, at the cost of a bit of site performance as less
>> gets compiled client-side. That being said, the admin isn't supposed to be
>> used as a a high-traffic site (or shouldn't be, I can't say how people abuse
>> it).
>
> Two points:
>
> * If we decide to change the admin site to use LESS, we should ship
> compiled CSS. No need to introduce the less.js overhead.
>
> * I have been working on a Python LESS compiler in my spare time, and
> there could be a use for it in here.


Is this up somewhere public? I've been fighting the urge to do this as
well. Using django-compressor with less on Heroku is a non-starter
since you can't install node. Having this as a Python module would be
handy.


> Adrian
>
> --
> 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.

Djangocon US Call for Talks

[Sean O'Connor]

Hey Everybody,

I know we're a bit late this year but the new 
Djangocon.US<http://djangocon.us/> site 
is finally up and we are accepting talk proposals today.

Unfortunately, thanks to our lateness we will only be able to accept 
proposals for the next* *two weeks.  This means if you want to have a chance 
to speak at this year's Djangocon, you need to get your proposal in ASAP.

You can read more about submitting a proposal at 
http://djangocon.us/blog/2011/06/22/call-papers/ and feel free to contact me 
directly if you have any questions or concerns.

*Sorry for the cross post of this on both lists, but given the very short 
timeline that we're working with, we want to make sure everybody knows ASAP.
*

-Sean O'Connor
s...@seanoc.com

-- 
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/-/YTQUe_ZDth8J.
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: Javascript Testing

[Sean Bleier]

Hi Luke,

This looks like it could be really interesting or useful, but at the
> moment I can't quite see my way to working out how to use it. I'd really
> like to be able to:
>
> 1) apply a patch (or two) to my copy of Django
>

Would you like me to attach a patch to a ticket? I could attach it to
https://code.djangoproject.com/ticket/16193 or open a new ticket using a
more generic description of a javascript testing framework.


> 2) run an example test that proves something useful about the admin's
> javascript (for instance - or some other example app that is provided).
>
>
I recently added tests for URLify.js from the admin, that may give you a
better practical sense of how to test the admin.
https://github.com/sebleier/django/commit/3a358cc3a4c2fa9a1fda0d58c46309c9f7956d6a


Thanks,

--Sean

-- 
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.

Javascript Testing

[Sean Bleier]

Hello everyone,

A couple months ago I started work on a django branch [1] (with the help of
@jezdez) that introduces a framework for writing javascript unit tests using
QUnit[2].  I started with QUnit because Django already included jQuery in
the admin and seemed like a natural extension, but it would be nice to hear
opinions from people that know more about javascript testing than I.

Since I haven't touch it in a couple months, I thought I would share it with
django-developers to get some more eyes on it and discuss any missing
features or implementation details. It also be nice if Idan or any other
designery person could look it over and give some UI/UX advice.

Just to give a overview, the javascript testing framework is initiated by
first collecting static media and then starting a special runserver:

./manage.py collectstatic
./manage.py jstest

This starts a runserver that collects and serves everything you need to run
the javascript tests found within an installed app. More detail can be found
in these preliminary docs[3], though they need to be moved into their proper
place within the docs directory.

I'm hoping we can figure out a way forward so that we can start writing
tests for the admin and elsewhere.

Cheers,

--Sean


[1] https://github.com/sebleier/django/tree/qunit
[2] http://docs.jquery.com/Qunit
[3]
https://github.com/sebleier/django/blob/qunit/django/test/javascript/__init__.py

-- 
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: jQuery.tmpl() and Django

[Sean Brant]

2011/5/27 Gábor Farkas <ga...@nekomancer.net>:
> On Fri, May 27, 2011 at 7:04 AM, Sean O'Connor <s...@seanoc.com> wrote:
>> A better approach would for Django to provide some tools and documentation
>> to help people work around the conflict.  One easy solution would be to
>> provide a verbatim tag like what ericflo wrote
>> at https://gist.github.com/629508.  Another would be to provide
>> documentation on tools that make it easy to load jquery style templates via
>> ajax like icanhaz.js.
>
> (technically, there is an open jquery-templating ticket about making
> the template-tag format customizable:
> https://github.com/jquery/jquery-tmpl/issues/74)
>
> i had the same problem in the past (btw. mustache.js also uses the
> two-curly-braces notation :-),
> and unfortunately the verbatim tag did not solve the problem, because
> sometimes you need
> to use the django-templating INSIDE the jquery template
> .
> for example:
> """
> .
> .
> 
> Are you sure to delete {{ name_of_thing }}?
> <button>{% trans "YES"%}</button>
> <button>{% trans "NO"%}</button>
> 
> """
>
> here i want the {{ name_of_thing }} to be handled by
> jquery-templating, but the translation
> should happen using the django-tags.
>
> so either i have to use the {% verbatim %} tag only around the places
> where i have javascript-variables
> (and not around the whole jquery-template), or i have to do the
> translation in python,
> and send them in as variables in javascript. both seem to be impractical.
>
> the approach i chose was to use a different variable-syntax
> (instead of "{{ thing }}", i use "[[ thing ]]"), and before using the 
> template,
> i simply replace those with the correct values. it's not nice, but
> still the most practical solution i could find.
>
> gabor

I wonder if verbatim as a filter makes more sense, for example::


Are you sure to delete {{ "{{ name_of_thing }}"|verbatim }}?
<button>{% trans "YES"%}</button>
<button>{% trans "NO"%}</button>


The filter would then just return {{ name_of_thing }} back to the
template. If you wanted to use a template variable as the name of the
jQuery variable this approach would still fail.

Now that I think about it maybe the replace tokens approach is the
most flexible.

{% verbatim "[[" "]]" %}

Are you sure to delete [[ name_of_thing ]]?
<button>{% trans "YES"%}</button>
<button>{% trans "NO"%}</button>

{% endverbatim %}

You you could then choose the tokens that get replaced.

- Sean

> --
> 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: jQuery.tmpl() and Django

[Sean O'Connor]

I think it would be a bit much for us to ask the jQuery crew to change their 
template language to avoid conflict with ours. Aside from the amount of 
backwards incompatible work we'd be asking them to do, they'd probably just end 
up with a new conflict with some other template language. At the end of the day 
this is also more of a symptom than an underlying problem. Even if we got the 
jQuery crew to change their syntax, there would still be other JS template 
languages with the same conflict (e.g. mustache.js).

A better approach would for Django to provide some tools and documentation to 
help people work around the conflict. One easy solution would be to provide a 
verbatim tag like what ericflo wrote at https://gist.github.com/629508. Another 
would be to provide documentation on tools that make it easy to load jquery 
style templates via ajax like icanhaz.js.

My vote is that we fix the problem once and for all on our end by providing 
compatibility tools and guidance instead of trying to tell the entire JS 
community to not conflict with out template syntax :)

-- 
Sean O'Connor
http://www.seanoc.com

On Thursday, May 26, 2011 at 11:14 PM, Ori Livneh wrote:

> Hello,
> 
> jQuery.tmpl(), a beta feature slated for inclusion in the main jQuery
> brach, uses some of the same syntax as Django in its templating
> markup, which is a bit of a bummer. I'm writing to see whether you
> think we should get in touch with the jQuery team to see if they could
> plausibly change it.
> 
> There are, obviously, quite a lot of templating languages out there,
> and some of them are bound to clash with Django, and that's not a
> problem. But Django and jQuery are often deployed together (jQuery is
> actually bundled with Django for use in the admin), making this clash
> especially annoying.
> 
> You might think this isn't an issue since JavaScript code should be
> served from static files anyway, but there's an added complication.
> One of the patterns jQuery.tmpl() recommends is nesting templates
> within a 

Caching model choice fields in admin inlines.

[Sean Brant]

If you have ever used a inline in the admin for a model that contained
a model choice field you have probably noticed it has to query the
database for each row to fill the select drop-down. This results in n+
identical queries.

I though it might be useful to have a way to tell a admin inline to
cache the choices of fields. Here is some rough code that gets the job
done::


from django.forms.models import BaseInlineFormSet


class CachedInlineFormSet(BaseInlineFormSet):
cached_fields = []

def _construct_form(self, i, **kwargs):
form = super(CachedInlineFormSet, self)._construct_form(i,
**kwargs)
for cache_field in self.cached_fields:
field = form.fields[cache_field]
field.cache_choices = True
choices = getattr(self, '_cached_%s_choices' %
cache_field, None)
if choices is None:
choices = list(field.choices)
setattr(self, '_cached_%s_choices' % cache_field,
choices)
field.choice_cache = choices
return form


class CachedTabularInline(admin.TabularInline):
cached_fields = []

def get_formset(self, request, obj=None, **kwargs):
formset = super(CachedTabularInline,
self).get_formset(request, obj=None, **kwargs)
formset.cached_fields = self.cached_fields
return formset


class MyInline(CachedTabularInline):
model = MyModel
cache_fields = ['myfk']


Im not super big on how this patches the classes in various places so
i'm open to better suggestions. Is this something that the admin could
benefit from or is this better kept as a 3rd party tool?

-- 
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.

r15580 breaks change list result template overwrites

[Sean Brant]

Looks like r15580 modified the way change list rows are returned. The
template used to just iterate over {{ result }} but now requires
iteration over {{ result.row }}.  This will breaking anyones templates
that happen to overwrite admin/change_list_results.html. Does
overwriting admin templates fall into public api territory?

-- 
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: Changing settings per test

[Sean Brant]

On Nov 4, 4:26 pm, Alex Gaynor  wrote:
> 2010/11/4 Łukasz Rekucki :
>
>
>
>
>
> > Funny, I had exactly the same problem today at work while refactoring
> > my application's tests suite :).
>
> > Currently, I'm using a pair of save/restore functions: save() monkey
> > patches the settings module and returns a dictionary of old values,
> > restore() puts back the old values based on the dictionary. I usually
> > put this in setUp/tearDown so I don't have to repeat in every test. I
> > was about to propose that
> > Django's TestCase should do something similar by default.
>
> > Both the decorator and context processor are very useful, but having
> > something to set values for the whole test case instead of a single
> > test or a block of code would be great too. I was thinking about
> > something in line of:
>
> >    class EmailTestCase(TestCase):
> >        settings = dict(DEFAULT_FROM_EMAIL="webmas...@example.com")
>
> > On 4 November 2010 21:11, David Cramer  wrote:
> >> With a decorator approach here's what I whipped up:
>
> >> (This is dry code)
>
> >> def with_settings(**overrides):
> >>    """Allows you to define settings that are required for this
> >> function to work"""
> >>    NotDefined = object()
> >>    def wrapped(func):
> >>       �...@wraps(func)
> >>        def _with_settings(*args, **kwargs):
> >>            _orig = {}
> >>            for k, v in overrides.iteritems():
> >>                _orig[k] = getattr(settings, k, NotDefined)
>
> >>            try:
> >>                func(*args, **kwargs)
> >>            finally:
> >>                for k, v in _orig.iteritems():
> >>                    if v is NotDefined:
> >>                        delattr(settings, k)
> >>                    else:
> >>                        setattr(settings, k, v)
> >>        return _with_settings
> >>    return wrapped
>
> >> I'm not familiar with the context managers, but I imagine those would
> >> solve things like adjusting CONTEXT_PROCESSORS.
>
> >> On Thu, Nov 4, 2010 at 1:06 PM, Dan Fairs  wrote:
>
>  Let me start with an example test:
>
>  def test_with_awesome_setting(self):
>     _orig = getattr(settings, 'AWESOME', None)
>     settings.AWESOME = True
>
>     # do my test
>     ...
>
>     settings.AWESOME = _orig
>
> >>> Pedant: there's a small bug above which has bitten me before doing a 
> >>> similar thing - settings.AWESOME  ends up set to None after the test has 
> >>> run if it didn't exist before.
>
>  Anyways, I'd love to hear how others have dealt with this and any
>  other possible solutions.
>
> >>> I've used Michael Foord's Mock library to patch a setting for the 
> >>> duration of a test case. Chris Withers' testfixtures library also has 
> >>> some sugar to provide a context manager approach, though I haven't used 
> >>> that in a little while.
>
> >>> Cheers,
> >>> Dan
>
> >>> --
> >>> Dan Fairs | dan.fa...@gmail.com |www.fezconsulting.com
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups 
> >>> "Django developers" group.
> >>> To post to this group, send email to django-develop...@googlegroups.com.
> >>> To unsubscribe from this group, send email to 
> >>> django-developers+unsubscr...@googlegroups.com.
> >>> For more options, visit this group 
> >>> athttp://groups.google.com/group/django-developers?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "Django developers" group.
> >> To post to this group, send email to django-develop...@googlegroups.com.
> >> To unsubscribe from this group, send email to 
> >> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group 
> >> athttp://groups.google.com/group/django-developers?hl=en.
>
> > --
> > Ł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-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> Well, there's no reason the decorator couldn't be used as a class
> decorator (on 2.6 and above).  I'll admit that the settings attribute
> on TestCase is more consistant with how we've handled other things
> (urls, fixtures), however, for whatever reason I'm not a fan, as it
> forces you to split up tests that should logically be grouped on a
> single class.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me

What if it worked like self.client. So self.settings would be the
current settings with 

Re: Bump/question for #13956

[Sean Brant]

Has supporting kwargs along with args been mentioned? I would find
having both very helpful. Maybe we can lean on the work happening for
the include and with tags.


On Wed, Nov 3, 2010 at 10:06 AM, Stephen Burrows
 wrote:
> As far as I know, the only thing still missing from the ticket is a
> decision as to whether there need to be documentation changes for
> simple tags and inclusion tags... if there need to be changes, I could
> try working on them. I would just need to know.
> Best,
> Stephen
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: contrib.staticfiles app concerns

[Sean Bleier]

I agree with Carl,

> Staticfiles has a very specific, well-defined purpose (collecting media
> files from apps), which fills a major hole in the Django "story" for
> reusable apps.


IMHO contrib apps should have the following characteristics (and probably
more):
* Solves a problem that can be described in one short sentence.
* Solves a fundamental problem in web development, including problems
involving the reusable app paradigm.
* Doesn't restrict the programmer from using other tools to solve the same
problem.
* Promotes a convention among developers.

Staticfiles solves the problem of reusable app media collection and doesn't
restrict the developer from using something else. It also promotes the
convention of storing media within a "static" directory, which will help
adoption of new reusable apps.  To me, adding staticfiles to Django was a
logical move that will help the community.  Just my two cents.

Cheers,

--Sean

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

Re: variable view name in url tag

[Sean Brant]

On Oct 3, 8:08 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant <brant.s...@gmail.com> wrote:
>
> > On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
>
> >> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant <brant.s...@gmail.com> wrote:
> >>> I know this has come up over the last few years[1] and people are
> >>> mixed on the action that should be taken. I would like to bring it up
> >>> again as it has bitten me a few time lately.
>
> >>> I seems the biggest concern is backwards compatibility of the syntax.
> >>> I feel that should not stop us from fixing something that is an
> >>> annoying wart and also keeping the syntax in line with how other tags
> >>> work.
>
> >>> In this thread[2] Malcolm suggested introducing a new tag and
> >>> depreciating the old one which could be done by bringing something
> >>> like[3] into core. Im not huge on the idea of have 2 tags that do the
> >>> same thing only with slightly different syntax, but if that is the
> >>> cleanest upgrade I'm +1.
>
> >>> I think this can still be done in a backwards compatible way[4],
> >>> unless I'm missing something.
>
> >> This isn't backwards compatible in every case. Consider:
>
> >> {% url foo %}
>
> >> foo could be:
> >> - A URL pattern name
> >> - A variable in the context
> >> - A variable in the context *and* a URL pattern name
>
> >> It's the third case where your proposal has problems. Under the
> >> current implementation, it's *always* interpreted as a URL pattern
> >> name. Under your proposal, the context variable would take precedence
> >> in the third case.
>
> >> It's also backwards incompatible in the second case (though not in a
> >> way that matters as much): if you have an existing template that
> >> raises an error, but you have a context variable that matches the name
> >> you've used, your implementation *won't* raise an error.
>
> >> However, there is another way (an alternative to adding a parallel tag) :-)
>
> >> An interesting quirk/feature of Django's template language: if you
> >> register template tags with the same name, the last registered name
> >> wins.
>
> >> This means we can define a "future_url" template tag library that
> >> registers a {% url %} template tag. Then, in your code, you can say:
>
> >> {% load future_url %}
> >> {% url "url-name" foo=bar %}
>
> >> and get the new behavior. Then, we can put PendingDeprecationWarnings
> >> in the old {% url %} tag definition, upgraded to DeprecationWarnings
> >> in 1.4. Then, in 1.5, we switch the behavior over and start
> >> deprecating the future_url tag library.
>
> >> I'm completely in favor of making this change; the behavior of the url
> >> tag has always been an annoying wart, and it would be good to clean it
> >> up.
>
> >> Yours,
> >> Russ Magee %-)
>
> > Thanks for the feedback Russ. I know it couldn't be that straight forward. 
> > I'll work on a patch this week that
> > implements what you mentioned. Would it be best to start a new ticket or 
> > re-open the old ticket?
>
> Open a new ticket. #7917 proposes fixing the existing tag; this is a
> complete new approach to the problem. However, make sure you reference
> the old ticket and discussions so we have a point of reference. Feel
> free to accept the new ticket for the 1.3 milestone.

Okay I created a new ticket with patch for this.
http://code.djangoproject.com/ticket/14389

> Yours,
> Russ Magee %-)

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

Re: variable view name in url tag

[Sean Brant]

On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:

> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant <brant.s...@gmail.com> wrote:
>> I know this has come up over the last few years[1] and people are
>> mixed on the action that should be taken. I would like to bring it up
>> again as it has bitten me a few time lately.
>> 
>> I seems the biggest concern is backwards compatibility of the syntax.
>> I feel that should not stop us from fixing something that is an
>> annoying wart and also keeping the syntax in line with how other tags
>> work.
>> 
>> In this thread[2] Malcolm suggested introducing a new tag and
>> depreciating the old one which could be done by bringing something
>> like[3] into core. Im not huge on the idea of have 2 tags that do the
>> same thing only with slightly different syntax, but if that is the
>> cleanest upgrade I'm +1.
>> 
>> I think this can still be done in a backwards compatible way[4],
>> unless I'm missing something.
> 
> This isn't backwards compatible in every case. Consider:
> 
> {% url foo %}
> 
> foo could be:
> - A URL pattern name
> - A variable in the context
> - A variable in the context *and* a URL pattern name
> 
> It's the third case where your proposal has problems. Under the
> current implementation, it's *always* interpreted as a URL pattern
> name. Under your proposal, the context variable would take precedence
> in the third case.
> 
> It's also backwards incompatible in the second case (though not in a
> way that matters as much): if you have an existing template that
> raises an error, but you have a context variable that matches the name
> you've used, your implementation *won't* raise an error.
> 
> However, there is another way (an alternative to adding a parallel tag) :-)
> 
> An interesting quirk/feature of Django's template language: if you
> register template tags with the same name, the last registered name
> wins.
> 
> This means we can define a "future_url" template tag library that
> registers a {% url %} template tag. Then, in your code, you can say:
> 
> {% load future_url %}
> {% url "url-name" foo=bar %}
> 
> and get the new behavior. Then, we can put PendingDeprecationWarnings
> in the old {% url %} tag definition, upgraded to DeprecationWarnings
> in 1.4. Then, in 1.5, we switch the behavior over and start
> deprecating the future_url tag library.
> 
> I'm completely in favor of making this change; the behavior of the url
> tag has always been an annoying wart, and it would be good to clean it
> up.
> 
> Yours,
> Russ Magee %-)

Thanks for the feedback Russ. I know it couldn't be that straight forward. I'll 
work on a patch this week that
implements what you mentioned. Would it be best to start a new ticket or 
re-open the old ticket?

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

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

variable view name in url tag

[Sean Brant]

I know this has come up over the last few years[1] and people are
mixed on the action that should be taken. I would like to bring it up
again as it has bitten me a few time lately.

I seems the biggest concern is backwards compatibility of the syntax.
I feel that should not stop us from fixing something that is an
annoying wart and also keeping the syntax in line with how other tags
work.

In this thread[2] Malcolm suggested introducing a new tag and
depreciating the old one which could be done by bringing something
like[3] into core. Im not huge on the idea of have 2 tags that do the
same thing only with slightly different syntax, but if that is the
cleanest upgrade I'm +1.

I think this can still be done in a backwards compatible way[4],
unless I'm missing something.

I hope this doesn't turn into a shed planing session, thanks!

[1] http://code.djangoproject.com/ticket/7917
[2]
http://groups.google.com/group/django-developers/browse_thread/thread/ac2b1ea4555c0a62/21cf9b1aed6d11e0?lnk=gst=url+tag+viewname#21cf9b1aed6d11e0
[3] http://github.com/ulope/django-reversetag
[4] http://pastebin.com/FhZSFQdn

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

Re: Feature idea

[Sean O'Connor]

I've been generally thinking about putting together a package of reusable
tools to implement common "patterns" for reusable apps.  Included in this
would be this type of auto-discovery system as well as a registration
pattern.  Unfortunately I probably won't get much practical work done on
this too soon due to other obligations.

That being said I'd be very interested to see what initial stabs other
people may take in this direction or what other patterns would make sense
for this type of package.  Once a toolset of this nature does exist, I think
it'll be a great asset to reusable apps and even more so to the domain
specific frameworks like imagekit or haystack.

____
Sean O'Connor
http://seanoc.com


On Tue, Jun 1, 2010 at 3:34 PM, Gabriel Hurley <gab...@gmail.com> wrote:

> I like the idea of boxing up the autodiscover code into a publicly
> accessible utility class... it's a problem many people solve for
> themselves (myself included) but even moreso it would go well with the
> new startup.py proposal that's in the works.
>
> Once it's easy to have things run once at startup, the desire to run
> some sort of autodiscovery mechanism from those startup files is
> likely to take off. And it's not that it's a hard problem for someone
> to solve themselves, but it might be one worth solving once and being
> done with it.
>
> The downside, of course, is the cost of maintaining it and ensuring
> backwards compatibility going forward.
>
> All the best,
>
>- Gabriel
>
> On Jun 1, 12:02 pm, Gregor Müllegger <gre...@muellegger.de> wrote:
> > I also needed this functionality in one of my apps and just went the
> > way of copy and pasting the existing solution that is already
> > implemented in django.contrib.admin. But making this code reuseable
> > would IMO be a benefit for some app developers.
> >
> > But I think the approach of using an setting for this purpose is not
> > the ideal way. Admin does a great job in that way, because it only
> > uses the autodiscover functionality on demand. My need for an
> > autodiscover functionality was directly tight to a management command.
> > I don't want to load these modules unless I invoke the management
> > command, which is possible with the admin like autodiscover() function
> > instead of using a setting.
> >
> > My proposal would go into the direction of pulling the autodiscover
> > function out of the django.contrib.admin module and putting it
> > somewhere in the core. Since the admin needs some special
> > functionality on errors while loading an admin.py module from an app,
> > I would suggest a Autodiscover class that provides some hooks to be
> > better customizable.
> >
> > Something like:
> >
> > class Autodiscover(object):
> > def __init__(self, module_name):
> > self.module_name = module_name
> >
> > def __call__(self):
> > # existing autodiscover code from django.contrib.admin
> >
> > def pre_load(self, app_label):
> > # gets called directly before trying to load an app's module
> >
> > def post_load(self, app_label):
> > # gets called after trying to load an app's module even if
> the
> > # import failed
> >
> > def on_success(self, app_label, module):
> > # gets called if the module was imported successfully
> >
> > def on_error(self, app_label):
> > # gets called if the module didn't exist or import failed
> >
> > In django.contrib.admin or in any other app we can use:
> >
> > from django.core.autodiscover import Autodiscover
> >
> > autodiscover = Autodiscover('admin')
> >
> > This also provides backwards compatibility since the following snippet
> still
> > works:
> >
> > from django.contrib import admin
> >
> > admin.autodiscover()
> >
> > Yours,
> > Gregor Müllegger
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Process discussion: reboot

[Sean O'Connor]

The DVCS conversation has been had many times over the last year or two on
this list and in other places.  I mention this not to say that you should
know already as it isn't clearly documented, but as a suggestion that you
should make sure that you are bringing something new and concrete to the
discussion before starting it again.

The current view of the core team is that the combination of a central,
authoritative, Subversion server with semi-official mirrors for Git,
Mercurial, and Bazaar is sufficient for the foreseeable future.  All of the
benefits of the distributed systems are available via the mirrors and
there's no disruption to users who are used to the current
workflow/infrastructure.

If you would like to make a contribution to Django, you can work with
whichever of the three most common DVCSs and there will be several core devs
able to accept your changes without any problems.


Sean O'Connor
http://seanoc.com

P.S.  I am not a core dev so any of the core devs should feel free to
correct me on this. That being said this view has been clearly expressed
several times on this list and in other venues.


On Mon, Apr 19, 2010 at 8:35 PM, Jerome Leclanche <adys...@gmail.com> wrote:

> If you contribute to open source projects, at one point you'll be
> faced with the forced choice to use git. It is extremely popular (I
> believe it's the most popular after svn), and unlike svn it's popular
> for a good reason.
> However, hg is decent as well; whatever the django team chooses, as
> long as it's not cvs it can't really be worse than svn.
>
> (bzr fan, personally, but I'd prefer it if django moved over to git)
>
> J. Leclanche / Adys
>
>
>
> On Tue, Apr 20, 2010 at 2:58 AM, VernonCole <vernondc...@gmail.com> wrote:
> > Not to start a flame war --- but PLEASE! don't use git.  I already
> > have to use the other two leading DVCS's and all three are one too
> > many.
> > I personally prefer bazaar, but python itself and pywin32 are both
> > committed to mercurial.  I suspect that hg would be a better choice
> > for most people.
> > --
> > Vernon Cole
> >
> > On Apr 19, 10:05 am, Dennis Kaarsemaker <den...@kaarsemaker.net>
> > wrote:
> >> On ma, 2010-04-19 at 15:47 +, Peter Landry wrote:
> >>
> >>
> >>
> >>
> >>
> >> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" <ja...@jacobian.org> wrote:
> >>
> >> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry <plan...@provplan.org>
> wrote:
> >> > >> One suggestion that jumped out at me (which I admittedly know very
> little
> >> > >> history about with regards to Django or other projects) was the
> "trunk
> >> > >> ready" branch(es) [1]. Perhaps an effort to outline what that
> process might
> >> > >> entail in detail, to determine if it would address any concerns?
> >>
> >> > > FTR, I think this is a fine idea, and I think most (all?) of the
> other
> >> > > Django core developers do, too. It's just waiting on someone to Just
> >> > > Do It.
> >>
> >> > > Anyone -- preferably a group -- who wants to start such a branch
> could
> >> > > go ahead and start one using the DVCS tool of their choice (Django
> has
> >> > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me
> and
> >> > > I'll start watching it; show some continued motion and I'll spend
> some
> >> > > time getting a buildbot going against the branch; show high quality
> >> > > and I'll start pulling from it more and more frequently; show
> >> > > incredibly quality and I'll suggest that the maintainer(s) get
> commit.
> >>
> >> > >> For my part, I see that it could be helpful to let some
> patches/ideas get a
> >> > >> shot at integration without having to endure the (necessarily) more
> rigorous
> >> > >> core commit trails.
> >>
> >> > > Quality is important, and if this branch is created it needs to
> >> > > maintain that quality. If this hypothetical branch is low-quality
> it's
> >> > > just a different tool for a queue of un-reviewed patches, and I've
> >> > > already got one of those. I'm not willing to compromise on quality:
> if
> >> > > patches don't meet our standards, they don't go in.
> >>
> >> > > Jacob
> >>
> >> > I fully agree regarding quality, my point being that this branch
> itself may
> >> > not be "trunk r

logialogin_required does not check User.is_active

[Sean Brant]

A co-worker of mine noticed this bug today 
http://code.djangoproject.com/ticket/13125.
Should it be marked for 1.2 or punt it until after the release
candidate? It looks to be a bug so it could probably go in at anytime.
Let me know your thoughts.

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

Re: Django documentation for newer users

[Sean O'Connor]

The Django documentation is already included in code base with Django and
anybody is welcome to submit patches for them.  If you do a checkout of
Django, there will be a "docs" directory there.  Inside there is the full
documentation source in reStructuredText.  If you'd like a local HTML or PDF
version of the docs you can simply install sphinx[1] on your machine and
build the docs like any other sphinx project.

If your interested in learning more I'd recommend that you read the "How the
Django Documentation Works"[2] page as well as "Contributing to Django"[3].

____
Sean O'Connor
http://seanoc.com

[1] http://sphinx.pocoo.org/
<http://sphinx.pocoo.org/>[2]
http://docs.djangoproject.com/en/1.1/internals/documentation/#internals-documentation
<http://docs.djangoproject.com/en/1.1/internals/documentation/#internals-documentation>
[3]
http://docs.djangoproject.com/en/1.1/internals/contributing/#internals-contributing


On Fri, Mar 5, 2010 at 11:35 AM, stherrien <shawntherr...@gmail.com> wrote:

> What I'm suggesting is that we setup something to allow everyone to
> improve the docs with help from the core django group. I think this
> would be very helpful to everyone. if one of the core group would like
> to help us get setup to do this it would be great. maybe if they setup
> a repository with the current online docs online so we can add updates
> as we do with django itself.
>
> On Mar 5, 11:20 am, stherrien <shawntherr...@gmail.com> wrote:
> > Exactly my point docs need to be more organization to be constructive
> > for django users.
> >
> > On Mar 5, 11:05 am, Jared Forsyth <ja...@jaredforsyth.com> wrote:
> >
> > > To be honest I am quicker to just go to django's source code rather
> than the
> > > docs, as often I can find what I need there, and the docs aren't (imo)
> > > organized enough to provide much of an advantage.
> >
> > > On Fri, Mar 5, 2010 at 8:46 AM, stherrien <shawntherr...@gmail.com>
> wrote:
> > > > Hi all,
> >
> > > > I have a request that django documentation show the import locations
> > > > for classes like in other well formed docs found on the web showing
> > > > the users where the classes can be found for import. I think this
> > > > would be handy for newer users and experienced users finding
> something
> > > > new. Documentation on the site is different from page to page. Take
> > > > for instance the file object doc page in django doesn't tell the user
> > > > where this can be imported which requires you to dig into the python
> > > > help pages to try and find it. which is "from django.core.files.base
> > > > import File". it would be nice to show this consistently across the
> > > > site. I would be happy to help make this happen.
> >
> > > > -shawn
> >
> > > > --
> > > > You received this message because you are subscribed to the Google
> Groups
> > > > "Django developers" group.
> > > > To post to this group, send email to
> django-develop...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> <django-developers%2bunsubscr...@googlegroups.com<django-developers%252bunsubscr...@googlegroups.com>
> >
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Django's testing infrastructure

[Sean O'Connor]

A platform we probably should get into the mix is a CentOS/RHEL 5 box.  I
suspect a significant portion of the community is stuck on such boxes and
given the ancient versions of everything available under RHEL I'm sure that
there are things which will break there and not in a developer's standard
environment.

I personally don't have a suitable RHEL box laying around but this seems
like a good candidate for either another volunteer or DSF funds.


Sean O'Connor
http://seanoc.com


On Thu, Feb 25, 2010 at 10:54 PM, Eric Holscher <e...@ericholscher.com>wrote:

> Hey everyone,
>
> During the sprints, I worked to set up a hudson instance for Django. This
> is hopefully going to be the way that we are going to go forward for now
> with doing continuous integration for Django. I have a pretty good setup
> going currently, and want make it really fantastic. At this point in time,
> what we really need now is some more hardware to be able to run tests on.
>
> The current setup is hosted at: http://hudson.djangoproject.com/
>
> Currently, I have tests running on the following architectures:
>
> Django trunk:
>
> Solaris:
> Python 2.4-2.5
> Databases: sqlite, postgres, mysql
>
> Ubuntu:
> Python 2.5-2.6
> Databases: sqlite, postgres, mysql
>
> Django 1.1.X:
>
> Solaris:
> Python 2.5
> Databases: sqlite, postgres
>
> This gives us pretty good coverage currently, but the whole point of doing
> CI is that we catch bugs on other platforms we wouldn't normally run on.
>
> What we need
> ===
>
> So I'm looking for people who can offer other boxes that they would like to
> see tested. Currently the big ones we aren't covering are Windows boxes, and
> the Oracle backends. There are lots of other permutations that we could be
> testing against (Different python runtimes being a good example).
>
> However, we don't want to get in a situation where boxes that people have
> set up just disappear. So, I'm only currently looking for machines that
> people would be able to dedicate to the effort. We would require a
> django-testing user account on the box, with our SSH key on it. There would
> also be a team of trusted users, who would have access to this key and thus
> your machine.
>
> We want the build farm to be stable and useful, and in the past we have had
> too much trouble having machines just disappear.
>
> Requirements
> ===
>
> Currently the hudson requirements seem to be about <1GB of disk space, with
> 512MB of ram. I'm also looking into some pony build/barn based alternatives
> that would knock the memory requirements down pretty substantially. However,
> for the current 1.2 release it looks like hudson is how we're going to make
> it going forward.
>
> Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so
> another way that we might be able to get this going is to be able to have
> donations to the DSF, and have them get some dedicated rackspace boxes.
> However, for now, I'm hoping that we can cobble together enough stuff to get
> 1.2 tested really well.
>
> Feedback
> ==
>
> If you have any thoughts on CI, or any advice, I would love to hear it. I'm
> trying to make our Continuous Integration setup really kick ass, so feedback
> is necessary to do this. I have some notes and ideas that I have been
> recording while setting things up over at the pycon etherpad:
>
> http://pyconpads.net/django-testing
>
> Let me know if you have any thoughts, questions, or concerns.
>
> Cheers,
> Eric
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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

Re: Possible bug in messages framework?

[Sean Brant]

On Jan 22, 2010, at 7:04 PM, Luke Plant wrote:

> Well, it depends on what you call the 'spec'.  What spec says that 
> commas in values is invalid?
> 
> The 'spec' linked to on that WebKit bug is a preliminary Netscape 
> document, which, as far as I can tell, eventually turned into RFC 
> 2109, which surely has got to be regarded as more authoritative.  RFC 
> 2965 (which proposes Set-Cookie2) supposedly obsoletes RFC 2109, but I 
> don't know think it is really used much. [1]
> 
> As I noted on the bug [2], RFC 2109 allows values to be quoted, in 
> which case Django is behaving correctly, and it is some browsers that 
> are not.
> 
> Our implementation of this is in fact done entirely by Python's 
> standard library Cookie module [3]. It handles everything I can throw 
> at it (newlines, UTF8, throws exceptions with illegal cookie names 
> etc.).  It's kind of unlikely that we've found a bug in it.
> 
> Of course, it doesn't mean we shouldn't fix things to avoid this bug.  
> But to do so would require some kind of encoding, which is almost 
> certainly going to cause breakage of some kind with existing cookies.  
> Turbogears' solution would be backwards compatible in most cases, but 
> not all.
> 
> (BTW, if we implemented this change, the nicer way to do is to 
> subclass Cookie and override Cookie.value_encode() and value_decode(), 
> rather than the way that Turbogears does it)
> 
> Personally, I favour fixing our messages implementation so that it 
> isn't an issue (which is easy, it seems, see details on #12470), and 
> possibly just putting a note into our cookie documentation that some 
> old WebKit based browsers have a bug that means they do not correctly 
> handle a cookie value containing a comma followed by a space.
> 
> An argument in favour of this lazy approach is that this issue, for 
> both ourselves and Turbogears, has only ever come up in the context of 
> using cookies for messages.  Presumably that means that developers are 
> rarely storing extended human readable text strings in cookies outside 
> of this kind of usage, so outside of the messages app it is probably 
> not something we need to worry about.
> 
> Luke


Whats the downside of fixing this at the core cookie handling level? I agree 
with Luke and only ran across this bug when the new messaging framework 
dropped. However if we are going to fix the problem, and I do think it's a 
problem even if its a browser bug, should we just fix it at the core level and 
handle all cookies down the road? Would previously stored cookies that are not 
url quoted even fail when trying to unquote? Maybe I'm wrong but this seems 
pretty backwards compatible.

Sean

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

Re: Possible bug in messages framework?

[Sean Brant]

I wonder if this is related?
http://groups.google.com/group/django-developers/browse_thread/thread/5613e9a03d92c902/738a3b81e405dc78#738a3b81e405dc78

On Jan 21, 2010, at 10:55 PM, j...@jeffcroft.com wrote:

> After a little more playing around, I've discovered that this is not
> an issue if I use the session storage -- so it seems to be related to
> cookie storage.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

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

django.contrib.messages failing silently in safari when comma is used in message

[Sean Brant]

If you try and send a message with new messaging app that contains a
comma in the message it does not work in Safari.

I'm not really sure why the json encoded message is not working in the
Safari browser, but I fixed it by adding a base64 encode and decode
step that encodes/decodes the message string.

def _encode(self, messages, encode_empty=False):
...
if messages or encode_empty:
for message in messages:
message.message = base64.b64encode(message.message)
encoder = MessageEncoder(separators=(',', ':'))
...

def _decode(self, data):
...
messages = json.loads(value, cls=MessageDecoder)
for message in messages:
message.message = base64.b64decode
(message.message)
return messages
except ValueError:
pass
 ...

--

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

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Sean Brant]

The last thing that needs to happen is bulling this into core. It's no
good for the community and that could be part of the perceived
perceptions problem. Just because enough people bitch does not mean
that its a good thing. With that said the reason behind the ticket
being closed no longer seems valid.

A template filter for shortening a string seems like a logical
addition to truncatewords. At the very least reassessing the ticket
status might be a good start.

--

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

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Sean Brant]

On Dec 30, 2009, at 6:06 AM, Russell Keith-Magee wrote:
> Firstly, as James points out, slice already exists, and the ellipsis
> difference between slice and truncate can be easily overcome with
> additional code.

In the past I have had the need for a filter that works not just on the end of 
the string but sometimes in the middle. For example truncating a long filename, 
you might want to show the first bit and the last it.

myfilewithasuperlong...thisnameisreallylong.jpg

Doing this in the template is not a good idea, but with a template filter you 
can do it with an extra argument.

+1

--

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

Re: Possible bug with multi-db changes

[Sean Brant]

> Thanks for the report. I'll try and take a look at this today and work
> out what is going on. In the meantime - if you could open this as a
> ticket, I'd be much obliged.

Russ

I created a ticket for you http://code.djangoproject.com/ticket/12453.

Thanks for looking into this.
- Sean

--

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

Possible bug with multi-db changes

[Sean Brant]

I just upgraded to the latest trunk today and the admin now throws an
exception http://dpaste.com/138130/ when I try and save to a
ImageField. I messed with it a bit to make sure that it was not
something else in my code that could be causing the error. It looks
like the error only occurs when I have inlines defined on my
ModelAdmin and I try and save an image. He is the simplest thing that
fails for me. I only tested this on sqlite.

# admin.py
from django.contrib import admin
from django.contrib.auth.models import User

from models import Account, Membership

class MembershipInline(admin.TabularInline):
model = Membership

class AccountAdmin(admin.ModelAdmin):
model = Account
inlines = [
MembershipInline,
]

admin.site.register(Account, AccountAdmin)


# models.py
from django.contrib.auth.models import User
from django.db import models

class Account(models.Model):
name = models.CharField(max_length=100)
logo = models.ImageField(upload_to='logo')
users = models.ManyToManyField(User, through='Membership')

class Membership(models.Model):
user = models.ForeignKey(User)
account = models.ForeignKey(Account)

--

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

Re: Last call: #11863 (Model.objects.raw)

[Sean O'Connor]

Nice work Russ!  Got to love when something goes from "nice to have" to
"done".

Anssi, I don't think I understand your use case.  Even if an unmanaged model
doesn't have a literal table behind it, it needs something which at least
resembles a table (i.e. a view) to query against.  Otherwise the ORM will
generate errors regardless of the behavior of .raw().

To answer your question, raw() determines what fields are populated by the
names of the columns returned by the database cursor.  Accordingly, if you
want to pull different fields using different queries, you probably do so
using subqueries in one big SQL statement.  As long as the field names
returned by the query match the field names in the model or you provide a
translations parameter to describe which query fields go to which model
fields it should work.

As far as allowing users to define raw queries for each field to allow them
to be deferred, this is way outside the scope of this patch.  The goal of
.raw() was to provide some relatively simple syntactic sugar to make a
common class of raw queries easier.  It was not intended to completely
replace all possible use cases for doing raw queries using a cursor.

____
Sean O'Connor
http://seanoc.com


On Wed, Dec 16, 2009 at 9:19 AM, Anssi Kaariainen <akaar...@cc.hut.fi>wrote:

>
>
> On Dec 16, 2:51 pm, Russell Keith-Magee <freakboy3...@gmail.com>
> wrote:
> > On Wed, Dec 16, 2009 at 7:56 PM, Jeremy Dunck <jdu...@gmail.com> wrote:
> > > On Dec 15, 2009, at 11:16 PM, "Sean O'Connor"
> > > <sean.b.ocon...@gmail.com> wrote:
> >
> > >> In regard to the deferred fields option, I'll let Jacob speak for
> > >> his view but I've approached such functionality as "nice to have"
> > >> for the patch since its not critical to the patch being useful.
> > >> Personally I haven't had the time to figure it out and implement it
> > >> so my original patch didn't include it.
> >
> > > I like the idea of the deferred fields, but if we don't implement it
> > > now, people may come to rely on the AttributeError so that we can't
> > > add deferred later. Perhaps a note in the docs stating our intent to
> > > add deferreds would suffice?
> >
> > No need for workaround docs - I've just uploaded an RC3 patch that
> > implements deferred fields.
> >
> > The one gotcha on this patch is that it now requires that you request
> > the primary key when you retrieve an object. That is, you can't just
> > run::
> >
> > Author.objects.raw('SELECT firstname, lastname FROM author')
> >
> > You must now include the pk:
> >
> > Author.objects.raw('SELECT id, firstname, lastname FROM author')
> >
> > If you don't, you get an exception. Unfortunately, it's an exception
> > after the SQL has been executed, but that's the only way to know
> > exactly which columns have been requested.
> >
> > This is slightly more restrictive than Jacob's RC2 patch - but I think
> > the RC3 behaviour is preferable. The primary key value is a fairly
> > essential part of the Django infrastructure. In RC2, if you retrieved
> > an Author with firstname and lastname, then saved the object, you
> > would get a new object in the database. RC3 avoids this because the
> > deferred object has the right primary key.
> >
> > If the price of avoiding surprises like this is forcing the PK to be
> > retrieved, I think it's a price worth paying. If you really can't
> > afford to have the PK retrieved, then I'd argue you aren't retrieving
> > a Django object; you can still call on raw SQL cursors to accommodate
> > those use cases.
>
> One use case where deferred fields aren't so nice is when creating
> models which don't have any backing tables in the db. That is, models
> with managed = False. These models would be the Django equivalent of
> views. In these cases trying to access the field, even for testing if
> it is None, would result in db query and an exception. And probably in
> aborted transaction, too.
>
> Using raw() as a way to perform view operations (complex joins etc.)
> is the first use case I though of when I saw this. Anyways, using
> default or None as a value isn't good either. How do you know if you
> got that from the DB or not? A nice way to test which fields the model
> were populated and marking the non-populated fields as deferred would
> be optimal in my opinion. One use case where you don't necessary know
> which fields are populated and which ones aren't is when you have
> multiple raw() queries defined populating different fields of the
> model.
>
> Anssi Kaariainen
>
> --
>

Re: Last call: #11863 (Model.objects.raw)

[Sean O'Connor]

Big thanks Jacob for picking up my slack and putting the finishing touches
on the patch and writing the docs.  Work got crazy and I dropped the ball.
 Definitely happy that the work will get completed and put into trunk
regardless.

In regard to the deferred fields option, I'll let Jacob speak for his view
but I've approached such functionality as "nice to have" for the patch since
its not critical to the patch being useful.  Personally I haven't had the
time to figure it out and implement it so my original patch didn't include
it.

For the multidb approach I'd lean towards the kwargs approach.  Right now
the .raw() code is fairly well insulated from the bulk of the ORM and visa
versa.  This keeps the raw() code pretty simple and minimizes the
opportunities for introducing new bugs in the ORM.

As far as putting raw() on querysets I'd be pretty against it as well.  It
strikes me in a lot of ways as mutli-table inheritance does.  People are
really going to want it, until they try and use it in the real world, and
realize that it was a really bad idea.  While I'm sure Russ or some others
around here could work some awesome magic and get it working after a
fashion, I don't think it will ever work the way a new user will expect.
 What does performing a raw query on a queryset even mean?  In the end I
think adding .raw() to queryset would lead to a much more complicated
implementation and more confusion for users.

____
Sean O'Connor
http://seanoc.com


On Tue, Dec 15, 2009 at 8:24 PM, Russell Keith-Magee <freakboy3...@gmail.com
> wrote:

> On Wed, Dec 16, 2009 at 6:15 AM, Jacob Kaplan-Moss <ja...@jacobian.org>
> wrote:
> > Hey folks --
> >
> > Forgot to mention it during the sprint this weekend, but I've pushed a
> > RC patch to #11863, Model.objects.raw(). If anyone's got any feedback,
> > let it fly. Otherwise, I'll be checking this in in a couple-three days
> > or so.
>
> Hi Jacob,
>
> A couple of quick notes on the RC2 patch:
>
>  * If you have an incomplete selection of fields, the patch currently
> marks those fields as None/default values. Couldn't (Shouldn't?) they
> be marked as deferred fields?
>
>  * Looking slightly forward - what's the integration point for
> multidb? One option is to put a using argument on raw::
>
>  Person.objects.raw('SELECT ...", using='other')
>
> It would be nice to allow .using(), but while it is easy to allow::
>
>  Person.objects.raw('SELECT ...").using('other')
>
> it isn't so easy to allow::
>
>  Person.objects.using('other').raw('SELECT ...")
>
> We could jump through some hoops to put raw() on queryset, but raise
> exceptions under most uses (i.e., if you've performed any query
> modifying operation). However, this is a lot of hoops just to allow an
> edge case API use.
>
> Obviously, multidb isn't in scope for this patch, but given the
> obvious overlap, I thought I'd ask for opinions.
>
> Other than that, RC2 looks good to me.
>
> Russ %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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

Re: Running unit tests when you can't create a new database

[Sean Brant]

This might help you out
http://ericholscher.com/projects/django-test-utils/keep_database_runner.html.
Or at least give you some pointers.

- Sean

On Wed, Dec 9, 2009 at 2:16 PM, Martin Omander <martin.oman...@gmail.com> wrote:
> Russ,
>
> The method you describe sounds like the preferred way. It's cleaner to
> add a new test runner module than to modify existing Django code. I
> really like it.
>
> But as you say, it's not obvious how to do this. I'd like to do a
> write-up of how this is done, for the common use case where you don't
> have database creation privileges.
>
> Before I dig in and try to figure this out by myself, has anyone out
> there written a test runner you could share with me?
>
> /Martin
>
>
>
> On Dec 9, 4:50 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
>> On Wed, Dec 9, 2009 at 7:22 PM,  <reg...@messir.net> wrote:
>> >> Django allows you to define a custom test runner. Copy
>> >> django.tests.simple.run_tests() into your own code, removing the calls
>> >> to create and destroy the test database. Then set TEST_RUNNER in your
>> >> settings file to point at the new runner.
>> > Hello!
>> > I see many similar bugreports and wishes which was closed with this
>> > proposal.
>>
>> > Unfortunately this will not work with recent django versions.
>> > Errors like AttributeError: 'Settings' object has no attribute
>> > 'DATABASE_SUPPORTS_TRANSACTIONS'
>>
>> Ok - I oversimplified slightly. You can't just delete the call to
>> create the test database. You need to replicate some of the logic that
>> the backend that establishes the extent of transaction support on your
>> database of choice.
>>
>> My point still stands - Django ships with an ability to control and
>> customize the testing process. You just need to pick the
>> customizations that are required by your particular deployment
>> scenario.
>>
>> Yours,
>> Russ Magee %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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

Re: Django needs for normal sequence of handlers for request processing

[Sean Brant]

Oh, forgot there are also signals that might help.
http://docs.djangoproject.com/en/dev/ref/signals/#module-django.core.signals

:)

--

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

Re: Django needs for normal sequence of handlers for request processing

[Sean Brant]

Not sure if this would solve the problem, but have a look at
django.utils.ddecorators.decorator_from_middleware.

"""
Given a middleware class (not an instance), returns a view decorator. This
lets you use middleware functionality on a per-view basis.
"""

This also might be best discussed on django-users for now.

--

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

template or is it template_name

[Sean Brant]

Stop me if you have heard this one before. Anyone else find it
annoying that direct_to_template takes the kwarg "template" and most
other generic views take "template_name". Smells a little like php to
me.

Is this something that should be / can be fixed?

Sean

--~--~-~--~~~---~--~~
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: Regularly-scheduled Django sprints, first December 11 - 13

[Sean Brant]

> Sure that'd be great, I guess we don't really need to start planning
> until it gets a little closer, but if we want to have any discussions
> about the local things let's try to revive the django-chicago mailing
> list :)
>
> Alex

Yeah, I agree. If you need admin access to that list I think Tom can
help with that.

Sean

--~--~-~--~~~---~--~~
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: Regularly-scheduled Django sprints, first December 11 - 13

[Sean Brant]

Alex, I can help you out in Chicago if you need it.

Sean

--~--~-~--~~~---~--~~
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: CSRF changes - backwards incompatible

[Sean Brant]

Interesting note. A co-worker of my has been working with the poll
tutorial for a couple days now and just got to part 3 which now
contains the {% csrf_token %} tag. He could not figure out how why he
was getting an error that the csrf_token tag could not be loaded.

I'm not sure how wide spread this will become, but I think for new
users it could be a problem. When asked what version of the doc he was
using he replied the one for trunk. He is running trunk but he did not
svn up for a few days hence his trunk falling behind.

Im not sure the best way to combat this problem, it was easily spotted
by me but only because I follow this list. Maybe the problem is people
that are learning should not be learning on trunk, which probably goes
without saying.

Anyways just thought I'd drop a real life user story seeing how this
feature just landed.

- Sean

--~--~-~--~~~---~--~~
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: shortcut proposal

[Sean Brant]

>
I agree with Russ that why I hinted this might be better left for  
domain code. In my decorator I do check for an instance of  
HttpResponse and pass that thru unchanged. So of you want to return a  
HttpResponseRedirect inside if a if statment it will still work. My  
only problem is the boiler plate code required to check accept headers  
and returning the correct response format. Say you want to create an  
API were the same view function returns multiple response formats. I'm  
cool with anything that make it so we don't have use RequestContext it  
seems like doing so is always the defualt anyways

If anyone is interested I can produce sample code.
>

--~--~-~--~~~---~--~~
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: shortcut proposal

[Sean Brant]

Using a decorator allows you to do cool things like

@provides_html('myapp/mypage.html')
@provides_json(optional_serialize_callback_can_go_here)
def my_view(request):
return {'foo': 'bar')

Then your provides_* could check the accept-header and know how to
response. Html renders a template and json would serialize the dict.

With that said this probably falls into the domain specific use case
and is probably not needed by enough people to be added to core,
however doing ajax apps are a breeze.

sean

--~--~-~--~~~---~--~~
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: Patch: adding a msg parameter to assertContains and similar methods in the test client

[Sean Bleier]

>
>
> > def assertFormError(self, response, form, field, errors, msg=None):
> >...
> >self.fail(msg or "The field '%s' on form '%s' in context %d"
> >  " contains no errors" % (field, form, i))
>
> would become:
>
> prefix = msg and "%s: " % msg or ""
> self.fail("%sThe field '%s' on form '%s' in context %d"
>  " contains no errors" % (prefix, field, form, i))
>
> This preserves the best of both worlds - a rich failure message, plus
> the ability to add user-specific context to help identify the source
> of the problem in the test suite. This does differ from the behavior
> of the assert* functions in the standard library, but hopefully in a
> way that makes sense under the circumstances. Opinions?
>
> Yours,
> Russ Magee %-)
>
>
I like Russ's prefix idea.  I believe Christian's concern is that the
django's error messages do not give enough context for the programmer when
debuging.  Adding the prefix allows programmers to add that context without
blindly overridding the error message that django throws.

Karen is right about the name of msg if it is going to serve as a prefix to
the msg given to Python's assert* methods.  Something like msg_prefix or
prefix would be more appropriate IMO

Using Christian's example, I might change it to:

class TemplateTestCase(ClientTestCase):
   def testTemplateError(self):
   urls = [
   '/',
   '/home/',
   '/admin/',
   # etcetera ...
   ]
   for url in urls:
   response = self.client.get(url, follow=True)
   self.assertNotContains(
   response,
   settings.TEMPLATE_STRING_IF_INVALID,
   msg_prefix='Error in url %s' % url)

This way for the two cases in which assertNotContains can fail, you can have
errors messages like:
"Error in url /home/: Couldn't retrieve page: Response code was 404
(expected 200)"
or
"Error in url /home/: Response should not contain
'TEMPLATE_STRING_IF_INVALID"

--Sean

--~--~-~--~~~---~--~~
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: Proposal: Tutorial Refresh

[Sean Brant]

+1 Simon's idea of a conference site. Adding some features like
http://hello.carsonified.com/ would be cool to have, though it might
be to advance for this kind of tutorial.

Sean

--~--~-~--~~~---~--~~
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: Model.objects.raw() (#11863)

[Sean O'Connor]

To be honest this seems like something which would be a lot of work with
relatively little gain.  For this to work raw() would need to change from a
relatively simple bit of code which doesn't need to touch all of the complex
query code in the ORM to a complex bit of code which needs to deeply modify
the behavior of the query code.
For most use-cases where you simply wish to inject bits of SQL into the
query, the existing extra() method works well.  Otherwise you've probably
already written the query you want to use.  To use "advanced extra" type
tools you'd have to do additional work to break down your new query into
something that fits into these functions.  With a simple raw all one would
need to do is plug their query into the raw() method.
In addition to making raw() much more complicated, this proposal eliminates
or dramatically complicates the possibility of implementing raw() for
non-relational back-ends.

If somebody really wants this functionality and can provide an
implementation it could certainly be looked at more deeply.  Otherwise IMHO
this would not be a good thing to add to raw() and have little interest in
implementing it.

____
Sean O'Connor
http://seanoc.com


On Fri, Oct 2, 2009 at 7:35 AM, mrts <mrts.py...@gmail.com> wrote:

>
> Wishful thinking follows.
>
> It would be awesome if one could mix ordinary QuerySet methods
> with raw() (or, rather, raw_extra(), see below for that).
>
> Assuming the following models:
>
> class Foo(models.Model):
>name = models.CharField(max_length=255)
>
> class FooDates(models.Model):
>foo = models.ForeignKey(Foo)
>start = models.DateField()
>end = models.DateField()
>
> I for one would be definitely struck with awe if
> I could write something in the lines of:
>
> RAW_ORDER_BY = """
> ORDER BY (SELECT MIN("start")
>FROM "myapp_foodates"
>WHERE "myapp_foodates"."start" >= %s
>AND "myapp_foo.id" = "myapp_foodates"."foo_id")
> """
>
> q = Foo.objects.filter(
>foodate__end__gte=datetime.date.now())\
>.raw(RAW_ORDER_BY, params=(datetime.date.now(),))\
>.distinct()
>
> and q.query.as_sql() would look as follows:
>
> SELECT DISTINCT ...
>  FROM "myapp_foo"
>  INNER JOIN "myapp_foodates"
>  ON ("myapp_foo"."id" = "myapp_foodates"."foo_id")
>  WHERE "myapp_foodates"."end" >= "2009-10-02"
>  ORDER BY (
>   SELECT MIN("start")
> FROM "myapp_foodates"
> WHERE "myapp_foodates"."start" >= "2009-10-02"
>   AND "myapp_foo"."id" = "myapp_foodates"."foo_id");
>
> However, I assume that achieving this would be extremely
> hard with plain raw().
>
> What probably would work, however, is an extra()-like
> raw_extra() that would accept raw parametrized strings
> for each of `select`, `where` and `order_by` and plainly
> replace the corresponding part in the query builder.
>
> I.e. the example above would read:
>
> q = Foo.objects.filter(
>foodate__end__gte=datetime.date.now())\
>.raw_extra(order_by=RAW_ORDER_BY,
>params=(datetime.date.now(),))\
>.distinct()
>
> Best,
> Mart Sõmermaa
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

set_urlconf/get_urlconf patch

[Sean Brant]

I have updated the patch on this ticket (http://code.djangoproject.com/
ticket/5034) that SmileyChris wrote a while back. I ensured that the
new patch works against rev:11590.

In talking to SmileyChris about this on the IRC channels he noticed
that not clearing the _urlconfs dict after each request could cause a
memory leak. I added a finally statement in
handlers.base.BaseHandler.get_response which will ensure that urlconf
gets reset after each requets/response.

I'm not sure what to do from here, it would be nice if some of the
core could chime in on this. It doesn't change to much with how stuff
works currently. Although we would probably have to take the warning
out until 1.3.

--~--~-~--~~~---~--~~
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: Should TransactionTestCase flush db in teardown rather than setup?

[Sean Legassick]

On 15 Apr 2009, at 22:25, Karen Tracey wrote:
>> So am I missing something or should this be changed?
>
> TestCase testcases should not be running after TransactionTestCase  
> testcases.  I had this concern prior to checking in the test changes  
> (see 
> http://groups.google.com/group/django-developers/browse_thread/thread/1e4f4c840b180895/)
>  
>  and (thought) I addressed it by adding code to reorder the test  
> suite after all the tests are discovered so that all TestCase  
> testcases (which assume a clean DB on entry and ensure one on exit)  
> are run first.  It's even documented 
> (http://docs.djangoproject.com/en/dev/topics/testing/#django.test.TransactionTestCase
>  
> ) since the reordering revealed a few testcase-order dependent bugs  
> in the Django test suite so might also cause hiccups for people with  
> their own suites when upgrading to 1.1.

Ah, so that's what I was missing. That does ring a bell now you  
mention it, I was reading some of your discussion of this at the time.

> Are you actually seeing TestCases run after TransactionTestCases?

I am seeing this, however I am using the GIS test runner which doesn't  
have the reordering code.
So the correct solution instead of what I suggested is for me to work  
up a patch for the GIS test runner that uses your reordering code.

Thanks,
Sean

(PS I've hit another issue with the new-style TestCase to do with  
using the transaction decorators, but I'm more confident that I know  
what's going on with that so I'm preparing a ticket about it with a  
patch right now).

-- 
Sean Legassick
sean.legass...@gmail.com




--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Should TransactionTestCase flush db in teardown rather than setup?

[Sean Legassick]

(I'm posting this here rather than filing a ticket, because I'm not  
sure whether I'm missing something. If I'm not than I will file a  
ticket with a patch).

It strikes me that TransactionTestCase should be flushing the database  
in the teardown stage of the test case rather than the setup. My  
thinking is that when using a mixture of TestCase and  
TransactionTestCase (where the latter is only used when testing  
transaction-related behaviour) what's important is that the test db is  
left in the 'clean' state at the end of the test. Otherwise subsequent  
TestCase tests will be operating on a test db with any modifications  
made by the TransactionTestCase test still in place, and thus  
potentially failing.

So am I missing something or should this be changed?

Sean

-- 
Sean Legassick
sean.legass...@gmail.com


--~--~-~--~~~---~--~~
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: Proposal: user-friendly API for multi-database support

[Sean Stoops]

I just wanted to toss out one more use case that I know I would find
especially useful.  Legacy databases.

I'd like to see the ability to setup a model (using rough
introspection and then user tweaking) based on a legacy database,
maybe with the options of read-write or read-only access.

Like Robert, I'll have to give this another read through tomorrow
after a little sleep.

-Sean

On Sep 10, 5:27 pm, Robert Lofthouse <[EMAIL PROTECTED]> wrote:
> Wow, i'm with Malcolm on the "steady on, let's take this a bit at a
> time" :) Someone has been working hard, but that's a huge amount to
> think about.
>
> Reading through some of the comments: Most of the functionality
> described here would be an explicit mapping and choice made by the
> developer, it would be pretty hard to use any form of magic. I'm all
> for the setting up of bindings in a settings.py, which you later
> access and pass through whenever you do a select/update/delete. I'm
> also for per-model connections/connection overrides, with an option to
> override on a more general level at the (overseeing) application
> level.
>
> I'm against the idea of having functions in settings.py, but I don't
> see why they can't be discovered based on definitions in the settings
> file.
>
> Will have a proper read through tomorrow, as this thread is
> interesting.
>
> On Sep 10, 6:53 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> > For those who weren't at DjangoCon, here's the state of play with
> > regards to multi-db support: Django actually supports multiple
> > database connections right now: the Query class (in django/db/models/
> > sql/query.py) accepts a connection argument to its constructor, and
> > the QuerySet class (django/db/models/query.py) can be passed an
> > optional Query instance - if you don't pass it one, it will create a
> > Query that uses the default django.db.connection.
>
> > As a result, if you want to talk to a different connection you can do
> > it right now using a custom manager:
>
> > class MyManager(Manager):
>
> >     def get_query_set(self):
> >         query = sql.Query(self.model, my_custom_db_connection)
> >         return QuerySet(self.model, query)
>
> > As Malcolm described it, he's provided the plumbing, now we need to
> > provide the porcelain in the form of a powerful, user-friendly API to
> > this stuff. Here's my first attempt at an API design.
>
> > Requirements
> > 
>
> > There are a number of important use-cases for multi-db support:
>
> > * Simple master-slave replication: SELECT queries are distributed
> >   between slaves, while UPDATE and DELETE statements are sent to
> >   the master.
> > * Different Django applications live on different databases, e.g.
> >   a forum on one database while blog lives on another.
> > * Moving data between different databases - it would be useful if
> >   you could do this using the ORM to help paper over the
> >   differences in SQL syntax.
> > * Sharding: data in a single Django model is distributed across
> >   multiple databases depending on some kind of heuristic (e.g. by
> >   user ID, or with archived content moved to a different server)
> > * Replication tricks, for example if you use MySQL's InnoDB for
> >   your data but replicate to a MyISAM server somewhere so you can
> >   use MySQL full-text indexing to search (Flickr used to do this).
>
> > I've probably missed some; please feel free to fill in the gaps.
>
> > We don't need to solve every problem, but we do need to provide
> > obvious hooks for how those problems should be solved. Sharding, for
> > example, is extremely application specific. I don't think Django
> > should automatically shard your data for you if you specify 'sharding
> > = True' on a model class, but it should provide documented hooks for
> > making a custom decision on which database connection should be used
> > for a query that allow sharding to be implemented without too much
> > pain.
>
> > Different applications on different databases on the other hand is
> > something Django should support out of the box. Likewise, master-slave
> > replication is common enough that it would be good to solve it with as
> > few lines of user-written code as possible (it's the first step most
> > people take to scale their database after adding caching - and it's a
> > sweet spot for the kind of read-heavy content sites that Django is
> > particularly suited for).
>
> > Proposed API
> > 
>
> > Here's my first attempt at describing a user-facing API.
>
> > First, we need a way of 

Re: Altering data uploaded to FileField before save is called

[Sean Legassick]

On 10 Sep 2008, at 15:38, Brian Rosner wrote:
>> I think that the commit=False (or save=False in FieldFile.save() )
>> should not do the save to the storage backend.
>
> Agreed. I have been considering treating FileFields the same as
> many-to-many fields when commit=False in a ModelForm. In the event
> that commit=False a new method is available to perform the file saving
> explicitly. This would help in the event of wanting to name the file
> the same as the primary key for instance.

Looking at the code, the issue I see with this is at the moment there  
is a mechanism for the storage backend to alter the filename when  
saving. If the save was performed separately after the DB update then  
a second DB update would be required to store the amended name.

The default FileSystemStorage uses the name change mechanism to avoid  
race conditions over conflicting names. It may be that this can be  
considered unusual enough that a second DB update in this situation is  
acceptable, although a mechanism for this would need to be included.  
Anyway I just wanted to flag this potential issue to help with  
thinking this through.

Sean


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: {% doctype %} and {% field %} tag for outputting form widgets as HTML or XHTML

[Sean Legassick]

On 10 Sep 2008, at 09:49, Simon Willison wrote:
> I think we should maintain a list of doctypes - there really aren't
> that many: xhtml1, xhtml1trans, xhtml1frameset, html4, html4trans,
> html4frameset, xhtml11 and html5 should cover everything.

There's also xhtml-mp, wml and chtml for mobile apps...

> The current design of the {% doctype %} tag supports setting your own
> custom doctype using the "silent" argument. You need to pick a
> supported doctype that is closest to your own, then supress output
> with "silent" and add your own instead:

...which can always be handled by this mechanism if not directly  
supported.

-- 
Sean L


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The last push to 1.0

[Sean]

We are *NOW* in complete and total feature freeze?

Regards


On Aug 27, 9:41 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> "We're not in complete and total feature freeze. "
>
> I assume you mean the opposite of this.
>
> On Aug 27, 9:15 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
> wrote:
>
> > Hi folks --
>
> > Right, so this is it.
>
> > We've got about a week until the scheduled release of Django 1.0, and
> > the milestone shows 86 open tickets. It's time to put our heads down
> > and get this release out. A few notes:
>
> > We're not in complete and total feature freeze. This means that the
> > only things we should be working on for the next week are fixing true,
> > verified bugs. This also means that if you report a feature request,
> > it'll get automatically pushed to post-1.0 regardless of the merits.
>
> > We're also in string freeze so that translators have the next week to
> > get their translations as complete as possible. Any string marked for
> > translation cannot be changed. This means that if you're working on a
> > patch that touches translated strings, we'll ask you to write around
> > them.
>
> > Don't expect to see much activity from the core developers on the
> > community lists and channels. If there's something that needs
> > attention from one of us, make a note and repost in about two weeks if
> > we've not gotten back to you by then. I, at least, am going to pretty
> > much ignore the mailing lists for the next weekish while we get this
> > release out.
>
> > Finally, keep in mind that although "1.0" seems huge -- mostly since
> > we've been working on it for so long -- it's only the *first* of what
> > I expect to be an increasingly awesome set of releases. 1.0 will be
> > missing quite a few things we've had to put off, but 1.1 will be even
> > better, and 1.2 will kick the crap out of 1.1.
>
> > So let's do the best we can, but remember that it'll only get better from 
> > here!
>
> > 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The last push to 1.0

[Sean]

pls forgive me. didn't see Jacob's reply. was replying to alex.gaynor.
the exact phrasing was a coincidance, though.. lol

On Aug 27, 10:51 pm, Sean <[EMAIL PROTECTED]> wrote:
> We are *NOW* in complete and total feature freeze?
>
> Regards
>
> On Aug 27, 9:41 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
> > "We're not in complete and total feature freeze. "
>
> > I assume you mean the opposite of this.
>
> > On Aug 27, 9:15 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
> > wrote:
>
> > > Hi folks --
>
> > > Right, so this is it.
>
> > > We've got about a week until the scheduled release of Django 1.0, and
> > > the milestone shows 86 open tickets. It's time to put our heads down
> > > and get this release out. A few notes:
>
> > > We're not in complete and total feature freeze. This means that the
> > > only things we should be working on for the next week are fixing true,
> > > verified bugs. This also means that if you report a feature request,
> > > it'll get automatically pushed to post-1.0 regardless of the merits.
>
> > > We're also in string freeze so that translators have the next week to
> > > get their translations as complete as possible. Any string marked for
> > > translation cannot be changed. This means that if you're working on a
> > > patch that touches translated strings, we'll ask you to write around
> > > them.
>
> > > Don't expect to see much activity from the core developers on the
> > > community lists and channels. If there's something that needs
> > > attention from one of us, make a note and repost in about two weeks if
> > > we've not gotten back to you by then. I, at least, am going to pretty
> > > much ignore the mailing lists for the next weekish while we get this
> > > release out.
>
> > > Finally, keep in mind that although "1.0" seems huge -- mostly since
> > > we've been working on it for so long -- it's only the *first* of what
> > > I expect to be an increasingly awesome set of releases. 1.0 will be
> > > missing quite a few things we've had to put off, but 1.1 will be even
> > > better, and 1.2 will kick the crap out of 1.1.
>
> > > So let's do the best we can, but remember that it'll only get better from 
> > > here!
>
> > > 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: models.TimeField has no to_python method

[Sean Legassick]

On 22 Jul 2008, at 15:01, Leo Soto M. wrote:

> I'm not going to pretend that I know why there is not
> TimeField.to_python. But some changes on #7560 needed it, so it is
> implemented on its attached patch.

Ah yes, so it is.

Anything I can do to help? (I do a lot of development with the gis  
branch and PostGIS so I can try out the patch there and see what  
happens).

-- 
Sean Legassick
[EMAIL PROTECTED]




--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSOC: More backends for djangosearch

[Gabriel Sean Farrell]

On Thu, Jun 19, 2008 at 10:47:36PM +0100, Ben Firshman wrote:
> Not that I just want to copy other projects, but it'd would be nice to  
> bring together all the best features of all the Django search  
> solutions that already exist. It would be ideal if the developers of  
> all these projects (django-sphinx in particular seems the most mature)  
> would be willing to assist with djangosearch. With their expertise on  
> their search backends, we can make it contrib worthy.

As a developer on a Django/Solr project [0], I'm keen on the
possibilities for integrating search engines with Django.  A couple of
questions:

1. You mention integration with Lucene.  Do you mean to do this via Solr
or PyLucene?

2. What's the relationship between django-search [1] and djangosearch [2]?
Seems like some collaboration/combination could happen there.

[0] http://code.google.com/p/fac-back-opac/
[1] http://code.google.com/p/django-search/
[2] http://code.google.com/p/djangosearch/ 

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Response to "Shortcutting render_to_response"

[Gabriel Sean Farrell]

In response to http://fi.am/entry/shortcutting-render_to_response/ --
posting it here rather than some little comment box.

PART 1: A Bold Diff
---
In regard to the clumsiness of render_to_response and RequestContext,
I too like the solution at http://www.djangosnippets.org/snippets/3/,
and even though the comments there mention its similarity to
direct_to_template, I'd rather avoid abusing a function by ignoring
its name and exercising largely undocumented functionality.  After
all, my params aren't going directly to the template.

That use of direct_to_template smells a little like the and/or ternary
operator mischief that went on before Python 2.5, and I think the
proper thing to do would be to make what people want to do most of the
time (i.e. send variables to a template with RequestContext) the
shortest and easiest thing to do.  I'd follow Paul Bowsher's lead [1],
but take it further:

Index: django/shortcuts/__init__.py
===
--- django/shortcuts/__init__.py(revision 7612)
+++ django/shortcuts/__init__.py(working copy)
@@ -8,15 +8,26 @@
 from django.http import HttpResponse, Http404
 from django.db.models.manager import Manager
 from django.db.models.query import QuerySet
+from django.template.context import RequestContext

-def render_to_response(*args, **kwargs):
+def render_response(request, *args, **kwargs):
 """
-Returns a HttpResponse whose content is filled with the
result of calling
-django.template.loader.render_to_string() with the passed arguments.
+Returns a HttpResponse filled with the result of
render_to_string called
+with passed arguments and the RequestContext as the context_instance.
 """
+kwargs['context_instance'] = RequestContext(request)
 httpresponse_kwargs = {'mimetype': kwargs.pop('mimetype', None)}
 return HttpResponse(loader.render_to_string(*args, **kwargs),
**httpresponse_kwargs)

+def render_response_without_request(*args, **kwargs):
+"""
+Returns a HttpResponse filled with the result of
render_to_string called
+with passed arguments.
+"""
+httpresponse_kwargs = {'mimetype': kwargs.pop('mimetype', None)}
+return HttpResponse(loader.render_to_string(*args, **kwargs),
**httpresponse_kwargs)
+render_to_response = render_response_without_request # For
backwards compatibility.
+
 def _get_queryset(klass):
 """
 Returns a QuerySet from a Model, Manager, or QuerySet. Created to make

render_response_without_request is maybe too long and tortured (not
much of a shortcut at that length), but I think it gives the
RequestContextless response the secondary status it has long deserved.

PART 2: In Which I Rethink Things
-
In researching render_to_response, I see that when RequestContext
is passed as context_instance to render_to_string, it is then simply
updated with the context dictionary, then passed along to render.  My
views usually look like so:

def index(request):
context = {}
context['foo'] = do_something(bar)
...
return render_to_response('index.html', context,
context_instance=RequestContext(request))

So it wouldn't be too much hassle to change them to:

def index(request):
context = RequestContext(request)
context['foo'] = do_something(bar)
...
return render_to_response('index.html', context)

An anonymous commenter also suggested this technique [2], but in his
example as well as in the Django docs it didn't occur to me until now
that context variables could be added to the RequestContext
dictionary.  If I'm not mistaken, the two views have the exact same
effect.  I much prefer the look of the second, to the point where my
changes to django.shortcuts don't seem quite so necessary [3].  Maybe
the docs could provide a similar example?

[1] See the thread at
http://groups.google.com/group/django-developers/browse_thread/thread/e0a59d1eaa84c7b4
[2] http://fi.am/entry/shortcutting-render_to_response/#comment-7
[3] They still might be worth considering, however, if one believes that
RequestContext should just be included in the default template-rendering
shortcut.  It would make most view code just a little bit simpler.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: QuerySet.update improvement.

[Sean Legassick]

On 10 May 2008, at 14:47, Sebastian Noack wrote:
> You can still do model.objects.update(foo=42) with my patch, because
> of 42 is casted to a LiteralExpr under the hood. I could even make it
> possible to do model.objects.update(foo=CurrentExpr() + 42). But there
> is no way to enable model.objects.update(foo=42 + CurrentExpr()),
> because of in this case int.__add__ instead of Expression.__add__ is
> called, so I decided to introduce LiteralExpr. But I agree that it
> would be cool, if you could use a literal as it is.

You can handle this case by defining Expression.__radd__ (see 
http://docs.python.org/ref/numeric-types.html)

-- 
Sean


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Adding SVN revision identifier to version

[Sean Perry]

On Aug 17, 2007, at 9:09 PM, Deryck Hodge wrote:

>
>
>
> On Aug 17, 2007, at 10:37 PM, Sean Perry <[EMAIL PROTECTED]> wrote:
>
>>
>> On Aug 17, 2007, at 6:49 PM, Russell Keith-Magee wrote:
>>>
>>> At the very least, your patch would need to catch the inevitable
>>> error. Better yet would be an approach that doesn't require an
>>> external call. Is there any other data source we can farm? Is there
>>> anything we can easily glean from the contents of the .svn  
>>> directory?
>>>
>>
>> yeah, .svn/entries, should be line 4.
>>
>> cat .svn/entries | head
>> 8
>>
>> dir
>> 5920 <-- you want this
>> http://code.djangoproject.com/svn/django/trunk
>> http://code.djangoproject.com/svn
>
> Certain (older?) versions of the entries file are XML.  We would need
> to figure out how many versions there are, which doesn't do much for
> future proofing us.
>
> This is one advantage the svn client has, but I'm really not against
> parsing entries files ourselves.  I just wanted to point out there are
> pros and cons either way.
>

First line is the format version number of the entries file itself.  
Versions >= 7 are no longer in XML format. As you can see, mine says  
'8'.

If it is XML, the structure should be:

   


Assuming I read subversion-1.4.4/subversion/libsvn_wc/README  
correctly. The entries file format is documented pretty well in the  
README. Should be trivial to get what django needs.

The joys of open source. The answers are pretty easy to find.




--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Adding SVN revision identifier to version

[Sean Perry]

On Aug 17, 2007, at 6:49 PM, Russell Keith-Magee wrote:
>
> At the very least, your patch would need to catch the inevitable
> error. Better yet would be an approach that doesn't require an
> external call. Is there any other data source we can farm? Is there
> anything we can easily glean from the contents of the .svn directory?
>

yeah, .svn/entries, should be line 4.

cat .svn/entries | head
8

dir
5920 <-- you want this
http://code.djangoproject.com/svn/django/trunk
http://code.djangoproject.com/svn


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

[Sean Patrick Hogan]

That's a good question and one I don't know the answer to.

But here's one thing to keep in mind.  Let's say that introspectively
looking up a function is 4x more costly.  If I have 8 entries in my URLConf
going to different functions, calling by string is 2x faster.

Plus, there's the issue of memory which might be more important than
processing power as web apps tend to be memory-hungry more than processor
hungry.  I'm guessing loading the functions would take more memory than
calling by string.

In the end, I don't think it will matter in any app.  One should probably
pay attention to what's in their functions more than how they load them.
That's where the real problems are going to be.

On 7/10/07, Kevin Menard <[EMAIL PROTECTED]> wrote:
>
>
> On 7/10/07, Sean Patrick Hogan <[EMAIL PROTECTED]> wrote:
> > The "pythonic" way is a new addition to Django if I'm not mistaken.
> >
> > I personally prefer calling by string because (I'm assuming here) it
> doesn't
> > load the function unless it needs to.  So, if I have a URLConf that
> > references 8 view functions, it only imports the one for the correct URL
> if
> > I call by string which saves me from loading 7 functions that I'm not
> using.
> >  If I import them all at the top, I'm importing functions that may have
> > nothing to do with rendering the current page.  Of course, the impact on
> > resources is probably minimal to none, but it still means writing less
> code
> > to call by string.
>
> Sorry to be taking this a bit OT, but you raised an interesting point.
> Do you happen to know what the cost impact is for importing a
> function into the current scope VS the cost of introspectively looking
> up a function?  Is either cached or is this done on a per request
> basis?
>
> As an aside, I prefer the pythonic way because PyDev is able to give
> me some help with auto-completion, which tends to mean less errors due
> to stupid typos.
>
> --
> Kevin
>
> >
>


-- 
www.PovertyFighters.com

If you knew you could fight hunger and poverty, conserve the environment,
empower women, combat AIDS, improve labor standards and win a national
competition for your university--all with only two clicks a day--would you do
it?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: New Python ORM

[Sean Patrick Hogan]

It's also just very verbose.

   1 >>> class Person(object):
   2 ... __storm_table__ = "person"
   3 ... id = Int(primary=True)
   4 ... name = Unicode()

So, I have to declare a __storm_table__ and id for every model.  That should
be assumed by default and allowed to be overwritten (in my opinion).

   1 >>> class Employee(Person):
   2 ... __storm_table__ = "employee"
   3 ... company_id = Int()
   4 ... company = Reference(company_id, Company.id)

Here we see that I have to declare a company_id and the the foreign key -
Django does this in one step with ForeignKey(Model).

It just seems that Django's ORM is already syntactically nicer and, other
than inheritance, Storm doesn't seem to have any really compelling feature.

On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Jul 10, 4:43 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> > Not sure if you guys have seen this, but maybe Django can take a bit
> > from what it does well.
> >
> > https://storm.canonical.com/Tutorial
>
> The problem is no one knows what it 'does well' yet :-)
> It is missing many of the features Django already has, and looks to be
> behind SQLAlchemy which people are already working on integrating in
> some fashion (maybe).
>
>
> -Doug
>
>
> >
>


-- 
www.PovertyFighters.com

If you knew you could fight hunger and poverty, conserve the environment,
empower women, combat AIDS, improve labor standards and win a national
competition for your university--all with only two clicks a day--would you do
it?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

[Sean Patrick Hogan]

Yeah, I've used the caching decorators in my URLConf for generic views that
way.
I think it's good to support both ways and I don't think either is going
away, but someone more familiar with development should probably comment on
that.

Sean.

On 7/10/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
>
> On 7/10/07, Sean Patrick Hogan <[EMAIL PROTECTED]> wrote:
> > The "pythonic" way is a new addition to Django if I'm not mistaken.
>
> Yes, it was added between the 0.95 and 0.96 releases.
>
> > I personally prefer calling by string because (I'm assuming here) it
> doesn't
> > load the function unless it needs to.
>
> On the other hand, importing the functions and using them directly
> opens up some interesting possibilities -- you can apply decorators
> like 'login_required' to them right there in the URLConf, which adds
> another layer of configurability that isn't possible when referencing
> them as strings.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> >
>


-- 
www.PovertyFighters.com

If you knew you could fight hunger and poverty, conserve the environment,
empower women, combat AIDS, improve labor standards and win a national
competition for your university--all with only two clicks a day--would you do
it?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: urlconf, strings vs. callables

[Sean Patrick Hogan]

The "pythonic" way is a new addition to Django if I'm not mistaken.

I personally prefer calling by string because (I'm assuming here) it doesn't
load the function unless it needs to.  So, if I have a URLConf that
references 8 view functions, it only imports the one for the correct URL if
I call by string which saves me from loading 7 functions that I'm not
using.  If I import them all at the top, I'm importing functions that may
have nothing to do with rendering the current page.  Of course, the impact
on resources is probably minimal to none, but it still means writing less
code to call by string.

from project.app.views import function

(r'^$', function)

is more than

(r'^$', 'project.app.views.function')

Sean.

On 7/10/07, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>
>
> hi,
>
> when specifying view-functions in the urlconfs, you can either specify
> them by their name as a string, or by referencing them "pythonically"
> (importing them, and giving the urlconf the callable).
>
> which is the "preferred" way?
>
> i'm always using the "pythonic" way (import the view function, and give
> it to the urlconf), and assumed that this is the recommended way.
>
> but what always worried me is that you still have to enter that
> "string-prefix", which is of course an empty-string in my case, but
> still, it's quite ugly there.
>
> so i wondered whether the pythonic-way is really the preferred one.
>
> so i went to check the django-documentation...
>
> the documentation on the django-site:
>
> http://www.djangoproject.com/documentation/tutorial03/#design-your-urls
>
> uses the string-based syntax.
>
> but the django-book:
>
> http://www.djangobook.com/en/beta/chapter03/
>
> uses the pythonic-syntax.
>
> so:
>
> 1. which is the preferred way?
> 2. will django support both ways "forever"?
> 3. would it make sense to make the tutorial and the book more consistent
>   by using the same urlconf-style?
>
> thanks,
> gabor
>
> >
>


-- 
www.PovertyFighters.com

If you knew you could fight hunger and poverty, conserve the environment,
empower women, combat AIDS, improve labor standards and win a national
competition for your university--all with only two clicks a day--would you do
it?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Message Passing for Anonymous Users

[Sean Patrick Hogan]

I created a ticket for a new way of passing messages and the first response
said that I should bring it up to the dev group for a design decision.

http://code.djangoproject.com/ticket/4604 - that's the ticket (with patch).

Basically, it stores messages according to session rather than according to
user.  This way, even if a user is anonymous, you can send them messages.
This works out nicely when someone is signing up for the site and you want
to pass them back to the homepage with a message (but they don't have their
account yet so you can't use user_instance.message_set.create()).

It uses a context processor to get the message into the template and
middleware to get the message from the view and into the session.

I hope you like it!
Sean.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Are we dropping auto_now and auto_now_add for 1.0?

[Sean Perry]

On Apr 6, 2007, at 11:39 AM, David Larlet wrote:

>
> 2007/4/6, Brian Beck <[EMAIL PROTECTED]>:
>>
>> On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote:
>>> It could be just me, but although i don't mind losing auto_*, it  
>>> don't
>>> look very DRY in save.
>>>
>>> I know it's only a few lines (like 4 ? for both options, not using
>>> default= for sake of keeping the logic together) but when lots of
>>> models
>>> have a cre_date and mod_date, those lines are repeated over and over
>>> again in save().
>>
>> I agree. Using default= in place of auto_now_add is fine, but writing
>> a save() for every model that needs auto_now is just annoying. A
>> shortcut would be nice.
>
> I agree with Brian.
>

seems like it should be as easy as a function in contrib somewhere:

def auto_now(amodel):
 if not amodel.id:
 amodel.created = datetime.datetime.now()
 else:
 amodel.modified = datetime.datetime.now()

 super(type(amodel), amodel).save()

and in your model you have:

save = contrib.auto_now

When you have to add code to your save() method you could still call  
auto_now(self).


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: MS SQL help (Was Re: Moving towards Django 1.0)

[Sean De La Torre]

Adrian,

A few of us are talking to Chris Beaven about getting a SQL Server support
ticket committed (ticket 2358 - http://code.djangoproject.com/ticket/2358).
The only thing that is not included in the ticket is SQL Server pagination
support (it's a complicated subject).  A few of us have been using the patch
in that ticket for a while now, and it is stable.

Sean

On 2/9/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
>
> On 2/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I have significant experience with MS SQL server 2000, and have access
> > to an instance to test against.  I have found very little
> > documentation on Trac about this in tickets or the wiki.  I am also
> > willing to help with Windows installers (NSIS is my recommended
> > tool).  I gather that SQL server support is a slightly higher priority
> > than a Windows installer?  Does MS SQL currently have someone heading
> > that effort?  Where should I start?
>
> Hi rokclim15,
>
> Thanks very much for this kind offer! I'm not sure who the MS SQL
> Django maintainers/advocates are, if any. I'm hoping they'll chip into
> this thread.
>
> Where does MS SQL support stand, and what do we need to do to make it
> a first-class citizen?
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: svn properties ?

[Sean Perry]

On Jan 23, 2007, at 10:45 PM, Russell Keith-Magee wrote:

>
> On 1/24/07, Sean Perry <[EMAIL PROTECTED]> wrote:
>> I could care less about most of the keywords. However, having Rev or
>> Id set is handy for the sysadmin down the road trying to figure out
>> where the bug came from.
>
> Isn't that what `svn blame` is for?
>
> Count me -1 on keywords expansion, too.
>

Yes, but ONLY if you have a svn checkout. Forgive me for not being  
clear. Having a id or rev is handy if at sometime a sysadmin has a  
file on his system but does not know for sure which version / release  
it came from.

For example, admin A finds out about Django downloads a tarball /  
checks out svn. He installs it to /usr/local/blah and writes some web  
apps. At some point in the future admin B has to find out why an app  
is not working and it turns out to be a Django bug. How does he know  
where /usr/local/blah/django/broken.py came from? Is it 0.91? 0.95? 1.1?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: State of MSSQL support

[Sean De La Torre]

Take a look at this ticket http://code.djangoproject.com/ticket/2358

It's based on adodb, and I believe it is fully functional except for
paging support (hopefully coming soon).

Sean

On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I am mostly new to Django, but have significant experience working with
> MSSQL in other languages.  I noticed that there is support for MSSQL
> (generating SQL only) through the adodb abstraction layer.  I'm
> guessing this was a compatibility patch to allow for the "TOP" vs
> "LIMIT" syntax.  Is that the reason that adodb was used?  I recently
> found a python library for MSSQL that is open source, and was
> considering writing both generation and introspection code for native
> MSSQL.  However, I don't want to do this if such a thing is already
> under way or has already been considered.  I can't find a trac ticket
> on it, so I'm posting here.  Thanks.
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: MSSQL Support

[Sean De La Torre]

I'll take a look around and see if there is a proper place for these
statements.  I had just come across the statement you posted for SQL
Server 2000, so we're probably looking in the same places to solve the
problem.

On 10/22/06, DavidA <[EMAIL PROTECTED]> wrote:
>
>
> Sean De La Torre wrote:
> > I've been testing with SQL Server 2000 and MSDE.  When I have more
> > time I intend to install SQL Server 2005 Express to see if there are
> > any issues with the newer versions.
> >
> > On 10/21/06, DavidA <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Sean De La Torre wrote:
> > > > I've been maintaining/enhancing a ticket
> > > > (http://code.djangoproject.com/ticket/2358) contributed by another
> > > > django user that adds MSSQL support to django.  In addition to what
> > > > that user started, I've added full introspection capabilities and
> > > > patched a few bugs that I've found.  I've been running a production
> > > > site using this patch for about a month now, and the MSSQL integration
> > > > seems to be stable.
> > > >
> > > > I'd appreciate it if other MSSQL users could give the patch a try.
> > > > The one item missing from the ticket is paging, but MSSQL doesn't
> > > > support that natively, so any input regarding that problem would also
> > > > be most appreciated.
> > > >
> > > > If the Django-users list is the more appropriate place for this
> > > > message, please let me know.
> > > >
> > > > Thanks,
> > >
> > > What version of SQL Server have you been testing with? I think in 2005
> > > there is support for paging. This brings up the question of how to
> > > handle different versions of backends.
> > >
> > >
> > > >
> > >
>
> For 2005 you can use the new ROW_NUMBER() function to help with
> limit/offset:
>
> SELECT  * FROM (
> SELECT  ROW_NUMBER() OVER (ORDER BY field DESC)
>  AS Row, * FROM table)
> AS foo
> WHERE  Row >= x AND Row <= y
>
> For 2000 I've seen people use this approach, which works if your sort
> field(s) are unique:
>
> SELECT * FROM (
> SELECT TOP x * FROM (
> SELECT TOP y fieldlist
> FROM table
> WHERE conditions
> ORDER BY field  ASC) as foo
> ORDER by field DESC) as bar
> ORDER by field ASC
>
> So to get records 81-100, y is 100 and x is 20, and the inner-most
> select gets the top 100 rows. The middle select orders these in reverse
> order and gets the top 20. The outer select reverses these again to put
> them in the right order.
>
> I'm not sure where if the db backends separate responsibilities enough
> to allow you to wrap this up nicely in the SQL server backend. But it
> might work.
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: MSSQL Support

[Sean De La Torre]

I've been testing with SQL Server 2000 and MSDE.  When I have more
time I intend to install SQL Server 2005 Express to see if there are
any issues with the newer versions.

On 10/21/06, DavidA <[EMAIL PROTECTED]> wrote:
>
>
> Sean De La Torre wrote:
> > I've been maintaining/enhancing a ticket
> > (http://code.djangoproject.com/ticket/2358) contributed by another
> > django user that adds MSSQL support to django.  In addition to what
> > that user started, I've added full introspection capabilities and
> > patched a few bugs that I've found.  I've been running a production
> > site using this patch for about a month now, and the MSSQL integration
> > seems to be stable.
> >
> > I'd appreciate it if other MSSQL users could give the patch a try.
> > The one item missing from the ticket is paging, but MSSQL doesn't
> > support that natively, so any input regarding that problem would also
> > be most appreciated.
> >
> > If the Django-users list is the more appropriate place for this
> > message, please let me know.
> >
> > Thanks,
>
> What version of SQL Server have you been testing with? I think in 2005
> there is support for paging. This brings up the question of how to
> handle different versions of backends.
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: mod_python configuration problem (apache 2.2.2/mod_python 3.2.10)

[Sean De La Torre]

Tim,

>> adding polls/ to the end of this address on apache - it throws up a 404
error.

Try removing the '$' from the r'^mysite/$' pattern.  The '$' signifies
the end of the end of the string, so the pattern '^mysite/$' will only
match 'mysite/'; the pattern '^mysite/' will match any pattern
starting with 'mysite/'.

Sean

On 10/20/06, Tipan <[EMAIL PROTECTED]> wrote:
>
> Sean,
>
> That did the trick. Thanks. Admin section looks the part on Apache
> server now.
>
> I've still got a discrepancy between the way the project application
> works on Apache and on the lite development server.
>
> in my url.py if I have the line: (r'^mysite/$',
> 'mysite.polls.views.index') it runs on the lite server when I enter the
> URL: localhost/polls/ whether this line is commented out or not
>
> However, it only works on Apache, when I uncomment the line and have to
> enter the address: localhost/mysite/
>
> adding polls/ to the end of this address on apache - it throws up a 404
> error.
>
> The whole thing works just as you'd expect in the lite server - but not
> in apache. Clearly it's getting there, but is frustrating.
>
> My url.py looks like this:
> --
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('',
> #(r'^mysite/$', 'mysite.polls.views.index'),
> (r'^polls/', include('mysite.polls.urls')),
>
> # Uncomment this for admin:
>  (r'^admin/', include('django.contrib.admin.urls')),
> )
> -
>
> Regards, Tim
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: mod_python configuration problem (apache 2.2.2/mod_python 3.2.10)

[Sean De La Torre]

Hmm.  Try adding* this before your alias statement:


AllowOverride None
Options None
Order allow,deny
Allow from all


* Remember to change the Directory value to the base directory where
your media files are stored.

Sean

On 10/20/06, Tipan <[EMAIL PROTECTED]> wrote:
>
> Sean,
>
> Thanks for your time here, much appreciated.
>
> That all made sense except the alias statement in HTTPD.conf.  Does it
> matter where I place this line?
>
> I've implemented it all as you described and it now throws up an error
> in the HTML source as before and doesn't fromat the output:
> -
>  rel="stylesheet">
>
> Access forbidden!
>
> You don't have permission to access the requested object. It is either
> read-protected or not readable by the server.
>
> If you think this is a server error, please contact the webmaster.
> Error 403
>
>  localhost
>
> 10/20/06 16:46:02
> Apache/2.2.2 (Win32) DAV/2 mod_python/3.2.10 Python/2.4.3 mod_ssl/2.2.2
> OpenSSL/0.9.8b mod_autoindex_color PHP/5.1.4
>
> -
>
> Any thoughts?
>
> Tim
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: mod_python configuration problem (apache 2.2.2/mod_python 3.2.10)

[Sean De La Torre]

I made a mistake in the alternative section I posted in my last
response.  You would need to remove the '^' from each of the
urlpatterns starting with '^polls' and replace it with '.*polls'.  In
any case, adding '^mysite' to the beginning of each urlpattern is the
more explicit way to go.

Sorry,

Sean

On 10/19/06, Sean De La Torre <[EMAIL PROTECTED]> wrote:
> Your urlpatterns are not correct.  Given your current apache
> configuration, the beginning of each of your patterns will need to
> start with '^mysite'.  Alternatively, you can try removing the '^' at
> the beginning of each of the polls url patterns.  That symbol
> indicates that the regex pattern should start its match at the
> beginning of the string, and it will never match your urls because
> they all start with 'mysite'.
>
> As for the admin section, create another apache location similar to
> the one you created for mysite.  In fact, copy and paste the location
> you have for mysite and substitute 'admin' for 'mysite'.  That should
> get your admin to work.
>
> Sean
>
> On 10/19/06, Tipan <[EMAIL PROTECTED]> wrote:
> >
> > Clint,
> >
> > Thanks for the advice. I have changed the urls.py which is found in the
> > mysite folder and this now brings the simple list of polls on to the
> > screen (http://localhost/mysite/). Adding a /polls/ to the url throws
> > up an error (as it did before).
> >
> > My urls.py now looks like this:
> >
> >
> > -
> > from django.conf.urls.defaults import *
> >
> > urlpatterns = patterns('',
> > # Example:
> > (r'^mysite/$', 'mysite.polls.views.index'),
> > (r'^polls/$', 'mysite.polls.views.index'),
> > (r'^polls/(?P\d+)/$', 'mysite.polls.views.detail'),
> > (r'^polls/(?P\d+)/results/$',
> > 'mysite.polls.views.results'),
> > (r'^polls/(?P\d+)/vote/$', 'mysite.polls.views.vote'),
> >
> > # Uncomment this for admin:
> > (r'^admin/', include('django.contrib.admin.urls')),
> > ---
> >
> > However, using the lite server when I enter the URL:
> > http://localhost:8000/admin/
> > I get the my administration interface with table access, sidebar etc.
> >
> > Typing the same URL when Apache is running gets me a "cannot connect to
> > server" message.
> >
> > Clearly to 2 servers are interpreting differently and I wonder whether
> > my apache config file httpd.conf is correct. The location lines I've
> > added to it are:
> > ---
> > 
> > SetHandler python-program
> > PythonPath "['c:/data/business/projects/django_test'] + sys.path"
> > PythonHandler django.core.handlers.modpython
> > SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> > PythonDebug On
> >
> > 
> > 
> >
> > Any thoughts?
> >
> > Regards, Tim
> >
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: mod_python configuration problem (apache 2.2.2/mod_python 3.2.10)

[Sean De La Torre]

Your urlpatterns are not correct.  Given your current apache
configuration, the beginning of each of your patterns will need to
start with '^mysite'.  Alternatively, you can try removing the '^' at
the beginning of each of the polls url patterns.  That symbol
indicates that the regex pattern should start its match at the
beginning of the string, and it will never match your urls because
they all start with 'mysite'.

As for the admin section, create another apache location similar to
the one you created for mysite.  In fact, copy and paste the location
you have for mysite and substitute 'admin' for 'mysite'.  That should
get your admin to work.

Sean

On 10/19/06, Tipan <[EMAIL PROTECTED]> wrote:
>
> Clint,
>
> Thanks for the advice. I have changed the urls.py which is found in the
> mysite folder and this now brings the simple list of polls on to the
> screen (http://localhost/mysite/). Adding a /polls/ to the url throws
> up an error (as it did before).
>
> My urls.py now looks like this:
>
>
> -
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('',
> # Example:
> (r'^mysite/$', 'mysite.polls.views.index'),
> (r'^polls/$', 'mysite.polls.views.index'),
> (r'^polls/(?P\d+)/$', 'mysite.polls.views.detail'),
> (r'^polls/(?P\d+)/results/$',
> 'mysite.polls.views.results'),
> (r'^polls/(?P\d+)/vote/$', 'mysite.polls.views.vote'),
>
> # Uncomment this for admin:
> (r'^admin/', include('django.contrib.admin.urls')),
> ---
>
> However, using the lite server when I enter the URL:
> http://localhost:8000/admin/
> I get the my administration interface with table access, sidebar etc.
>
> Typing the same URL when Apache is running gets me a "cannot connect to
> server" message.
>
> Clearly to 2 servers are interpreting differently and I wonder whether
> my apache config file httpd.conf is correct. The location lines I've
> added to it are:
> ---
> 
> SetHandler python-program
> PythonPath "['c:/data/business/projects/django_test'] + sys.path"
> PythonHandler django.core.handlers.modpython
> SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> PythonDebug On
>
> 
> 
>
> Any thoughts?
>
> Regards, Tim
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Integrating Django and SQLAlchemy

[Sean De La Torre]

If you need MSSQL
support today, you might want to take a look this ticket:
http://code.djangoproject.com/ticket/2358.  It hasn't been officially
accepted, but I've been able been able to successfully use MSSQL with Django
after applying it.  

Using ticket 2358, I wrote this patch http://code.djangoproject.com/ticket/2563
(introspection functionality for MSSQL
backends).  Again, this
is another patch that hasn't been accepted, but if you really need to use Django with MSSQL like me, these tickets are certainly a good
place to start.From what I've read, pagination might not work yet. but everything else that I've tried seems to work just fine. Sean
On 9/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I noticed on the SQLAlchemy web site that there is "developmentalsupport" for MS SQL. Would this help hasten support for MS SQL inDjango?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/django-developers  -~--~~~~--~~--~--~---

Re: What if instead of calling them "projects" we called them "sites"?

[Sean Perry]

Jeremy Dunck wrote:
> On 3/2/06, Sean Perry <[EMAIL PROTECTED]> wrote:
> 
>>I am definitely -2 on this. Malcolm does a good job of starting the ball
>>rolling as to why.
> 
> 
> The range is -1..+1  ;-)
> 

with room for hyperbole (-:


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: What if instead of calling them "projects" we called them "sites"?

[Sean Perry]

pbx wrote:
> I was going to file a ticket but wanted to make sure there isn't some
> important conceptual distinction that I'm missing. Is there?
> 

I am definitely -2 on this. Malcolm does a good job of starting the ball 
rolling as to why.

For any admin / web type guy a 'site' is a machine / virtual server. It 
contains many projects / apps / whatever.

you have a blog, a front page with other news about whatever it is, and 
may be an online ordering system. That is all one site. At least 3 apps.

I am not keen on the 'project' name itself, but 'site' is not a better term.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: How about converting python config files to text config files

[Sean Perry]

Russell Keith-Magee wrote:

I fail to see what problem would be solved or made easier by introducing a
new syntax.



sometimes people like to use a language other than python but share some 
data.