Re: The greatest proposal yet: rename this damn group

[Russell Keith-Magee]

On Fri, Sep 19, 2014 at 5:39 AM, Wim Feijen  wrote:

> Hi Russell,
>
> Is this an issue we should solve?
>
> Because I believe technology can help here. For example, by posing a
> question when a user is creating a ticket. Ask if it deals with security;
> then present two clear buttons: "Report a security issue" or "Report
> something else". (There might be better wordings). That will probably help
> a lot.
>
> Don'ts are probably not helpful, f.e. don't think of a yellow lemon.
>

Sure - we can fix it, as long as we rewrite the tool to take account of the
social use case. The proposal you've made here is a reasonable suggestion;
we might be able to come up with something even better if we gave it more
thought.

However, this doesn't account for the fact that this feature doesn't (to
the best of my knowledge) exist in Trac. So - we've either got to rewrite a
portion of Trac, write our own bug tracker, put some sort of shim around
the front of the ticket reporting process, or accept the limitations of the
tools we have.

Bringing it back to mailing lists - we could fix this problem by providing
a mechanism to migrate messages from one forum to another - but that isn't
a feature Google provides, either. So, we can rewrite our own mailing list
infrastructure, or make the most of the tools we have - accepting that the
tools have limitations. And for me, part of accepting that the mailing list
has limitations is accepting that it doesn't matter what you call it,
*someone* will post the wrong thing in the wrong place.

Humans, amirite? :-)

If someone is motivated to provide better solutions to either of these
problems, they certainly have my blessing - but keep in mind that the
Django project won't be migrating to a new bug tracker or mailing list tool
until that tool is a battle proven and self-sustaining project. We have
enough trouble getting enough volunteers to maintain development of Django
itself without also needing to recruit volunteers to keep our bug
tracker/mailing list running.

Russ %-)

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

Re: The greatest proposal yet: rename this damn group

[Russell Keith-Magee]

Hi Wim,

My apologies, this slipped through the cracks in my "returning from
DjangoCon US/annual post DjangoCon sickness" window. I've just mailed this
to the group for a decision.

Yours,
Russ Magee %-)

On Fri, Sep 19, 2014 at 5:31 AM, Wim Feijen  wrote:

> Hi Russell,
>
> Did you manage to speak to the technical board about renaming the group?
>
> Wim
>
> On Tuesday, 9 September 2014 03:49:21 UTC+2, Russell Keith-Magee wrote:
>>
>>
>> On Mon, Sep 8, 2014 at 11:24 PM, Carl Meyer  wrote:
>>
>>> On 09/08/2014 08:56 AM, Aymeric Augustin wrote:
>>> > 2014-09-08 16:21 GMT+02:00 Thomas Leo >> > >:
>>> >
>>> > +1 for django-contributors
>>> >
>>> >
>>> > That would be "Django Contributors" since we're talking about changing
>>> > the display name of the group, not its email address.
>>> >
>>> > It's a good proposal.
>>>
>>> I agree. I don't see any reason not to try this.
>>>
>>> Who has access to the Google Groups admin?
>>>
>>
>> I do.
>>
>> As a matter of formality, I'd like to put this through the technical
>> board so that it isn't just a fiat decision by the handful of people
>> motivated to participate in this discussion.
>>
>> Russ %-)
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a8c35fa3-20cb-4eb5-98bd-9791332630d5%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: The greatest proposal yet: rename this damn group

[Wim Feijen]

Hi Russell,

Is this an issue we should solve? 

Because I believe technology can help here. For example, by posing a 
question when a user is creating a ticket. Ask if it deals with security; 
then present two clear buttons: "Report a security issue" or "Report 
something else". (There might be better wordings). That will probably help 
a lot. 

Don'ts are probably not helpful, f.e. don't think of a yellow lemon.

Wim 

On Wednesday, 10 September 2014 01:56:43 UTC+2, Russell Keith-Magee wrote:
>
>
> On Tue, Sep 9, 2014 at 11:40 PM, Thomas Leo  > wrote:
>
>> +1 for @Wim Feijen's rewording but...
>>
>> I think the wording of the Group description isn't the issue, my guess is
>> that people who make the mistake of asking django-user's questions in the
>> django-developers mailing list didn't read the description to begin with.
>>
>> > They are almost all from people whose first language is clearly not 
>> English,
>>
>> I haven't been following this mailing list for a particularly long time, 
>> but I
>> can recall a number of cases where users were simply noobies looking for 
>> help,
>> and didn't reading the description of this mailing list before asking 
>> their
>> question.  Whether they are native English speakers or not, clearer 
>> wording
>> would mitigate the issue for everyone.
>>
>
> Let me dispel this illusion for you.
>
> If you go to Django's new ticket page:
>
> https://code.djangoproject.com/newticket
>  
> You are greeted with the following text:
>
> Please read this first:
> Please don't report security issues here! Contact 
> secu...@djangoproject.com  instead.
>
> This text is in bold, and is a hyperlink to a page describing Django's 
> security processes in detail.
>
> And yet, every couple of months, we get someone opening a ticket that 
> starts "I think I've found a security/DDOS issue in Django". The report 
> will be written in reasonably good english, so it isn't a language barrier 
> issue.
>
> This is what I meant when I said you can't solve a social problem with 
> technology. Yes, we might be able to improve the number of errors by 
> improving the text, but at some level, it doesn't matter how large you make 
> the "PLEASE DON'T PUSH THIS BUTTON" sign, someone is going to push the 
> button. It is folly to believe that the problem is that we just haven't 
> found the right descriptive text.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/98e09e4b-7a8d-46e2-83e4-7b2d2ed10854%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Wim Feijen]

Hi Russell,

Did you manage to speak to the technical board about renaming the group?

Wim

On Tuesday, 9 September 2014 03:49:21 UTC+2, Russell Keith-Magee wrote:
>
>
> On Mon, Sep 8, 2014 at 11:24 PM, Carl Meyer  > wrote:
>
>> On 09/08/2014 08:56 AM, Aymeric Augustin wrote:
>> > 2014-09-08 16:21 GMT+02:00 Thomas Leo > > >:
>> >
>> > +1 for django-contributors
>> >
>> >
>> > That would be "Django Contributors" since we're talking about changing
>> > the display name of the group, not its email address.
>> >
>> > It's a good proposal.
>>
>> I agree. I don't see any reason not to try this.
>>
>> Who has access to the Google Groups admin?
>>
>
> I do. 
>
> As a matter of formality, I'd like to put this through the technical board 
> so that it isn't just a fiat decision by the handful of people motivated to 
> participate in this discussion.
>
> Russ %-)
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a8c35fa3-20cb-4eb5-98bd-9791332630d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading timezone naive data into your test database with USE_TZ = True

[Wim Feijen]

Hi Robert, 

Timezones confuse me, maybe Aymeric can answer this one if he has time?

Off topic, your question might be a better fit for the django-users mailing 
list, but perhaps you posted to django-developers intentionally, because 
you are thinking of a bug report?

Wim


On Wednesday, 17 September 2014 01:54:13 UTC+2, Robert Rollins wrote:
>
> I have a legacy database from which my Django application must migrate 
> data into a Django database. The relevant dates fields are actually 
> TIMESTAMP columns in the database, but something (perhaps Django, or 
> python's MySQL driver?) loads these columns as timezone naive datetime 
> objects, rather than integers. So I wrote my migration code under the 
> assumption that the dates coming out of the legacy database are timezone 
> naive.
>
> Unfortunately, now that I'm trying to write tests for this migrator, I 
> can't find any way to load timezone naive datetimes into my test legacy 
> database. I can't use integer timestamps, because the DateTimeField doesn't 
> accept that kind of input (I get a JSON serialization error when I try), so 
> I'm using datetime strings like this: "2014-08-01T00:00:00" in my fixture. 
> But 
> regardless of whether or not I include a UTC offset in the string, the 
> datetime objects that come out of the database during my tests are somehow 
> timezone aware. This causes my code to crash because it calls make_aware(), 
> which throws ValueError('Not naive datetime (tzinfo is already set)'). 
>
> It seems like having USE_TZ = True is forcibly making my fixture dates 
> timezone aware, which I don't want. But USE_TZ will be True during the 
> actual migration, so I can't just turn it off during the tests. So how can 
> I load timezone naive dates into my test database?
>

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

Re: Should reverse() return a Unicode string?

[Wim Feijen]

Please do. :) 

- Wim

On Thursday, 18 September 2014 22:01:21 UTC+2, Jon Dufresne wrote:
>
> What do you think? If others agree, I can file a bug and create a pull 
> request to fix this. 
>  
>

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

Re: Should reverse() return a Unicode string?

[Carl Meyer]

Hi Jon,

On 09/18/2014 02:01 PM, Jon Dufresne wrote:
> In my Django application, I'm making a strong attempt to always deal
> with Unicode strings at the application layer. Byte strings are only
> handled at the protocol layer -- sending data out on the "wire". If my
> application tests if an object is a string, I'll use isinstance(obj,
> unicode) (Python2).
> 
> One gotcha that I noticed is that reverse() will always return a byte
> string. Tracing this through the code, I see this happens during the
> call to iri_to_uri(), as this function creates a string consisting
> only of ASCII characters, other characters are escaped.
> 
> Now, reverse() is often used to grab a URL and handle it at the
> application layer. It is not reserved only for the protocol layer. An
> example would be presenting a URL inside a HTML template, (as an href
> or as text), mail, or JSON.
> 
> In my opinion, reverse() should return a Unicode string, even if that
> string consists only of ASCII characters. It is not until the string
> hits the wire that it ought to be forced to bytes.
> 
> To verify this, I have created a unit test that I placed in
> "urlpatterns_reverse.tests.URLPatternReverse" to demonstrate this is
> at the Django layer.
> 
> def test_reverse_unicode(self):
> name, expected, args, kwargs = test_data[0]
> self.assertIsInstance(
> reverse(name, args=args, kwargs=kwargs),
> six.text_type)
> 
> What do you think? If others agree, I can file a bug and create a pull
> request to fix this.

It makes sense to me that `reverse()` should return a text (unicode)
string. A URL may be "just bytes" on the network, but within the Django
context it is clearly text.

I'm a bit concerned about the backwards-compatibility implications,
particularly for Python 3 projects where `bytes` and `str` don't
silently interoperate. It would be really interesting to hear if anyone
on this list has a real-world Python 3 Django project handy and could
test the impact of this change.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/541B4A79.9020109%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Should reverse() return a Unicode string?

[Jon Dufresne]

Hi,

In my Django application, I'm making a strong attempt to always deal
with Unicode strings at the application layer. Byte strings are only
handled at the protocol layer -- sending data out on the "wire". If my
application tests if an object is a string, I'll use isinstance(obj,
unicode) (Python2).

One gotcha that I noticed is that reverse() will always return a byte
string. Tracing this through the code, I see this happens during the
call to iri_to_uri(), as this function creates a string consisting
only of ASCII characters, other characters are escaped.

Now, reverse() is often used to grab a URL and handle it at the
application layer. It is not reserved only for the protocol layer. An
example would be presenting a URL inside a HTML template, (as an href
or as text), mail, or JSON.

In my opinion, reverse() should return a Unicode string, even if that
string consists only of ASCII characters. It is not until the string
hits the wire that it ought to be forced to bytes.

To verify this, I have created a unit test that I placed in
"urlpatterns_reverse.tests.URLPatternReverse" to demonstrate this is
at the Django layer.

def test_reverse_unicode(self):
name, expected, args, kwargs = test_data[0]
self.assertIsInstance(
reverse(name, args=args, kwargs=kwargs),
six.text_type)

What do you think? If others agree, I can file a bug and create a pull
request to fix this.

Thanks,
Jon

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

Re: Fwd: Django 1.7 polymorphism error

[Thiago Avelino]

Without PolymorphicModel he's the same error!

I'll write an example...



Cheers,
Thiago Avelino
@avelino0  - avelino.xxx

On Thu, Sep 18, 2014 at 12:11 PM, Carl Meyer  wrote:

> Hi Thiago,
>
> On 09/18/2014 08:51 AM, Thiago Avelino wrote:
> > I think I found a error polymorphism in django 1.7, field slug exist in
> > _meta.fields and run filter return error "FieldError: Cannot resolve
> > keyword 'slug' into field. Choices".
> >
> > Example: https://gist.github.com/avelino/793bdaf9f9732314912a
> >
> >
> > Slugged(abstract):
> >
> https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/core/models/core.py#L80
> >
> > Article(abstract):
> >
> https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/abstracts/articles.py#L12
> >
> > Post:
> >
> https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/types/posts.py#L8
> >
> > Container:
> >
> https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/models/core.py#L29
> >
> >
> > class Container(Publishable, Channeling):
> > class Article(Container, Slugged, Tagged):
> > class Post(Article):
> >
> > In Post not exist slug (on filtrer) and _meta.fields exist!
>
> It certainly looks like there's a bug there somewhere, but there's so
> much going on in your code (including inheriting from PolymorphicModel,
> a third-party base class) that it's hard to say where the bug might be
> (and whether it's even a bug in Django at all) without doing some direct
> exploration (i.e. using pdb to trace into the filter call and figure out
> exactly why a FieldError is being raised for 'slug' when a field of that
> name appears to exist). I think if you want a resolution here, you'll
> likely need to do that exploration yourself and try to narrow down the
> source of the bug so that you can reproduce it with a simplest-case
> example.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/541AF60D.6020502%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Fwd: Django 1.7 polymorphism error

[Carl Meyer]

Hi Thiago,

On 09/18/2014 08:51 AM, Thiago Avelino wrote:
> I think I found a error polymorphism in django 1.7, field slug exist in
> _meta.fields and run filter return error "FieldError: Cannot resolve
> keyword 'slug' into field. Choices".
> 
> Example: https://gist.github.com/avelino/793bdaf9f9732314912a
> 
> 
> Slugged(abstract):
> https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/core/models/core.py#L80
> 
> Article(abstract):
> https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/abstracts/articles.py#L12
> 
> Post:
> https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/types/posts.py#L8
> 
> Container:
> https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/models/core.py#L29
> 
> 
> class Container(Publishable, Channeling):
> class Article(Container, Slugged, Tagged):
> class Post(Article):
> 
> In Post not exist slug (on filtrer) and _meta.fields exist!

It certainly looks like there's a bug there somewhere, but there's so
much going on in your code (including inheriting from PolymorphicModel,
a third-party base class) that it's hard to say where the bug might be
(and whether it's even a bug in Django at all) without doing some direct
exploration (i.e. using pdb to trace into the filter call and figure out
exactly why a FieldError is being raised for 'slug' when a field of that
name appears to exist). I think if you want a resolution here, you'll
likely need to do that exploration yourself and try to narrow down the
source of the bug so that you can reproduce it with a simplest-case example.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/541AF60D.6020502%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Fwd: Django 1.7 polymorphism error

[Thiago Avelino]

Hi guys!

I think I found a error polymorphism in django 1.7, field slug exist in
_meta.fields and run filter return error "FieldError: Cannot resolve
keyword 'slug' into field. Choices".

Example: https://gist.github.com/avelino/793bdaf9f9732314912a


Slugged (abstract):
https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/core/models/core.py#L80

Article (abstract):
https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/abstracts/articles.py#L12

Post:
https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/types/posts.py#L8

Container:
https://github.com/opps/opps/blob/8e58a60c3cfea75b5cc4455d247a75b26f995b58/opps/containers/models/core.py#L29


class Container(Publishable, Channeling):
class Article(Container, Slugged, Tagged):
class Post(Article):

In Post not exist slug (on filtrer) and _meta.fields exist!


Cheers,
Thiago Avelino
@avelino0  - avelino.xxx

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