Re: first() and last(), earliest() and latest()

[Shai Berger]

Two notes:

1) I think it is better to leave the *args, **kw on the manager methods; since 
they are just forwarding to the qset anyways, there's no harm in that, and it 
makes them more "future proof" (i.e. you wouldn't need to change them next 
time you change the interface of the qset methods).

Case in point:

2) I'd like to add an argument to the first() method, something like 
   def first(self, only=True):

Where the sense of only=True is that if there is more than one object to get, 
that's an error (MultipleObjects, like in get).

As this feature was mainly designed to replace the anti-pattern,

try:
x = qset.get(...)
except DoesNotExist
x = None

I think the default for "only" should indeed be True. Other people may 
disagree. I think without at least the ability to set only=True, this feature 
is essentially broken -- since it is the equivalent of

try:
x = qset[0]
except IndexError
x = None

it encourages people to give up an integrity check.

My 2 cents,
Shai.

On Wednesday 15 May 2013, Selwin Ong wrote:
> I've updated the first() and last() to not accept any arguments. Please
> review it and let me know if there's anything else I need to change.
> Hopefully this can get merged in during the sprints and make it into 1.6
> :).
> 
> The pull request is here: https://github.com/django/django/pull/1056
> 
> Best,
> Selwin
> 
> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
> > > > I initially modeled "first()" and "last()"'s behaviors to mimic
> > > > "latest()", but in this new pull request, you can pass multiple field
> > 
> > names
> > 
> > > > into "first()" and "last()" so it behaves like "order_by()". It's
> > > > more flexible and requires less typing, but I wonder if we should
> > > > just get
> > 
> > rid
> > 
> > > > of the optional field arguments and rely on "order_by" for ordering.
> > 
> > "There
> > 
> > > > should be one-- and preferably only one --obvious way to do it".
> > > 
> > > Considering "There should be one-- and preferably only one --obvious
> > > way
> > 
> > to
> > 
> > > do it", I definitely prefer to rely on order_by to do the ordering, not
> > 
> > on
> > 
> > > first.
> > > 
> > > .order_by('name').first()
> > > 
> > > is clear and readable in my opinion.
> > 
> > My thoughts exactly, we already have one method that does ordering, I
> > don't think it is necessary to make these methods incorporate that
> > functionality. If we did, we might argue that other QuerySet
> > operations could be supported as well and that would just result in a
> > bloated API. Especially if there's no performance gain (the QuerySet
> > would be cloned anyway), and it only saves a few lines of code.
> > 
> > Also, skimming through this thread, I think there was a consensus on
> > first() and last() not taking any ordering arguments, i.e. the first
> > 
> > proposed syntax:
> > .filter(last_name__startswith='b').order_by('last_name').first()
> > 
> > Michal

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

django and paramstyle: what's the actual story?

[VernonCole]

I noticed in a recent post that there is an outstanding patch for Oracle 
for support of 'named' paramstyle.

I also found, during my morning's research on the question, that there has 
been at least one patch so that django will play nice with 'pyformat' 
paramstyle.

I got involved with this entire question when I back-ported Adam 
Vandenberg's paramstyle conversion code into the development fork of 
adodbapi.  It appeared to me, and seems to be widely believed in the 
community (enough so that I have stated it as a fact) that "django blindly 
expects 'format' paramstyle."  Not only django-mssql, but also the sqlite 
adapter convert incoming queries from 'format' into 'qmark' before handing 
it off to the SQL engine.  My revision to adodbapi permits the programmer 
to SET paramstyle (to one of 'named', 'qmark', or 'format') and the adapter 
does the conversion.  The version now in development adds the capability of 
making that selection using a keyword argument to the 'connect' call.  The 
patched version of the django-mssql back end just sets that keyword and 
goes on its merry way.

Recent traffic on the Python database discussion list has floated the idea 
that it is time for an upgrade to PEP 249, making a new db-api version 3.0 
with a new PEP.  The consensus opinion is running toward paring the 
available paramstyle options down to two, and forcing adapter authors to 
support both.  The two winners were 'qmark' and 'named'.  My latest input 
to that effort was a plea that 'format' must be kept because of the 
widespread use of it in existing code -- and I specifically mentioned 
django.  But was I wrong?

I am not sure whether I am sounding a warning, or asking a question.  If a 
programmer is using the ORM, the whole question of paramstyle confusion is 
unimportant -- the ORM takes care of it.  To a programmer who makes raw SQL 
calls, it is all important.  Do I make a parameter list, or a parameter 
dictionary?  

What is the feeling of this group?  Should I maintain my activism that %s 
'format' paramstyle be maintained into the future?  Or should I be helping 
the django community to prepare for a new future where one must (or may?) 
choose between a parameter list with "?" or a parameter mapping with 
":paramname"?  Personally, I do not really like the '%s' style would be 
happy if it goes away.  What do you think?
--
Vernon Cole

-- 
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: first() and last(), earliest() and latest()

[Ryan Hiebert]

Only is a different purpose than first, and as such it would make sense to me 
if it was a separate method. First has some implication that there may be 
second, third as well. It comes down to taste, but I think my buds would prefer 
a separate method.


Ryan
—
Sent from Mailbox for iPhone

On Thu, May 16, 2013 at 12:08 AM, Shai Berger  wrote:

> Two notes:
> 1) I think it is better to leave the *args, **kw on the manager methods; 
> since 
> they are just forwarding to the qset anyways, there's no harm in that, and it 
> makes them more "future proof" (i.e. you wouldn't need to change them next 
> time you change the interface of the qset methods).
> Case in point:
> 2) I'd like to add an argument to the first() method, something like 
>def first(self, only=True):
> Where the sense of only=True is that if there is more than one object to get, 
> that's an error (MultipleObjects, like in get).
> As this feature was mainly designed to replace the anti-pattern,
> try:
>   x = qset.get(...)
> except DoesNotExist
>   x = None
> I think the default for "only" should indeed be True. Other people may 
> disagree. I think without at least the ability to set only=True, this feature 
> is essentially broken -- since it is the equivalent of
> try:
>   x = qset[0]
> except IndexError
>   x = None
> it encourages people to give up an integrity check.
> My 2 cents,
>   Shai.
> On Wednesday 15 May 2013, Selwin Ong wrote:
>> I've updated the first() and last() to not accept any arguments. Please
>> review it and let me know if there's anything else I need to change.
>> Hopefully this can get merged in during the sprints and make it into 1.6
>> :).
>> 
>> The pull request is here: https://github.com/django/django/pull/1056
>> 
>> Best,
>> Selwin
>> 
>> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>> > > > I initially modeled "first()" and "last()"'s behaviors to mimic
>> > > > "latest()", but in this new pull request, you can pass multiple field
>> > 
>> > names
>> > 
>> > > > into "first()" and "last()" so it behaves like "order_by()". It's
>> > > > more flexible and requires less typing, but I wonder if we should
>> > > > just get
>> > 
>> > rid
>> > 
>> > > > of the optional field arguments and rely on "order_by" for ordering.
>> > 
>> > "There
>> > 
>> > > > should be one-- and preferably only one --obvious way to do it".
>> > > 
>> > > Considering "There should be one-- and preferably only one --obvious
>> > > way
>> > 
>> > to
>> > 
>> > > do it", I definitely prefer to rely on order_by to do the ordering, not
>> > 
>> > on
>> > 
>> > > first.
>> > > 
>> > > .order_by('name').first()
>> > > 
>> > > is clear and readable in my opinion.
>> > 
>> > My thoughts exactly, we already have one method that does ordering, I
>> > don't think it is necessary to make these methods incorporate that
>> > functionality. If we did, we might argue that other QuerySet
>> > operations could be supported as well and that would just result in a
>> > bloated API. Especially if there's no performance gain (the QuerySet
>> > would be cloned anyway), and it only saves a few lines of code.
>> > 
>> > Also, skimming through this thread, I think there was a consensus on
>> > first() and last() not taking any ordering arguments, i.e. the first
>> > 
>> > proposed syntax:
>> > .filter(last_name__startswith='b').order_by('last_name').first()
>> > 
>> > Michal
> -- 
> 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: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Danilo Bargen]

As a sidenote, there was a discussion about this on this mailing list a few 
months ago:

https://groups.google.com/forum/#!searchin/django-developers/16550/django-developers/xN0aMzrmA1Y/KsrsEf7XOA8J

-- 
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: django and paramstyle: what's the actual story?

[mjl Martin J. Laubach]

  As for the death of '%s' style -- yes please, with sprinkles on top. It 
is totally violating the principle of least astonishment as anyone will 
expect '%s' to expand to a parameter string; yet that's not what it does, 
it magically adds quotes and whatnot.

  The other two variants are widely understood.

mjl

-- 
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: Automatic deployment tool

[Jonathan Slenders]

Hi all,

Some improvements have been made and documentation is coming.

For the curious, here is a 5min screen recording of me using it on our 
deployment environment that I'll present this weekend on djangocon-europe. 
You can watch it here:

https://vimeo.com/66302371


It shows:

- The hierarchical architecture of the deployment tree. (navigation through 
the nodes.)
- Interacting with remote redis shell and the django shell. (some of our 
deployment services.)
- source code introspection
- sandboxing of deployments.
- one complete (sandboxed) setup of our distributed application.

What's not shown, but great:
- typing "--connect" will open a bash shell on the remote end of the 
current node.
- introspection of everything
- a lot more.


Feedback is very welcome, but maybe keep it off django-developers.

https://github.com/jonathanslenders/python-deployer/

Enjoy!
Jonathan


Le lundi 10 décembre 2012 01:07:21 UTC+1, Cal Leeming [Simplicity Media 
Ltd] a écrit :
>
>
>
> On Sun, Dec 9, 2012 at 11:40 PM, Jonathan Slenders 
> 
> > wrote:
>
>> Thanks for your feedback, Cal,
>>
>> You're right about the documentation, some very useful parts aren't even 
>> documented at all. (There are comments in the code, but there are some 
>> little things you wouldn't know from the readme.)
>>
>> During the last years I also put most of the effort in experimenting and 
>> getting something really useful. It took a while before I got there, and it 
>> didn't make sense to document features which were to be refactored every 
>> now and then. However, now I feel its quite stable. I should start making 
>> better documentation, and a lot of usage examples. I also cannot deny that 
>> the learning curve may be a little bit steeper then Fabric in the very 
>> beginning, but soon you will see the advantages. 
>>
>  
>
>> If only I were as good in selling a project as I can code. :)
>>
>
> I know that feeling
>  
>
>>
>> Anyway, I hope this can also improve automatic deployment of Django 
>> applications for other people.
>>
>> Cheers,
>> Jonathan
>>
>>
>> Le lundi 10 décembre 2012 00:15:58 UTC+1, Cal Leeming [Simplicity Media 
>> Ltd] a écrit :
>>>
>>> Hi Jonathan,
>>>
>>> Just from a very brief point of view.. my eyes started to glaze over 
>>> whilst looking at the github README, and even more so when I looked at the 
>>> code.
>>>
>>> Even if this was the best thing since sliced bread, the documentation in 
>>> its current state leaves me with the feeling of "why do I want to use this".
>>>
>>> I think what would benefit this project massively is good/easy to read 
>>> documentation, with a simple overview section explaining common uses, what 
>>> makes it better than alternatives, etc.. maybe via readthedocs..?
>>>
>>> Statements such as "It's as declarative as possible.." sound impressive, 
>>> but don't really give me much insight into what this is, and why I'd want 
>>> to use it.
>>>
>>>  Hope this helps!
>>>
>>> Cal
>>>
>>> On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders >> > wrote:
>>>
 Hi Everyone,

 In the past there have been some discussionh about how to deploy Django 
 web applications through SSH. How to use Fabric or other tools, and 
 whether 
 we should provide or maybe force users to deploy applications according to 
 a certain conventions.

 Back then, maybe already more than a year ago, I said that I was 
 working on my own deployment tool. [1] Something that could be used 
 instead 
 of Fabric. It's a tool which could probably help a lot of you, although it 
 can take a while to adopt. The core consists of high quality code. I took 
 me a while before I felt confident enough for releasing this, and it has 
 been refactored more then any project I did before. Things still can be 
 improved, but it's ready to share with you.

 Key features are:

- Interactive execution of remote commands. Locally, they will 
appear in a pseudo terminal (created with openpty), so that even 
 editors 
like Vim or Emacs works fine when you run them on the remote end. You 
 can 
easy start an interactive shell on any host as well. 
- Reusability of all deployment code is a key point. It's as 
declarative as possible, but without loosing Python's power to express 
everything as dynamic as you'd like to. Deployment code is 
 hierarchically 
structured, with inheritance where possible. 
- Parallel execution is easy when enabled, while keeping 
interaction with these remote processes possible through 
 pseudoterminals. 
Every parallel task gets his own terminal, either a new xterm or 
gnome-terminal window, a tmux pane, or whatever you'd like to. 
- Logging of your deployments. New loggers are easily pluggable 
into the system.


 So, enjoy!

 So, what does it have to do with Django? I have a setup-definit

Re: Perception of attitude in tickets

[Luke Plant]

On 15/05/13 19:36, ptone wrote:

> I wonder if a slightly more concise version of this should be added to
> the triaging docs instead of a wiki page (fine place to draft it though).
> 
> https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#closing-tickets
> 
> I feel that the wiki pages aren't very discoverable, and unless we are
> talking about patching trac to include this, such a comment won't carry
> the official weight of being in the project docs.

That's a good idea. The purpose of this wiki page is to make it easy for
triagers to link to - I personally hate having to go and find the right
page in the docs, but I can remember to do "DevelopersMailingList"
instead of "developers mailing list".


> One line I do feel needs a tweak:
> 
> "while the suggestion is good in theory, it lacks enough merit to exceed
> the cost it will add to the maintenance of Django"
> 
> The truth is, there are some suggestions that are just flat out
> incompatible. I'm fine to be gracious and thankful for the time someone
> takes to offer a suggestion, but that doesn't mean that all suggestions
> are automatically meritorious.

I guess we would normally use INVALID for something that was just a bad
idea, whereas WONTFIX recognises there is a valid issue, but we're not
going to do anything about it. I've already removed reference to INVALID
on that page, but I'll tweak the text - feel free to make more changes.

Luke

-- 
"If something is hard, it's not worth doing." (Homer Simpson)

Luke Plant || http://lukeplant.me.uk/

-- 
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: Perception of attitude in tickets

[Russell Keith-Magee]

On Thu, May 16, 2013 at 7:16 PM, Luke Plant  wrote:

> On 15/05/13 19:36, ptone wrote:
>
> > I wonder if a slightly more concise version of this should be added to
> > the triaging docs instead of a wiki page (fine place to draft it though).
> >
> >
> https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#closing-tickets
> >
> > I feel that the wiki pages aren't very discoverable, and unless we are
> > talking about patching trac to include this, such a comment won't carry
> > the official weight of being in the project docs.
>
> That's a good idea. The purpose of this wiki page is to make it easy for
> triagers to link to - I personally hate having to go and find the right
> page in the docs, but I can remember to do "DevelopersMailingList"
> instead of "developers mailing list".
>
> Patching Trac sounds like a really good idea to me. While I completely
appreciate the intent of these wiki messages, the way those messages are
"deployed" at the present strikes me as something that could easily be
interpreted as rude. I'd like to see a much more "humane" usage of these
messages, so that new users to Trac don't feel like they're interaction
with Django as a project isn't a mechanical rejection.

Yours,
Russ Magee %-)

-- 
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: Perception of attitude in tickets

[Cal Leeming [Simplicity Media Ltd]]

I was going to mention this before, but wasn't sure how to word it.

Russell has hit the spot though, giving the user a more personal
experience, not just automated (or manual) copy-pasta.

Cal

On Thu, May 16, 2013 at 1:29 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Thu, May 16, 2013 at 7:16 PM, Luke Plant  wrote:
>
>> On 15/05/13 19:36, ptone wrote:
>>
>> > I wonder if a slightly more concise version of this should be added to
>> > the triaging docs instead of a wiki page (fine place to draft it
>> though).
>> >
>> >
>> https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#closing-tickets
>> >
>> > I feel that the wiki pages aren't very discoverable, and unless we are
>> > talking about patching trac to include this, such a comment won't carry
>> > the official weight of being in the project docs.
>>
>> That's a good idea. The purpose of this wiki page is to make it easy for
>> triagers to link to - I personally hate having to go and find the right
>> page in the docs, but I can remember to do "DevelopersMailingList"
>> instead of "developers mailing list".
>>
>> Patching Trac sounds like a really good idea to me. While I completely
> appreciate the intent of these wiki messages, the way those messages are
> "deployed" at the present strikes me as something that could easily be
> interpreted as rude. I'd like to see a much more "humane" usage of these
> messages, so that new users to Trac don't feel like they're interaction
> with Django as a project isn't a mechanical rejection.
>
> Yours,
> Russ Magee %-)
>
> --
> 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: Perception of attitude in tickets

[Luke Plant]

On 16/05/13 13:29, Russell Keith-Magee wrote:

> Patching Trac sounds like a really good idea to me. While I completely
> appreciate the intent of these wiki messages, the way those messages are
> "deployed" at the present strikes me as something that could easily be
> interpreted as rude. I'd like to see a much more "humane" usage of these
> messages, so that new users to Trac don't feel like they're interaction
> with Django as a project isn't a mechanical rejection.

What kind of patching Trac are we talking about? I'm aware of two
suggestions I think:

1) If someone tries to re-open a ticket, we change it so they see some
message about the mailing list.

2) When a ticket is closed, a message is automatically added.

To me, both of these seem *more* mechanical and unfriendly than a
message that is composed by hand (which may link to an existing wiki
page or other docs). The first particularly will lead to people closing
tickets as WONTFIX without sufficient explanation, and the user getting
a 'doorslam' feeling (and probably won't get to the point of attempting
to re-open a ticket).

Regards,

Luke

-- 
"If something is hard, it's not worth doing." (Homer Simpson)

Luke Plant || http://lukeplant.me.uk/

-- 
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: first() and last(), earliest() and latest()

[Lee Trout]

That's what I thought- But why not just qs[0]?

Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems that
the [:1] is unnecessary. I would expect both to raise IndexError.



On Wed, May 15, 2013 at 11:39 PM, Alex Ogier  wrote:

> Significantly better. The latter method loads every single model in the
> queryset into Python, potentially the whole database!
> On May 15, 2013 9:24 PM, "Lee Trout"  wrote:
>
>> Is qs[:1][0] better form than list(qs)[0]?
>>
>>
>> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong  wrote:
>>
>>> I've updated the first() and last() to not accept any arguments. Please
>>> review it and let me know if there's anything else I need to change.
>>> Hopefully this can get merged in during the sprints and make it into 1.6 :).
>>>
>>> The pull request is here: https://github.com/django/django/pull/1056
>>>
>>> Best,
>>> Selwin
>>>
>>> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:

 > > I initially modeled "first()" and "last()"'s behaviors to mimic
 > > "latest()", but in this new pull request, you can pass multiple
 field names
 > > into "first()" and "last()" so it behaves like "order_by()". It's
 more
 > > flexible and requires less typing, but I wonder if we should just
 get rid
 > > of the optional field arguments and rely on "order_by" for
 ordering. "There
 > > should be one-- and preferably only one --obvious way to do it".
 >
 > Considering "There should be one-- and preferably only one --obvious
 way to
 > do it", I definitely prefer to rely on order_by to do the ordering,
 not on
 > first.
 >
 > .order_by('name').first()
 >
 > is clear and readable in my opinion.

 My thoughts exactly, we already have one method that does ordering, I
 don't think it is necessary to make these methods incorporate that
 functionality. If we did, we might argue that other QuerySet
 operations could be supported as well and that would just result in a
 bloated API. Especially if there's no performance gain (the QuerySet
 would be cloned anyway), and it only saves a few lines of code.

 Also, skimming through this thread, I think there was a consensus on
 first() and last() not taking any ordering arguments, i.e. the first
 proposed syntax:

 .filter(last_name__startswith=**'b').order_by('last_name').**first()


 Michal

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

-- 
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: first() and last(), earliest() and latest()

[Lee Trout]

Let me clarify that I would expect both qs[:1][0] and qs[0] to raise
IndexError if there were no results.


On Thu, May 16, 2013 at 11:05 AM, Lee Trout  wrote:

> That's what I thought- But why not just qs[0]?
>
> Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems that
> the [:1] is unnecessary. I would expect both to raise IndexError.
>
>
>
> On Wed, May 15, 2013 at 11:39 PM, Alex Ogier  wrote:
>
>> Significantly better. The latter method loads every single model in the
>> queryset into Python, potentially the whole database!
>>  On May 15, 2013 9:24 PM, "Lee Trout"  wrote:
>>
>>> Is qs[:1][0] better form than list(qs)[0]?
>>>
>>>
>>> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong wrote:
>>>
 I've updated the first() and last() to not accept any arguments. Please
 review it and let me know if there's anything else I need to change.
 Hopefully this can get merged in during the sprints and make it into 1.6 
 :).

 The pull request is here: https://github.com/django/django/pull/1056

 Best,
 Selwin

 On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>
> > > I initially modeled "first()" and "last()"'s behaviors to mimic
> > > "latest()", but in this new pull request, you can pass multiple
> field names
> > > into "first()" and "last()" so it behaves like "order_by()". It's
> more
> > > flexible and requires less typing, but I wonder if we should just
> get rid
> > > of the optional field arguments and rely on "order_by" for
> ordering. "There
> > > should be one-- and preferably only one --obvious way to do it".
> >
> > Considering "There should be one-- and preferably only one --obvious
> way to
> > do it", I definitely prefer to rely on order_by to do the ordering,
> not on
> > first.
> >
> > .order_by('name').first()
> >
> > is clear and readable in my opinion.
>
> My thoughts exactly, we already have one method that does ordering, I
> don't think it is necessary to make these methods incorporate that
> functionality. If we did, we might argue that other QuerySet
> operations could be supported as well and that would just result in a
> bloated API. Especially if there's no performance gain (the QuerySet
> would be cloned anyway), and it only saves a few lines of code.
>
> Also, skimming through this thread, I think there was a consensus on
> first() and last() not taking any ordering arguments, i.e. the first
> proposed syntax:
>
> .filter(last_name__startswith=**'b').order_by('last_name').**first()
>
>
> Michal
>
  --
 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.
>>
>>
>>
>
>

-- 
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: django and paramstyle: what's the actual story?

[Aymeric Augustin]

On 16 mai 2013, at 09:29, VernonCole  wrote:

> What is the feeling of this group?  Should I maintain my activism that %s 
> 'format' paramstyle be maintained into the future?  Or should I be helping 
> the django community to prepare for a new future where one must (or may?) 
> choose between a parameter list with "?" or a parameter mapping with 
> ":paramname"?  Personally, I do not really like the '%s' style would be happy 
> if it goes away.  What do you think?


The consequences for Django sound rather benign to me. I wouldn't worry too 
much.

If there's a new version of the DB API that standardize parameter style, I'll 
most likely advocate following it.

I also dislike the '%s' style because it interacts badly with string 
interpolation as soon as you try displaying the query, for instance in 
DebugCursorWrapper.

-- 
Aymeric.

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

Questions about ticket #19431

[Pablo Recio]

Hi guys,

Some months ago I submitted a pull
request for
the ticket #19431 . Even it's
a really small thing, didn't get the time until now (DjangoCon, yay!) to go
through last of Florian's reviews.

How should I tackle that? My initial thought was to use `settings.
DATETIME_INPUT_FORMATS`
for picking wich format the admin should accept. And as far as I know, the
activated locale will put the local formats in the top of that list, so
they will be picked first.

Shall I maybe add more tests covering the locale thing? Or shall I use just
ISO-format strings?

Thanks,

-- 
Pablo Recio

-- 
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: django and paramstyle: what's the actual story?

[Shai Berger]

On Thursday 16 May 2013, VernonCole wrote:
> I noticed in a recent post that there is an outstanding patch for Oracle
> for support of 'named' paramstyle.
> 

As the author of that patch, I should probably clarify that it is a "format" 
style -- %(name)s -- not a "named" -- :name -- style.

AFAIK, that style is currenly supported by all core django backends (well, 
except Oracle, of course); I know our code which uses it has been successfully 
run against SQLite and Postgres, and I suspect django-pyodbc also supports it. 
It has its problems, both with respect to Python string interpolation and to 
SQL's pattern operator, but AFAIK it is the most common in use.

-- 
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: Proposal: Redefine specific {% block %} in an intermediate template

[Emil Stenström]

Any feedback on how I was thinking? Does it make sense? 

Based on the feedback so far I gather that changing the block tag is a bad 
idea. I'd love to continue working on this, because I've felt this need in 
lots of different projects. A new proposal could be in terms of a new pair 
of tags, maybe "layout" and "content". But before going further I would 
love some thoughts on the area, and if you think it's a worthwhile problem 
to solve.

/Emil

On Wednesday, 17 April 2013 23:56:40 UTC+2, Emil Stenström wrote:
>
> Jacob Kaplan-Moss skrev 2013-04-17 18:36: 
> > On Wed, Apr 17, 2013 at 10:50 AM, Emil Stenström  wrote: 
> >> {% extends "base.html" %} 
> >> {% block content %} 
> >>  Be careful when changing these 
> settings! 
> >>  {% block content %}{% endblock %} 
> >> {% endblock %} 
> > 
> > I find this intensely confusing -- I can't build a mental model of 
> > what's going to be rendered there. Allowing re-definining of existing 
> > blocks nested inside those blocks... ouch. I'm -1 on allowing this; it 
> > just seems incredibly confusing and error prone. 
>
> The mental model I have, and that I've seen many beginners have when 
> comming from other languages, is that the outmost tag is what you're 
> "filling in", and the innermost block is what you're making available 
> for child templates. 
>
> ASP.Net: 
> Parent:  
> Child:  ... 
>  
>
> JSF: 
> Parent:  
> Child:  ...  
>
> Rails: 
> Parent: <%= yield :head %> 
> Child: <% content_for :head do %> ... <% end %> 
>
> I'm not saying I think you should differetiate the two, just explaining 
> my mental model. The big difference is of course that I'm separating 
> what a template consumes and what it makes a block available to child 
> templates. 
>
> I understand the differences to your mental model, that nested blocks 
> are also available to child templates. 
>
> > The general way I've solved this in the past is pretty straightforward:: 
> > 
> >  {% block content-wrapper %} 
> >  Be careful when changing these 
> settings! 
> >  {% block content %}{% endblock %} 
> >  {% endblock %} 
> > 
> > What's wrong with this? 
>
> This is "Alternative 1" in my original message, sorry if this was 
> unclear. Say I change base.html to have a content-wrapper block, and put 
> your code in base_with_warning. Half my templates inherit from base and 
> half from base_with_warning. Now when I decide I want to add a warning 
> to a template that previously didn't have one, I change parent template 
> AND need to remember to rename the block to content instead of 
> content-wrapper. The "rename block"-part is the difference between our 
> two variants. 
>
> In projects with lots of templates, this quickly becomes a maintainance 
> nightmare. People forget the change the block name, and accidentially 
> don't get the warning they expect, even though they are explicitly 
> inheriting from base_with_warning. It's a mess. 
>
> This is the problem I'm trying to solve with my proposal. I agree it's 
> slightly backwards, but I couldn't come up with a smarter way. 
>
> /Emil 
>

-- 
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: first() and last(), earliest() and latest()

[Alex Ogier]

QuerySets don't support indexing. I'm not entirely sure why, but I
think the reason is to encourage more efficient database usage, since
naive usage of indexing would lead to many repeated LIMIT 1 OFFSET N
type queries. Forcing people to slice first encourages them to think
about exactly how many results they need and evaluate them all at
once.

On Thu, May 16, 2013 at 11:06 AM, Lee Trout  wrote:
> Let me clarify that I would expect both qs[:1][0] and qs[0] to raise
> IndexError if there were no results.
>
>
>
> On Thu, May 16, 2013 at 11:05 AM, Lee Trout  wrote:
>>
>> That's what I thought- But why not just qs[0]?
>>
>> Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems that
>> the [:1] is unnecessary. I would expect both to raise IndexError.
>>
>>
>>
>> On Wed, May 15, 2013 at 11:39 PM, Alex Ogier  wrote:
>>>
>>> Significantly better. The latter method loads every single model in the
>>> queryset into Python, potentially the whole database!
>>>
>>> On May 15, 2013 9:24 PM, "Lee Trout"  wrote:

 Is qs[:1][0] better form than list(qs)[0]?


 On Wed, May 15, 2013 at 7:48 AM, Selwin Ong 
 wrote:
>
> I've updated the first() and last() to not accept any arguments. Please
> review it and let me know if there's anything else I need to change.
> Hopefully this can get merged in during the sprints and make it into 1.6 
> :).
>
> The pull request is here: https://github.com/django/django/pull/1056
>
> Best,
> Selwin
>
> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>>
>> > > I initially modeled "first()" and "last()"'s behaviors to mimic
>> > > "latest()", but in this new pull request, you can pass multiple
>> > > field names
>> > > into "first()" and "last()" so it behaves like "order_by()". It's
>> > > more
>> > > flexible and requires less typing, but I wonder if we should just
>> > > get rid
>> > > of the optional field arguments and rely on "order_by" for
>> > > ordering. "There
>> > > should be one-- and preferably only one --obvious way to do it".
>> >
>> > Considering "There should be one-- and preferably only one --obvious
>> > way to
>> > do it", I definitely prefer to rely on order_by to do the ordering,
>> > not on
>> > first.
>> >
>> > .order_by('name').first()
>> >
>> > is clear and readable in my opinion.
>>
>> My thoughts exactly, we already have one method that does ordering, I
>> don't think it is necessary to make these methods incorporate that
>> functionality. If we did, we might argue that other QuerySet
>> operations could be supported as well and that would just result in a
>> bloated API. Especially if there's no performance gain (the QuerySet
>> would be cloned anyway), and it only saves a few lines of code.
>>
>> Also, skimming through this thread, I think there was a consensus on
>> first() and last() not taking any ordering arguments, i.e. the first
>> proposed syntax:
>>
>> .filter(last_name__startswith='b').order_by('last_name').first()
>>
>> Michal
>
> --
> 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.
>>>
>>>
>>
>>
>
> --
> 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

Re: first() and last(), earliest() and latest()

[Alex Gaynor]

Querysets definitely support indexing.

Alex


On Thu, May 16, 2013 at 2:51 PM, Alex Ogier  wrote:

> QuerySets don't support indexing. I'm not entirely sure why, but I
> think the reason is to encourage more efficient database usage, since
> naive usage of indexing would lead to many repeated LIMIT 1 OFFSET N
> type queries. Forcing people to slice first encourages them to think
> about exactly how many results they need and evaluate them all at
> once.
>
> On Thu, May 16, 2013 at 11:06 AM, Lee Trout  wrote:
> > Let me clarify that I would expect both qs[:1][0] and qs[0] to raise
> > IndexError if there were no results.
> >
> >
> >
> > On Thu, May 16, 2013 at 11:05 AM, Lee Trout  wrote:
> >>
> >> That's what I thought- But why not just qs[0]?
> >>
> >> Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems
> that
> >> the [:1] is unnecessary. I would expect both to raise IndexError.
> >>
> >>
> >>
> >> On Wed, May 15, 2013 at 11:39 PM, Alex Ogier 
> wrote:
> >>>
> >>> Significantly better. The latter method loads every single model in the
> >>> queryset into Python, potentially the whole database!
> >>>
> >>> On May 15, 2013 9:24 PM, "Lee Trout"  wrote:
> 
>  Is qs[:1][0] better form than list(qs)[0]?
> 
> 
>  On Wed, May 15, 2013 at 7:48 AM, Selwin Ong 
>  wrote:
> >
> > I've updated the first() and last() to not accept any arguments.
> Please
> > review it and let me know if there's anything else I need to change.
> > Hopefully this can get merged in during the sprints and make it into
> 1.6 :).
> >
> > The pull request is here: https://github.com/django/django/pull/1056
> >
> > Best,
> > Selwin
> >
> > On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
> >>
> >> > > I initially modeled "first()" and "last()"'s behaviors to mimic
> >> > > "latest()", but in this new pull request, you can pass multiple
> >> > > field names
> >> > > into "first()" and "last()" so it behaves like "order_by()".
> It's
> >> > > more
> >> > > flexible and requires less typing, but I wonder if we should
> just
> >> > > get rid
> >> > > of the optional field arguments and rely on "order_by" for
> >> > > ordering. "There
> >> > > should be one-- and preferably only one --obvious way to do it".
> >> >
> >> > Considering "There should be one-- and preferably only one
> --obvious
> >> > way to
> >> > do it", I definitely prefer to rely on order_by to do the
> ordering,
> >> > not on
> >> > first.
> >> >
> >> > .order_by('name').first()
> >> >
> >> > is clear and readable in my opinion.
> >>
> >> My thoughts exactly, we already have one method that does ordering,
> I
> >> don't think it is necessary to make these methods incorporate that
> >> functionality. If we did, we might argue that other QuerySet
> >> operations could be supported as well and that would just result in
> a
> >> bloated API. Especially if there's no performance gain (the QuerySet
> >> would be cloned anyway), and it only saves a few lines of code.
> >>
> >> Also, skimming through this thread, I think there was a consensus on
> >> first() and last() not taking any ordering arguments, i.e. the first
> >> proposed syntax:
> >>
> >> .filter(last_name__startswith='b').order_by('last_name').first()
> >>
> >> Michal
> >
> > --
> > 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.

Re: first() and last(), earliest() and latest()

[Selwin Ong]

Hi Shai,

We can add args and kwargs later when it's actually needed, it's not needed 
right now and it' cleaner, I think.

As for "only=True", these methods are meant to replace "latest()". If someone 
ones to ensure that the queryset returns only one object,  I dont think 
"Queryset.get()" is going anywhere soon so they should use that. Besides, 
"first()" and "last()" don't really make sense if you expect a queryset to only 
return a single object - ordering doesn't matter.

That's just what I think though.

Best,
Selwin

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