Re: High Level Discussion about the Future of Django

[Taylor Marshall]

On Fri, Apr 16, 2010 at 12:23 PM, Tom X. Tobin  wrote:
> None of this means that I think the core development process should
> change.  (Well, besides my fervent desire that they officially adopted
> git — and yes, I do believe it *would* make a difference, centralized
> "official" branch and all — but that's a discussion for another time
> and a few beers.)
>

You might be able to make a case on the whole DVCS thing in general,
but I'm not sure why any particular flavor is necessarily *the* choice
(i.e. the whole git vs mercurial vs bazaar holy war).

>
> So ... who has a GitHub account and some neat code to look at?  :-)
>

There's already a unofficial mirror on GitHub which is maintained by jezdez:

http://github.com/django/django

Doesn't that solve the "make it easier to branch and track upstream
changes" thing?

-- 
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: GSoC10 Idea: Additional queryset methods

[Taylor Marshall]

On Fri, Mar 19, 2010 at 11:09 AM, Karen Tracey  wrote:
> However, it does seem to be in direct conflict with the idea of getting to
> the ORM working on non-SQL databases. The additional methods mentioned
> (select, from, leftJoin) together all sound like they are moving the app-ORM
> interface closer to raw SQL rather than away from it. Given the more
> long-standing interest in getting the ORM working with things like app
> engine's BigTable, I can't see a proposal for movement more towards raw SQL
> being accepted.

I agree with this sentiment.  To me, the example API shown here reads
almost just like SQL.   There's already a mechanism for writing raw
SQL, and the example provided doesn't seem to be a whole lot simpler.

Maybe a solution is some extension to django.db.connection that would
let you get back objects with named fields (or maybe just dicts) in
place of plain tuples?   You'd get all the flexibility that you want,
but more readable code (accessing field names rather than sequence
indices).

Taylor

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

Re: proposal: ask a queryset to not raise exceptions

[Taylor Marshall]

> PS: Can people *please* use 'cls' and not 'klass'. =/

Yes you are right, my fault.  Although I did just rip the code from
the patch at http://code.djangoproject.com/ticket/2659 and modify it.

Additionally, looking at that issue will likely give some insight into
the response this change will likely get.

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

Re: proposal: ask a queryset to not raise exceptions

[Taylor Marshall]

Seems like it'd be pretty simple for the developer to make a little
helper method like so...

>>> def latest_or_none(klass, *args, **kwargs):
>>> try:
>>> return klass.objects.filter(*args, **kwargs).latest()
>>> except klass.DoesNotExist:
>>> return None

I guess I don't see this as a huge issue.


On Sun, Mar 7, 2010 at 5:40 PM, Will Hardy  wrote:
> I'm not sure what reception you'll get for this suggestion (also given
> that all attention is currently on Django 1.2), but I think eventually
> problems like these may be best addressed by allowing you as the
> developer to write your own customised helper functions/methods to
> deal with things the way you want them to.
>
> In this case, it would mean a custom (subclassed) QuerySet.
>
> You can do this already by subclassing models.query.QuerySet, adding
> your own customisations and returning your queryset from the model
> manager's .get_query_set() method. It would however be nice if this
> were a little more obvious, simpler and explicit and by that I mean
> maybe removing the Manager/QuerySet distinction.
>
> Until then (and such a big change wont happen any time soon), you can
> use a number of snippets around that let you pass a custom queryset to
> the manager on instantiation, which isn't too difficult. I could also
> be wrong in that this might be the sort of feature a whole lot of
> people want baked in.
>
> Cheers,
>
> Will
>
> --
> 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: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Taylor Marshall]

I think umovi makes a great point here when he mentions that templates are
often used for things that are not HTML.   "Be decoupled from HTML" is one
of the core design philosophies listed in the docs.

I'm not really advocating for or against adding a truncate filter, but I do
think that "you should be using CSS instead" is an invalid argument against
it.

On Wed, Dec 30, 2009 at 2:33 PM, umovi  wrote:
> I use templates sometimes to produce plain text, emails *without
> html*, etc, so CSS is not always a solution.
>
> --
>
> 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Taylor Marshall]

I'd love to see this change get put in.  I think the most common case
for forms is to trim whitespace, not the other way around.  I'd rather
have the extra work come in for the rare case (when you wanted to
preserve leading/trailing spaces).

-Taylor

On Oct 10, 11:37 am, Barry Pederson  wrote:
> On May 13, 2:56 am, Russell Keith-Magee 
> wrote:
>  >On Wed, May 13, 2009 at 7:48 AM, thebitguru  wrote:
>
>  >> Hi,
>
>  >> What do we need to make a decision for ticket 6362 (http://
>  >> code.djangoproject.com/ticket/6362)?
>
>  > We need to wait until we're not trying to get v1.1 out the door.
>
>  > We are well past the feature deadline for v1.1; the focus of the
>  > community is on fixing bugs and finalizing the v1.1 release. Once that
>  > happens, we will be in a position to concentrate on design decisions
>  > again.
>
> Now that we're talking about 1.2, I hope this can be looked at before
> the door closes again.  Either this or the simpler patch from
>
>    http://code.djangoproject.com/ticket/4960
>
> Having extraneous spaces in user input is quite annoying and can cause a
> fair amount of trouble.  Yes, you could write custom validation for
> every single one of your forms, but a global fix is potentially pretty
> trivial.
>
> Some other tickets complaining about the same problem with specific
> field types are:
>
>    http://code.djangoproject.com/ticket/5714
>    http://code.djangoproject.com/ticket/11907
>
>         Barry

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