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

[Selwin Ong]

Hi everyone,

I opened a new pull request implementing Shai's suggestions (I didn't 
overwrite the current branch so we can still compare the two 
implementations if needed).

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

Thoughts?

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

Best,
Selwin

On Sunday, May 12, 2013 4:23:33 AM UTC+7, Shai Berger wrote:
>
> Hi Selwin, 
>
> On Saturday 11 May 2013, Selwin Ong wrote: 
> > Hi everyone, 
> > 
> > I submitted a pull request implementing "first()" and "last()" here: 
> >  https://github.com/django/django/pull/1054 
> > 
> > Comments welcome! 
> > 
> You implemented the "order_by" parameter as taking only one field name; 
> this is 
> inconsistent with the way ordering is done elsewhere  -- both the queryset 
> order_by() method, and the model meta ordering option, take a list of 
> field 
> names, each optionally prefixed by "-". 
>
> While I can see reason in going for a simpler implementation, I think it 
> is 
> much preferable to have a consistent API; and even if the simpler 
> implementation is preferred, you should take care of a more friendly error 
> message for someone who would call qset.first("a","b") or even 
> qset.last("-a") 
> [the latter may seem to make no sense -- "if that's what you want, call 
> qset.first('a')" -- but may reasonably arise in situations where the 
> ordering 
> field is received as an argument]. 
>
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Anssi Kääriäinen]

On 12 touko, 02:55, Russell Keith-Magee 
wrote:
> To that end - I want to make sure that we're clear about what we're talking
> about here.
>
> What is on the table is essentially adding a refresh() call on an object
> instance that is an API analog of ".get(id=self.id)" (although the
> implementation will need to do a bit more than that).

Concrete API proposal: Model.refresh() reloads all non-deferred local
field values (that is, all fields in the current model which have a
database column). In addition refresh() will make sure that cached
values dependent of the reloaded values will be cleared. That is, if
you do foo.refresh(), then when foo.user_id is reloaded foo.user will
be cleared (assuming the reloaded user_id is different from the
original value). This is to ensure that next access to foo.user will
reload the related object, too.

The refresh() method makes sure descriptors are honored, for example
custom field's to_python() method will be called for refreshed values.

The refresh() method accepts *args, so that one can specify which
fields to reload. This is useful so that deferred attribute loading
can use refresh(), and by overriding refresh() it will be possible to
customize how deferred loading happens.

Deferred field loading is altered to use .refresh().

It might be useful to add model.deferred_fields property. The property
returns a set of currently deferred fields in the instance. If this
was available it would be easy to force reload of all currently
deferred fields, but no reload of other fields. This would also be
useful for loading all deferred fields when any deferred field is
accessed. But this can wait for later...

Does the proposal look acceptable?

 - Anssi

-- 
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: reconsider re-opening ticket 901

[Alex Ogier]

On Sat, May 11, 2013 at 7:55 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> I'm sure I understand this argument. Python objects are passed around by
> reference, not by value, so if you've passed in a Django object deep into
> another library, that library will be pointing at the same instance. If the
> instance is changed, everywhere holding a handle to that reference will be
> updated.
>

Yes, but that is not what foo = MyObj.objects.get(id=foo.id) does. That
assigns a new reference to a new object to the name foo. Other references,
even references to the same instance as foo, are not refreshed. This is
precisely why a .reload() method is useful -- what is wanted is to mutate
the instance that is referred to, not to create a new reference and assign
it to the old name.

To that end - I want to make sure that we're clear about what we're talking
> about here.
>
> What is on the table is essentially adding a refresh() call on an object
> instance that is an API analog of ".get(id=self.id)" (although the
> implementation will need to do a bit more than that).
>

It's not really the same at all, .reload() or .refresh() would the existing
instance in place. It's more akin to foo.__dict__ = MyObj.objects.get(id=
foo.id).__dict__

Best,
Alex Ogier

-- 
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: reconsider re-opening ticket 901

[Andrew Ingram]

On 12 May 2013, at 00:55, Russell Keith-Magee  wrote:
> I'm sure I understand this argument. Python objects are passed around by 
> reference, not by value, so if you've passed in a Django object deep into 
> another library, that library will be pointing at the same instance. If the 
> instance is changed, everywhere holding a handle to that reference will be 
> updated.
> 
> To that end - I want to make sure that we're clear about what we're talking 
> about here. 
> 
> What is on the table is essentially adding a refresh() call on an object 
> instance that is an API analog of ".get(id=self.id)" (although the 
> implementation will need to do a bit more than that).
> 
> We are *not* talking about ticket #17, object instance caching. Calling 
> refresh() *will not* update *every* instance of a given object. The following 
> would be the effective API:
> 
> >>> a = MyObj.objects.get(id=42)
> >>> a.message = 'hello'
> >>> a.save()
> >>> b = MyObj.objects.get(id=42)
> >>> c = MyObj.objects.get(id=42)
> 
> >>> a.message = 'goodbye'
> >>> a.save()
> >>> print b.message
> 'hello'
> >>> b.refresh()
> >>> print b.message
> 'goodbye'
> >>> print c.message
> 'hello'

I was under the impression that the suggested use case was more like this:

>>> a = MyObj.objects.get(id=42)
>>> a.message = 'hello'
>>> b = {'obj': a}
>>> print b['obj'].message
'hello'
>>> c = MyObj.objects.get(id=42)
>>> c.message = 'goodbye'
>>> c.save()
>>> a = MyObj.objects.get(id=42)  # existing 'workaround', gives us a new 
>>> instance
>>> print a.message
'goodbye'
>>> print b['obj'].message  # b['obj'] still points to the original instance `a`
'hello'

If a reload() method existed, `a` could have been reloaded with `a.reload()`, 
and then `b['obj']` would have been up-to-date as well. As it stands, every 
reference to `a` has to be explicitly re-fetched from the database.

Am I missing something obvious?


- Andy

-- 
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 Sat, May 11, 2013 at 3:47 PM, Wim Feijen  wrote:

> Hi Simon, Luke and Aymeric,
>
> Simon, first of all, thanks for your feedback.
>
> Core developers, I think Simons comment is a thing we should take
> seriously. A ticket was closed and people didn't understand the process and
> re-opened it. I believe we could have explained more clearly:
> 1. our decision
> 2. the workaround
> 3. how exactly the mailing list works.
>
> Instead this ticket ended up into an argument about re-opening this
> ticket, where people apparently weren't familiar with the process and did
> not know the proper steps to raise this to the e-mailing list which was of
> course the best step to get this ticket any further.
>

Looking for a positive outcome here -- my question to the community, and
especially those that feel that we've been unresponsive here: how do we
improve the situation?

In this case, the requested course of action was very clear, and was
communicated clearly on three occasions. We also have a contributions
document that clearly documents our development process. The reason we have
this document is because we don't have the spare resources to reproduce the
same discussion every time the same problem arises. We get a dozen tickets
a day; and a good proportion of those end up being closed.

So - as clear as we think we've made the process, clearly "the message"
didn't get through here. How do we fix this?

Keep in mind when you're making suggestions, we have a certain number of
constraints. We're all volunteers, so we don't have the power to compel
anyone to do anything. We dot have the resources to micromanage every
decision, so we need to have processes that are essentially self-managing.
And keep in mind that one of the outcomes of every discussion about adding
a new feature is "no" - just because someone *really* wants something, and
*really* thinks it's a good idea, that doesn't mean we have to agree.

For me, the best way to proceed seems to raise this ticket to the mailing
> list and I will do so in a separate thread.
>
> Core devs, Aymeric, Luke, know that I have high esteem for the django
> community and especially for you. I thank you for your time and dedication
> to Django, your responsiveness and willingness to help newcomers and
> discuss even trivial details, which I truely admire; and the friendly
> atmosphere and openess and willingness to take seriously almost every
> remark a know-nothing like me can make, which I value highly.
>
> Simon, the "jacob" you are speaking about is Jacob Kaplan-Moss, one of the
> founders of django and since then our benevolent dictator, who has spent so
> much time on django and made this community as it is. In this case, maybe
> he could have spent a bit longer on his answer; but maybe he was triaging a
> hundred tickets and therefor a bit in a rush.
>
> Best regards,
>
> Wim
>
>
>
> On Saturday, 11 May 2013 00:41:12 UTC+2, Luke Plant wrote:
>>
>> Hi Simon,
>>
>> > I feel that the general attitude expressed in some of the tickets is
>> > poor. The one which prompted this post
>> > is 
>> > https://code.djangoproject.**com/ticket/901.
>> I think comment 20
>> > >
>> is a good
>> > demonstration of my point. A couple of users were getting frustrated at
>> > the lack of discussion/progress which resulted in a fairly
>> sanctimonious
>> > rant.
>>
>> I'm afraid I really couldn't disagree more with your characterisation of
>> this situation.
>>
>> If you just read the ticket, you'll find that different core developers
>> asked people to move discussion to the mailing list *3 times*, and quite
>> politely.
>>
>> Everyone who comments after that point either hasn't read or has decided
>> to ignore *3 requests* about how to get the ticket to progress. And to
>> add insult to the injury of having wasted people's time already, some
>> start adding comments about how feature requests for Django are a waste
>> of time.
>>
>> This is the height of rudeness, and if all they got was a sanctimonious
>> reply, they got better than they deserved.
>>
>> I'm not claiming that we couldn't do better in terms of our clarifying
>> our processes and so on, but I think you picked an example that
>> demonstrates exactly the opposite of what you claimed.
>>
>> Best regards,
>>
>> Luke
>>
>> --
>> "God demonstrates his love towards us in this, that while we were
>> still sinners, Christ died for us." (Romans 5:8)
>>
>> 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 

Re: reconsider re-opening ticket 901

[Russell Keith-Magee]

On Sat, May 11, 2013 at 4:03 PM, Wim Feijen  wrote:

> Hi,
>
> Following up on the discussion on:
>
> https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs
>
> I'd like to start a clear discussion about re-opening ticket 901.
> https://code.djangoproject.com/ticket/901
>
> Ticket 901 was marked 7 years ago as won't fix and has been subject of
> debate since.
>
> I must say that I for myself was looking for such a method until I found
> that foo = Foo.objects.get(id=foo.id) would work; which did not seem
> obvious to me then and now.
>

The existence of this workaround is probably the single biggest technical
reason that this ticket hasn't made any significant progress.


> Brandon put forward an argument, which is:
> reload() would cover an important use case that did not get a hearing in
> the above discussion: that you might already have handed the object off to
> some other library, which is keeping a reference from somewhere deep in its
> data structures for use when you make a final call to it. If one or more
> data structures that are being built already hold the object, then it is
> not reasonable to have to track down the object and try to swap in a new
> copy everywhere. There should be a simple way to have the existing object's
> attributes update in-place.
>

I'm sure I understand this argument. Python objects are passed around by
reference, not by value, so if you've passed in a Django object deep into
another library, that library will be pointing at the same instance. If the
instance is changed, everywhere holding a handle to that reference will be
updated.

To that end - I want to make sure that we're clear about what we're talking
about here.

What is on the table is essentially adding a refresh() call on an object
instance that is an API analog of ".get(id=self.id)" (although the
implementation will need to do a bit more than that).

We are *not* talking about ticket #17, object instance caching. Calling
refresh() *will not* update *every* instance of a given object. The
following would be the effective API:

>>> a = MyObj.objects.get(id=42)
>>> a.message = 'hello'
>>> a.save()
>>> b = MyObj.objects.get(id=42)
>>> c = MyObj.objects.get(id=42)

>>> a.message = 'goodbye'
>>> a.save()
>>> print b.message
'hello'
>>> b.refresh()
>>> print b.message
'goodbye'
>>> print c.message
'hello'

The only place I've had use for this sort of functionality is in test
suites, where the test setUp configures some objects, and then a test of a
view modifies that object. As a result of calling the view, the database
value is changed, but the object held by the test isn't modified in place.
In this situation, a call to refresh() would be a nice convenience.
However, it's a minor convenience; the "get by pk" trick works fine
everywhere I've had this problem.

and Anssi thinks it is a good idea to implement this.
>
> My question is, can we please re-open this ticket and/or discuss here what
> are the benefits and drawbacks of having a method reload() ?
>
> For clarity, this question is in no way meant to be offensive. And if you
> want to discuss personal views about this ticket or the behaviour of django
> community in general, I politely request you to do so at:
> https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs
>

Wim - You've done exactly what the core team has asked - you've started a
discussion. We're not opposed to discussion, and we're not opposed to
saying we're wrong if someone can make a strong case. Nothing you've done
or said here is offensive.

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: Triaging: Close as needsinfo

[Shai Berger]

On Sunday 12 May 2013, Łukasz Rekucki wrote:
> Hi,
> 
> On 11 May 2013 22:58, Shai Berger  wrote:
> > In
> > other communities, I have usually seen "needsinfo" as a ticket state,
> > rather
> > than a reason for closing; such tickets are then closed later, if enough
> > time
> > has passed and no further info is received.
> 
> To me that's just giving false hope for people viewing that ticket. If the
> ticket is open, there's a reasonable expectation that there is some action
> you can take to make it progress, but you most likely you can't as only the
> reporter has the needed info. 

I disagree; every person who encounters a problem consistent with the existing 
description, can provide more info. This is, IMO, the only real (rather than 
perceived) difference between closing as "needsinfo" and keeping the ticket in 
some sort of open limbo -- if someone else runs into the same problem, I'd 
rather they enhance an existing report than start a new one; and nobody looks 
at closed tickets.

> For bugs, "needsinfo" is almost identical to
> "cannot reproduce" (aka "worksforme") and I can't think of a reason to keep
> such a bug open.
> 

I hope I've given you one.

> Of course, there are people who will take everything personal. Even if it's
> getting your ticket closed by a stranger on a public bug tracker.

When people have already taken the trouble to file a ticket, if it is closed 
and the closure seems arbitrary and off-handed, they will be offended. I would 
be. Then again, I would actually read the comments on the ticket...

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Shai Berger]

[resend, reference included; sorrt for the noise]

On Saturday 11 May 2013, Anssi Kääriäinen wrote:
> 
>   - While it might seem trivial to implement reload()/refresh() when
> needed,

Indeed, it might; which is why I would assume many people have already done 
it. For these people, a new reload()/refresh() in core may go unnoticed or 
redundantly overridden. In the "test discovery" thread, Russel has mentioned 
an "upgrade checks" proposal[0] -- if it comes to fruition, and this ticket is 
reopened, I suggest that a check for pre-existing reoad/refresh methods on 
models be included in the upgrade check.

Shai.

[0] https://groups.google.com/d/msg/django-developers/0xuznNH7aP0/CCqyDTpWSj4J

-- 
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: reconsider re-opening ticket 901

[Shai Berger]

On Saturday 11 May 2013, Anssi Kääriäinen wrote:
> 
>   - While it might seem trivial to implement reload()/refresh() when
> needed,

Indeed, it might; which is why I would assume many people have already done 
it. For these people, a new reload()/refresh() in core may go unnoticed or 
redundantly overridden. In the "test discovery" thread, Russel has mentioned 
an "upgrade checks" proposal[0] -- if it comes to fruition, and this ticket is 
reopened, I suggest that a check for pre-existing reoad/refresh methods on 
models be included in the upgrade check.

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Triaging: Close as needsinfo

[Łukasz Rekucki]

Hi,

On 11 May 2013 22:58, Shai Berger  wrote:

> In
> other communities, I have usually seen "needsinfo" as a ticket state,
> rather
> than a reason for closing; such tickets are then closed later, if enough
> time
> has passed and no further info is received.
>

To me that's just giving false hope for people viewing that ticket. If the
ticket is open, there's a reasonable expectation that there is some action
you can take to make it progress, but you most likely you can't as only the
reporter has the needed info. For bugs, "needsinfo" is almost identical to
"cannot reproduce" (aka "worksforme") and I can't think of a reason to keep
such a bug open.

Of course, there are people who will take everything personal. Even if it's
getting your ticket closed by a stranger on a public bug tracker.

-- 
Łukasz Rekucki

-- 
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()

[Shai Berger]

Hi Selwin,

On Saturday 11 May 2013, Selwin Ong wrote:
> Hi everyone,
> 
> I submitted a pull request implementing "first()" and "last()" here:
>  https://github.com/django/django/pull/1054
> 
> Comments welcome!
> 
You implemented the "order_by" parameter as taking only one field name; this is 
inconsistent with the way ordering is done elsewhere  -- both the queryset 
order_by() method, and the model meta ordering option, take a list of field 
names, each optionally prefixed by "-".

While I can see reason in going for a simpler implementation, I think it is 
much preferable to have a consistent API; and even if the simpler 
implementation is preferred, you should take care of a more friendly error 
message for someone who would call qset.first("a","b") or even qset.last("-a") 
[the latter may seem to make no sense -- "if that's what you want, call 
qset.first('a')" -- but may reasonably arise in situations where the ordering 
field is received as an argument].

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Triaging: Close as needsinfo

[Shai Berger]

Hi Django devs,

I would like to raise a little concern I ran into lately. When going over some 
Oracle-related tickets, I came across ticket #20201[0] . The ticket 
description was missing important details, so I commented about them. A few 
days later, Aymeric came around, and closed the ticket as "needsinfo", 
referencing my comment. To me, this raised a couple of conflicting thoughts:

On one hand -- should I have closed it myself, and saved a core-dev the 
trouble? The triaging guide[1] seems very inconclusive about this, advising on 
other reasons to close tickets but not on needsinfo (except "tickets which are 
really feature requests").

On the other hand -- especially, in the wake of the "Perception of attitude in 
tickets" brouhaha -- should we really be closing tickets on needsinfo? In 
other communities, I have usually seen "needsinfo" as a ticket state, rather 
than a reason for closing; such tickets are then closed later, if enough time 
has passed and no further info is received. I realise that, when the person 
closing the ticket specifically says "when you have more info, please re-open" 
(as Aymeric did in this case), then the process is essentially the same, only 
a little more efficient; but I worry that this efficiency may carry a price in, 
as 
Simon put it, "perception of attitude in tickets". 

For what it's worth, I, personally, would feel much more at ease setting 
tickets as "needsinfo" without closing them -- and if it's a ticket state, 
there should be no problem taking such tickets out of the reports developers 
use, so they're almost as far out of the way as closed tickets.

Thanks for your consideration,

Shai.

[0] https://code.djangoproject.com/ticket/20201
[1] https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
tickets/

-- 
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: BCrypt + Python3

[Donald Stufft]

On May 11, 2013, at 4:10 AM, Claude Paroz  wrote:

> Le samedi 11 mai 2013 07:59:18 UTC+2, Donald Stufft a écrit :
> I went looking for BCrypt + Django + Python3 today and this is what I found: 
> 
> The current recommended solution to bcrypt + Django is using py-bcrypt which 
> is not compatible with Python3. 
> 
> Someone else has taken py-bcrypt and created py3k-bcrypt however they made 
> the decision to enforce having str instances sent in for password/salt 
> instead of bytes which makes it incompatible with Django's encode function on 
> the BCrypt password hashers[1]. 
> 
> So I created a library simply called `bcrypt`[2] which has the same API as 
> py-bcrypt but it functions on Python 2.6+ and 3.x (as well as PyPy 2.0 since 
> it's implemented via CFFI). When testing this against Python3 + Django I 
> discovered that Django isn't properly encoding/decoding when talking to the 
> external library so I made a patch that causes it to always send bytes to the 
> external library, and str's to other pats of Django. That can be found here: 
> https://github.com/django/django/pull/1052 
> 
> My bcrypt library is obviously new code but it's a small wrapper over 
> crypt_blowfish from OpenWall[3] and I'm wondering (assuming no one objects to 
> me merging my Patch) if it would make sense to switch the documentation away 
> from suggesting py-bcrypt and have it suggest bcrypt instead since it will 
> allow BCrypt to function on Python3 as well. 
> 
> Thoughts? 
> 
> [1] I believe this is inheriently wrong as bcrypt operates on bytes not on 
> unicode characters, and in order for this to work py3k-bcrypt must be 
> assuming a character set it can encode(). 
> [2] Found at https://crate.io/packages/bcrypt/ or 
> https://github.com/dstufft/bcrypt 
> [2] Found at http://www.openwall.com/crypt/ 
> 
> 
> Hi Donald,
> 
> There are several approaches in string handling in Python 3, being as content 
> input or output. As for me, I'm generally privileging unicode strings 
> whenever possible. See for example the Python hashlib behaviour for digest() 
> and hexdigest(): digest() returns a bytestring as it can return a full range 
> of bytes (0-255), while hexdigest() returns a string as the result is 
> guaranteed to be ASCII-safe.
> 
> Similarly I would have returned a string (unicode) from hashpw() as far as it 
> is guaranteed to be ASCII-safe. As for inputs, I think it is easy enough to 
> accept both bytestrings and strings, test them and encode('utf-8') when 
> needed.
> I recognize that it looks a bit odd on Python 2 to receive unicode when you 
> fed bytes to a method.
> 
> I'm not sure there is a "right" way, it's all about design and choice. Feel 
> free to ignore me :-)

As far as the return value from hashpw goes it's bytes primarily because the 
inputs to hashpw are expected to be bytes.

As far as the input values for hashpw goes, it accepts only bytes because 
bcrypt as an algorithm functions only on streams of bytes, not on unicode 
characters. Not every character in the world can be represented in utf-8 and I 
believe it's better for a library to require bytes (you can see the hashlib on 
python3 does this) than to make a possibly erroneous  guess.

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


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: test discovery

[Florian Apolloner]

On Saturday, May 11, 2013 2:38:23 PM UTC+2, Carl Meyer wrote:
>
> No good reason, just an oversight I think. If that's all that's needed to 
> make the CI happy, feel free to change it, should be a simple fix.
>

Perfect, pushed a fix, let's see what jenkins says. 

-- 
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: test discovery

[Carl Meyer]

Hi Florian,

On May 11, 2013, at 7:51 AM, Florian Apolloner  wrote:

> Hi Carl,
> 
> before I read all the tickets etc; why does runtests.py not use the 
> TEST_RUNNER from settings.py (see 
> https://github.com/django/django/commit/9012833af857e081b515ce760685b157638efcef#L60L149)?
>  We'd need that for jenkins to produce xml files as output.

No good reason, just an oversight I think. If that's all that's needed to make 
the CI happy, feel free to change it, should be a simple fix.

Carl

-- 
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: test discovery

[Florian Apolloner]

Hi Carl,

before I read all the tickets etc; why does runtests.py not use the 
TEST_RUNNER from settings.py (see 
https://github.com/django/django/commit/9012833af857e081b515ce760685b157638efcef#L60L149)?
 
We'd need that for jenkins to produce xml files as output.

Thanks,
Florian 

-- 
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()

[Selwin Ong]

Hi everyone,

I submitted a pull request implementing "first()" and "last()" here: 
 https://github.com/django/django/pull/1054

Comments welcome!

Best,
Selwin

On Thursday, February 28, 2013 5:34:16 AM UTC+7, Wim Feijen wrote:
>
> Hi all,
>
> We struggled to get a proper definition for a first() and last() method 
> vs. earliest() and latest() . I'd like to make one proposal. After that, I 
> really like your opinion on which syntax you prefer.
>
> First, let me give you a lenghty introduction. We discussed several use 
> cases on this mailing 
> list.
>  
> Then, I realized that:
>
> .filter(last_name__startswith='b').order_by('last_name').first()
> is an acceptable compromise for me to use in stead of:
> .first(last_name__startswith='b').order_by('last_name')
>
> Last weekend Aymeric explained to me that earliest can actually accomplish 
> the same:
> .filter(last_name__startswith='b').earliest('last_name')
>
> Then, I find "earliest" an inappropriate name, because it does not 
> describe functioning well.
>
> Therefore, my proposal is, if we are going to implement the earliest and 
> latest method, we should definitely rename them to: first and latest.
>
> After that, there is only one question left:
>
> Which style do you prefer?
>
> .filter(last_name__startswith='b').order_by('last_name').first()# 
> clear and long
> .first(last_name__startswith='b').order_by('last_name')# first method 
> has filter syntax.
> .filter(last_name__startswith='b').first('last_name')   # first method has 
> order_by syntax.
>
> So, what do you think?
>
> Best regards,
>
> Wim
>

-- 
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: test discovery

[Florian Apolloner]

Not good, at least our Jenkins runner which should generate xml output 
doesn't like it :/

On Saturday, May 11, 2013 5:36:55 AM UTC+2, Carl Meyer wrote:
>
> I merged this patch tonight. Thanks to everyone who contributed! Now let's 
> see how the CI servers feel about it...
>
> Carl
>
> On Wednesday, May 8, 2013 5:00:56 PM UTC-4, Carl Meyer wrote:
>>
>> Preston Timmons and I have been working the last several weeks to get 
>> the test discovery branch (#17365) ready for merge, and I think we now 
>> have a pull request ready for consideration: 
>> https://github.com/django/django/pull/1050 
>>
>> Brief summary of the features, changes, and open questions: 
>>
>> * You can now place tests in any file matching the pattern 'test*.py', 
>> anywhere in your codebase, rather than only in tests.py and models.py 
>> modules of an INSTALLED_APP. The filename pattern is customizable via 
>> the --pattern argument to "manage.py test". 
>>
>> * When you run "manage.py test" with no arguments, tests are discovered 
>> and run in all subdirectories (recursively) of the current working 
>> directory. (This means that django.contrib and other third-party app 
>> tests are no longer run by default). 
>>
>> * When you pass arguments to "manage.py test", they are now full Python 
>> dotted module paths. So if you have a "myproject.myapp" app, and its 
>> tests.py contains "SomeTestCase", you would now run that single test 
>> case via "manage.py myproject.myapp.tests.SomeTestCase" rather than 
>> "manage.py myapp.SomeTestCase". This is longer, but allows more control 
>> when an app's tests are split into multiple files, and allows for tests 
>> to be placed anywhere you like. 
>>
>> * Doctests are no longer discovered by default; you will need to 
>> explicitly integrate them with your test suite as recommended in the 
>> Python docs: http://docs.python.org/2/library/doctest.html#unittest-api 
>>
>> * Tests in models.py and tests/__init__.py will no longer be discovered 
>> (as those don't match the default filename pattern). 
>>
>> * The old test runner, and Django's extensions to the doctest module, 
>> are deprecated and will be removed in Django 1.8; they could of course 
>> be packaged separately if some people would like to continue using them. 
>>
>> Open question: how to handle the transition? 
>>
>> Jacob has suggested that back-compat breaks in test-running are not as 
>> serious as in production code, and that we should just switch to the new 
>> test runner by default in Django 1.6. This is what the pull request 
>> currently does. This will mean that some people's test suites will 
>> likely be broken when they upgrade to 1.6. They would have two options, 
>> both documented in the release notes: they can update their test suite 
>> to be discovery-compatible immediately, or they can just set TEST_RUNNER 
>> to point to the old runner and get back the old behavior, which they can 
>> keep using until Django 1.8 (or longer, if they package the old runner 
>> externally). 
>>
>> The alternative would be to keep the old test runner as the default in 
>> global_settings.py until it is removed in 1.8, and add the new runner as 
>> the TEST_RUNNER in the startproject-generated settings.py. This would 
>> provide a gentler transition for upgrading projects. On the other hand, 
>> we just recently got the startproject settings.py all cleaned-up, 
>> slimmed-down, and newbie-friendly, so it would make me sad to start 
>> polluting it again with stuff that new projects generally shouldn't care 
>> about, for solely legacy reasons. 
>>
>> Thoughts, questions, comments, code review and testing welcome! I'd like 
>> to merge this on Friday (it's a bear to keep updated with trunk), so let 
>> me know if you need longer. 
>>
>> Carl 
>>
>

-- 
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: reconsider re-opening ticket 901

[Anssi Kääriäinen]

On 11 touko, 11:03, Wim Feijen  wrote:
> Hi,
>
> Following up on the discussion 
> on:https://groups.google.com/forum/?fromgroups=#!topic/django-developers...
>
> I'd like to start a clear discussion about re-opening ticket 
> 901.https://code.djangoproject.com/ticket/901
>
> Ticket 901 was marked 7 years ago as won't fix and has been subject of
> debate since.
>
> I must say that I for myself was looking for such a method until I found
> that foo = Foo.objects.get(id=foo.id) would work; which did not seem
> obvious to me then and now.
>
> Brandon put forward an argument, which is:
> reload() would cover an important use case that did not get a hearing in
> the above discussion: that you might already have handed the object off to
> some other library, which is keeping a reference from somewhere deep in its
> data structures for use when you make a final call to it. If one or more
> data structures that are being built already hold the object, then it is
> not reasonable to have to track down the object and try to swap in a new
> copy everywhere. There should be a simple way to have the existing object's
> attributes update in-place.
>
> and Anssi thinks it is a good idea to implement this.

The reasons why I think a reload() or refresh() method is a good idea:
  - The above mentioned fact that if foo is already in data structure,
then you can't just reassign to foo. This is more and more an issue in
Django itself due to caching of related objects and
prefetch_related().
  - If you are in some of the model's methods you can't do self =
qs.get(pk=self.pk), more generally reassignment in any method/function
will not refresh the object in the caller of the method/function.
  - We could implement deferred loading using reload/refresh(), and
thus allow for a way to customize how deferred loading happens. An
example is the idea of loading all fields at a time instead of the
current default of loading one deferred field at a time.
  - This could also work as a way for allowing related objects cache
invalidation. The related objects are cached on first access, and
after that you don't have any way to force reload of the cached
object. (Maybe separate issue to be dealt with later on. But refresh()
as a name, and then eventually adding cached object invalidation seems
like a good idea to me.)
  - While it might seem trivial to implement reload()/refresh() when
needed, there are some bugs waiting to happen:
- Not going through setattr() - if you assign to self.__dict__
directly you might miss __setattr__ or a descriptor's __set__ (this is
a problem for custom fields defining to_python() for example).
- Reloading fields for deferred models with qs.values() doesn't
work correctly. Django uses descriptors for both to_python()
conversion and for deferred fields implementation, so if you use
values() to_python() will not be called for deferred fields as the
deferred descriptor overrides the normal descriptor. See SubfieldBase
or FileField for problematic cases.
- Not handling field.attname/field.name distinction correctly. For
example consider self.user.pk vs self.user_id. If you reload user_id,
but don't invalidate self.user the values will not necessarily match.

> My question is, can we please re-open this ticket and/or discuss here what
> are the benefits and drawbacks of having a method reload() ?

Benefits mentioned above, the only drawback I can see is the addition
of one more method to Model API. So, +1 from me to the feature.

 - Anssi

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

reconsider re-opening ticket 901

[Wim Feijen]

Hi,

Following up on the discussion on:
https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs

I'd like to start a clear discussion about re-opening ticket 901.
https://code.djangoproject.com/ticket/901 

Ticket 901 was marked 7 years ago as won't fix and has been subject of 
debate since.

I must say that I for myself was looking for such a method until I found 
that foo = Foo.objects.get(id=foo.id) would work; which did not seem 
obvious to me then and now.

Brandon put forward an argument, which is: 
reload() would cover an important use case that did not get a hearing in 
the above discussion: that you might already have handed the object off to 
some other library, which is keeping a reference from somewhere deep in its 
data structures for use when you make a final call to it. If one or more 
data structures that are being built already hold the object, then it is 
not reasonable to have to track down the object and try to swap in a new 
copy everywhere. There should be a simple way to have the existing object's 
attributes update in-place.

and Anssi thinks it is a good idea to implement this.

My question is, can we please re-open this ticket and/or discuss here what 
are the benefits and drawbacks of having a method reload() ?

For clarity, this question is in no way meant to be offensive. And if you 
want to discuss personal views about this ticket or the behaviour of django 
community in general, I politely request you to do so at: 
https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs

Best regards, Wim

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

[Wim Feijen]

Hi Simon, Luke and Aymeric,

Simon, first of all, thanks for your feedback. 

Core developers, I think Simons comment is a thing we should take 
seriously. A ticket was closed and people didn't understand the process and 
re-opened it. I believe we could have explained more clearly:
1. our decision 
2. the workaround 
3. how exactly the mailing list works.

Instead this ticket ended up into an argument about re-opening this ticket, 
where people apparently weren't familiar with the process and did not know 
the proper steps to raise this to the e-mailing list which was of course 
the best step to get this ticket any further. 

For me, the best way to proceed seems to raise this ticket to the mailing 
list and I will do so in a separate thread. 

Core devs, Aymeric, Luke, know that I have high esteem for the django 
community and especially for you. I thank you for your time and dedication 
to Django, your responsiveness and willingness to help newcomers and 
discuss even trivial details, which I truely admire; and the friendly 
atmosphere and openess and willingness to take seriously almost every 
remark a know-nothing like me can make, which I value highly.

Simon, the "jacob" you are speaking about is Jacob Kaplan-Moss, one of the 
founders of django and since then our benevolent dictator, who has spent so 
much time on django and made this community as it is. In this case, maybe 
he could have spent a bit longer on his answer; but maybe he was triaging a 
hundred tickets and therefor a bit in a rush.

Best regards,

Wim 



On Saturday, 11 May 2013 00:41:12 UTC+2, Luke Plant wrote:
>
> Hi Simon, 
>
> > I feel that the general attitude expressed in some of the tickets is 
> > poor. The one which prompted this post 
> > is https://code.djangoproject.com/ticket/901. I think comment 20 
> >  is a good 
> > demonstration of my point. A couple of users were getting frustrated at 
> > the lack of discussion/progress which resulted in a fairly sanctimonious 
> > rant. 
>
> I'm afraid I really couldn't disagree more with your characterisation of 
> this situation. 
>
> If you just read the ticket, you'll find that different core developers 
> asked people to move discussion to the mailing list *3 times*, and quite 
> politely. 
>
> Everyone who comments after that point either hasn't read or has decided 
> to ignore *3 requests* about how to get the ticket to progress. And to 
> add insult to the injury of having wasted people's time already, some 
> start adding comments about how feature requests for Django are a waste 
> of time. 
>
> This is the height of rudeness, and if all they got was a sanctimonious 
> reply, they got better than they deserved. 
>
> I'm not claiming that we couldn't do better in terms of our clarifying 
> our processes and so on, but I think you picked an example that 
> demonstrates exactly the opposite of what you claimed. 
>
> Best regards, 
>
> Luke 
>
> -- 
> "God demonstrates his love towards us in this, that while we were 
> still sinners, Christ died for us." (Romans 5:8) 
>
> 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.