BCrypt + Python3

2013-05-10 Thread Donald Stufft
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/

-
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

2013-05-10 Thread Yo-Yo Ma
Wow, this is awesome! Thanks so much guys. Too long have I dreamt of the day 
when I could include tests for my "lib" and "util", etc. without having to 
couple them to one app or another. I'm so excited that this was added so 
quickly. 


Thanks
Yo-yo

-- 
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: Help with #20378 - Reverse join fails when GenericRelation is defined on an abstract model

2013-05-10 Thread Anssi Kääriäinen
On 9 touko, 19:28, Gavin Wahl  wrote:
> I'd like to have a go at fixing this bug, but I'm not sure where to start.
> The problem seems to be that there's only a single instance of the field
> per model, so field.model is always the abstract class. I can't see a way
> to access the concrete class from the field instance. If the field only has
> a reference to the abstract model, which doesn't have a pk, how can it
> calculate join columns for the concrete model?

It can't. The field's model should be the concrete model, but due to
buggy field setup it isn't.

I took a look at altering the way virtual fields are copied from
abstract model to concrete model, but didn't find any easy solution
there. I didn't use too much time investigating this path, so taking
one more look might yield something. Start from
django.db.models.base:ModelBase.__new__() and virtual_fields copying.
Try to somehow end up in a situation where the field's model is the
concrete model.

More likely the solution is going to be found by altering how
GenericRelations are seen by the ORM. Before #19385 GenericRelation
masqueraded as m2m field (which it isn't), now in master it is a
ForeignObject subclass. The basic problem is that generic relation
represents reverse join, while ForeignObject usually represents direct
join. Doing changes in this area is likely going to be somewhat
complex...

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

2013-05-10 Thread Carl Meyer
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: test discovery

2013-05-10 Thread Carl Meyer
On Thursday, May 9, 2013 8:15:02 PM UTC-4, Russell Keith-Magee wrote:

> On Thu, May 9, 2013 at 11:30 PM, Carl Meyer  > wrote:
>
>> Hi Russ,
>>
>> On 05/09/2013 04:51 AM, Russell Keith-Magee wrote:
>> > Great work Carl and Preston! (And everyone else who had a hand in the
>> > patch - I know this has been kicking around for a while now)
>>
>> Thanks for the reminder; I should have mentioned that Mahdi Yusuf did
>> the initial draft patch, based on Jannis' django-discover-runner, which
>> was based on code I showed on a slide in my "Django and Testing" talk at
>> PyCon 2012; it all comes full circle :-)
>>
>> > I agree with Jacob's tests aren't production sensitive, so making a fast
>> > transition to the new test discovery has less impact.
>> >
>> > However, we know from experience that it doesn't matter how much we flag
>> > this change in the release notes, they won't be read, and *someone* is
>> > going to get stung. In an ideal world, it would be good to be able to
>> > warn people who upgrade that their test suite may not be run as 
>> expected.
>> >
>> > We've had a proposal kicking around for a while to add a management
>> > command that does an "upgrade check". I'm wondering if this might be an
>> > opportune time to dig into this some more.
>> >
>> > To be clear, this isn't something I consider to be a merge blocker. I'd
>> > be happy to see 1.6 released with a fast transition to the new test
>> > runner. It would just be nice icing on the cake if we can get an upgrade
>> > validator included in the same release.
>>
>> It wouldn't be too hard to write something that tried test discovery
>> using the old runner and using the new runner and did a simple
>> comparison of test counts to warn you if they differ.
>>
>> I'm not personally likely to work on this "upgrade checks" framework,
>> but if it does happen I'd be happy to contribute this check to it.
>
>  
> I thought about that approach, but my immediate reaction was that it will 
> end up producing more false positives than helpful feedback. Even the 
> simple case -- myapp.TestCase -> myapp.tests.TestCase -- is going to 
> require some name munging to work out if the old test and the new test are 
> actually the same one. Since this is for a short-lived transitional tool, 
> the effort involved in getting it right exceeds the value gained by having 
> it, IMHO.
>

I wasn't anticipating trying to actually match up individual tests by 
name/path, just trying both runners and seeing whether the test counts 
match. On second thought, though, I realize that contrib / third-party apps 
will mean this check would alert "missing tests!" for pretty much everyone, 
so it would need to be smarter to be useful, and you're right that's likely 
not worth it.
 

> I'd prefer something much simpler:
>
>  * On syncdb/validate, check for a marker somewhere in user space. 
>
>  * If the marker isn't present, do a check for likely problems. In this 
> case, look for the value of TEST_RUNNER; if it's set to the new default 
> value, display a warning about the change in test discovery format. Add 
> similar checks for other setting changes, or warnings about features that 
> have been fully deprecated (e.g., the final transition of the {% url %} 
> behavior)
>
>  * Provide a management command to set marker. 
>
>  * On the next syncdb/validate, the marker is present, so the install is 
> verified as being "updated", and no warnings are displayed.
>
> This leaves the question of where to put the marker. Some initial ideas:
>
>  - a file on disk (e.g., an .updated file next to the settings file)
>  - a new setting (VERIFIED_VERSION = "1.5")
>  - a key-value table in a database used only for Django administrivia
>
> Essentially, this would give us a place to put the "NO REALLY, READ THIS" 
> warnings that we need in release notes, and make those messages slightly 
> targeted.
>

In theory this makes sense to me, but I think the question of where to put 
the "I already ran the upgrade check" marker is thorny. Database is ugly, 
since there's no requirement for a Django project to even use the ORM at 
all; and requiring projects using the ORM to have a magical extra 
not-related-to-a-voluntarily-installed-app table in their database sticks 
in my craw. Similar with adding a file to the filesystem; we'd essentially 
be requiring everyone to have this file in order to avoid the extra 
overhead (and possible noise) of the check on startup; forcing that type of 
cruft on everyone using Django is a non-starter in my book. Of those three 
ideas, I'd say a new setting has the least downside, but even that is extra 
cruft we're forcing into everyone's settings.py file.

I think perhaps better is simply an "upgradecheck" management command that 
does checks like this relative to the last version of Django. Of course, 
this has to be manually run, so it doesn't have the "catch everyone" 
benefit of something that happens automatically at validation, but if 

Re: Perception of attitude in tickets

2013-05-10 Thread Russell Keith-Magee
On Fri, May 10, 2013 at 11:45 PM, Simon  wrote:

> Hi.
>
> I'm a newcomer to both Python and Django and just wanted to share my
> experience trying to solve a couple of problems.
>
> When I started coding in Python a month ago, Django was sufficiently
> common in Google searches that it was my first port of call. I've found
> quite a few features which I love and a few which seem a little quirky.
>
> Unfortunately, every time I come across a problem, I seem to end up back
> at the ticket system which almost invariably results in lots of people
> saying "It's important to me" and a core developer saying (rather
> arbitrarily) "I don't see the need" and closing as wontfix.
>
> Of course, once the ticket has been closed, the only way to appeal is
> through the mailing lists. To myself as a newcomer, that just feels like a
> way of making further dissent less visible. I'm sure this isn't the case
> but that's certainly the feeling I got.
>

I'm sorry you've got this impression, but we do this to *increase*
visibility, not decrease it.

When you subscribe to the mailing list, you get *all* the messages. You get
to see *every* conversation. So if someone turns up and proposes a new
feature, everyone gets a chance to participate. However, If you post a
comment on a ticket, only the people who have posted to that ticket get
notified.

So lets say I'm a person with an interest in the behavior of Django models,
but without a specific interest in a reload behaviour. Any discussion on
ticket #901 would be completely invisible to me.

Or, lets say I *do* have an interest in reload behaviour, but I think of it
more as a "refresh" behaviour. I open a new ticket, it slips through the
triage process without being identified as a duplicate (which is
unfortunate, but very easy to do). We now have 2 difference discussions
about exactly the same thing, and neither discussion will know that the
other is happening.

So - the repeated advice to take the discussion to django-developers exists
for a very good reason, and we give that advice for the exact opposite
reason to what we've been accused of. We've been doing this for a while,
and the processes we've developed exist because of what we've learned. And
our processes are also documented:

https://docs.djangoproject.com/en/1.5/internals/contributing/bugs-and-features/

The most recent example, which prompted this post is
> https://code.djangoproject.com/ticket/901 but this is the 5th or 6th time
> I've ended up at similar tickets with similar outcomes. I think comment
> #20  demonstrates
> my point perfectly - While the point being made is valid, the tone and
> general attitude is poor to say the least.
>

As the author of that comment --  I wrote it out of abject frustration. I
saw three comments in a row, all declaring that Django was unresponsive to
user requests, when *not one person complaining has done the very simple
thing that the core team has asked them to do*. When Person A has a
problem, Person B provides a way to resolve the problem, and Person A
refuses to do what they've been asked to do, why is Person B wearing the
blame?

That said, it certainly wasn't my intention to offend with my comments, so
I apologise for my tone.

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

2013-05-10 Thread Luke Plant
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.




New Release of IBM_DB_DJANGO (1.0.5)

2013-05-10 Thread Rahul
IBM_DB_DJANGO-1.0.5
---
IBM_DB_DJANGO adaptor enables access to IBM databases from Django
applications http://www.djangoproject.com/. The adaptor is developed
and maintained by IBM.

What's New?

 - Added support for Django-1.5, with backward compatibilty
 - Added support for REGEX lookup
 - Added support for Python-3.x


GIT access to the source
---
http://code.google.com/p/ibm-db/source/browse/#git/IBM_DB/ibm_db_django/

Installation

$ easy_install ibm_db_django

Feedback/Suggestions/Issues

You can provide us feedback/suggestions, or report a bug/defect, or
ask for help by using any of the following channels:
1. Mailing us at open...@us.ibm.com
2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list.
3. By opening new discussion at http://groups.google.co.in/group/ibm_db.
For prerequisites, installation steps and help details, visit -
http://code.google.com/p/ibm-db/wiki/ibm_db_django_README
Try this out and let us know you valuable feedback.

Cheers,
Rahul Priyadarshi

Download Express-C for free, go to:
---
http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01_TACT=ACDB2011

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

2013-05-10 Thread Geoffrey S. Knauth
Andres, amen to most of what you said.  Coming to Django from a different place 
(Scala, Racket), I keep an eye for widely-used good things to come from those 
communities too.  I do like that a Django project found me for work.  I just 
wish I knew more Django!  --Geoff

On May 10, 2013, at 12:44 , Andres Osinski  wrote:

> I really don't know how you think you'll be getting a different response in 
> other frameworks, because the core developers' attitude on this is correct.
> 
> There are over 2 tickets in the bug tracker for a project used by tens of 
> thousands of people. Code has to pass style guidelines, regression tests, 
> documentation must be made, features must be integrated into a release 
> schedule, obscure platform bugs and overall consistency with the rest of the 
> code has to be verified.
> 
> This takes a *long* time. Adding an extra method to the Model class is 
> something that may take weeks to discuss and to consider in a myriad possible 
> aspects. And what's worse, someone after you will have to maintain the whole 
> thing, because retrospectively removing things is a *really bad* practice on 
> code that you don't own.
> 
> Discussions take place on the mailing list and chat rooms because bug 
> trackers are not and have never been a place to discuss design decisions or 
> implementation details; just a place to track the progress in the development 
> and status of a bug or feature request.
> 
> Finally, Django as a framework is *massive*, and really good reasons have to 
> be had in order to increment the line count even more for something that is 
> ostensibly a corner case for people who don't wish to do a bit of additional 
> work by working within the framework's constraints and opinions instead of 
> against them.
> 
> Unfortunately, given that no framework is as large or feature-complete 
> (Pyramid supports a lot of things, but is against including too much in the 
> core framework and instead depends on external libs), you'll have even *less* 
> luck with other pieces of code. And I would certainly distrust any framework 
> that has less rigor than Django for including features; what core devs 
> giveth, core devs may deprecate on the next release.
> 
> Also, I beleive your perception of Django's openness if flat-out erroneous. 
> Go try to add an unrequested feature in Rails or Yii without discussion and 
> see how you're welcomed, never mind the fact that both of these framework's 
> development is done completely in the dark for many of the most important 
> features.

-- 
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: Recommending a Python 3-compatible MySQL connector

2013-05-10 Thread Aymeric Augustin
Hi Luke,

Your blog post nails the problem. The GPL wasn't written with dynamic
languages in mind and "linking" is a big question mark. As far as I know,
it has never been tested in court, and we won't be sure of anything until
it is.

Of course I could be wrong… I'm just repeating what I've heard from
others whom I trust.

In fact I would just like to skip this debate entirely and the easiest way
to do that is to avoid the GPL :)


That said, in my experience, people releasing Python libraries under
the GPL fall in two categories:
- people unfamiliar with licensing trying to do the right thing (I've done
  that before!),
- people who don't want their code to be used in non-GPL apps (for
  whatever reason).

In general, the first category doesn't object to switching to LGPL, which
is recognized as safe for our purposes (as far as I know).

It's hard to have a rational discussion with the second category because
they tend to go on a FSF jihad as soon as you try discussing licensing
with them ;)

Asking to change the license to LGPL is a good first step for libraries
where LGPL is obviously more suitable than GPL. If the author argues
that GPL is more suitable, that tells us about his motivations, and we
can make a decision to use or not use the code.

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




Re: Perception of attitude in tickets

2013-05-10 Thread Aymeric Augustin
On 10 mai 2013, at 19:00, Simon  wrote:

> While I'm sure it's not the real reason, sending people to the mailing lists 
> feels like a way of brushing disagreement under the carpet.

If you read our contributing guide, you'll understand that it's the exact 
opposite.

If I wanted to drown an issue, I'd just let it sit there, and nothing would 
happen.

> There's no obvious way to follow on from the discussion in the ticket to the 
> relevant discussions in the mailing list (if any) and visitors coming by 
> years later now have to go and hunt through an archive to find out if there's 
> any chance of a change.

The mailing-list is on Google Groups, all you need is to paste a link to the 
discussion in a comment.

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

You don't bother reading (or acknowledging) the previous comments, you leave a 
passive-aggressive 2-lines comment, a committer takes the time to write 20 
lines in response, and your reaction is "shrug, just another rant"?

Step back and try looking at it from the other side.

Or, as an exercise, triage a few dozen tickets here:
https://code.djangoproject.com/query?status=!closed=Unreviewed=1=changetime
Just figure out what each ticket is about and:
- move it to "Accepted", or
- close it as "needsinfo" or "invalid",
with a comment explaining your decision.

Once you've done, say, 25 tickets, read Russell's answer again, and remember he 
triaged several thousand tickets over the history of Django. Maybe you'll 
understand his perspective better.

At worst, you'll have helped us a bit :)

> Some other tickets I've ended up on have proposed patches and seem to have 
> sat in "Design decision" for years, which again gives the impression that the 
> core team didn't like it so just sort of ignored it until it went away.

And that's why we eliminated DDN a few weeks ago.

I personally made a decision on several hundred tickets. I'm not asking for 
anything in return. Please just don't imply the core team is slacking. Such 
feedback is clearly pushing me towards spending less time on Django and more 
with my family.

> So, to be honest, the impression I'm getting WRT new features in Django is 
> "Don't bother proposing it 'cos it's not going to happen".

Indeed "I would like a pony" doesn't work. Building trust with the developers, 
discussing alternatives with their advantages and drawbacks, proposing patches, 
and avoiding snarky comments works much better.

> I'm unlikely to use Django moving forward. There are a number of reasons and 
> I'd be lying if I said this was the biggest but it was a factor in my 
> decision.

Thanks for sharing your experience. I hope you'll find a friendlier community.

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




Re: Perception of attitude in tickets

2013-05-10 Thread Andres Osinski
I really don't know how you think you'll be getting a different response in
other frameworks, because the core developers' attitude on this is correct.

There are over 2 tickets in the bug tracker for a project used by tens
of thousands of people. Code has to pass style guidelines, regression
tests, documentation must be made, features must be integrated into a
release schedule, obscure platform bugs and overall consistency with the
rest of the code has to be verified.

This takes a *long* time. Adding an extra method to the Model class is
something that may take weeks to discuss and to consider in a myriad
possible aspects. And what's worse, someone after you will have to maintain
the whole thing, because retrospectively removing things is a *really bad*
practice on code that you don't own.

Discussions take place on the mailing list and chat rooms because bug
trackers are not and have never been a place to discuss design decisions or
implementation details; just a place to track the progress in the
development and status of a bug or feature request.

Finally, Django as a framework is *massive*, and really good reasons have
to be had in order to increment the line count even more for something that
is ostensibly a corner case for people who don't wish to do a bit of
additional work by working within the framework's constraints and opinions
instead of against them.

Unfortunately, given that no framework is as large or feature-complete
(Pyramid supports a lot of things, but is against including too much in the
core framework and instead depends on external libs), you'll have even
*less* luck with other pieces of code. And I would certainly distrust any
framework that has less rigor than Django for including features; what core
devs giveth, core devs may deprecate on the next release.

Also, I beleive your perception of Django's openness if flat-out erroneous.
Go try to add an unrequested feature in Rails or Yii without discussion and
see how you're welcomed, never mind the fact that both of these framework's
development is done completely in the dark for many of the most important
features.


On Fri, May 10, 2013 at 12:45 PM, Simon  wrote:

> Hi.
>
> I'm a newcomer to both Python and Django and just wanted to share my
> experience trying to solve a couple of problems.
>
> When I started coding in Python a month ago, Django was sufficiently
> common in Google searches that it was my first port of call. I've found
> quite a few features which I love and a few which seem a little quirky.
>
> Unfortunately, every time I come across a problem, I seem to end up back
> at the ticket system which almost invariably results in lots of people
> saying "It's important to me" and a core developer saying (rather
> arbitrarily) "I don't see the need" and closing as wontfix.
>
> Of course, once the ticket has been closed, the only way to appeal is
> through the mailing lists. To myself as a newcomer, that just feels like a
> way of making further dissent less visible. I'm sure this isn't the case
> but that's certainly the feeling I got.
>
> The most recent example, which prompted this post is
> https://code.djangoproject.com/ticket/901 but this is the 5th or 6th time
> I've ended up at similar tickets with similar outcomes. I think comment
> #20  demonstrates
> my point perfectly - While the point being made is valid, the tone and
> general attitude is poor to say the least.
>
> In any case, I shall be moving away from Django before I get too tied to
> it. I know this won't impact you in the slightest but I suspect other
> newcomers will be doing the same and not taking the time to post.
>
> All the best
>
>  --
> 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.
>
>
>



-- 
Andrés Osinski
http://www.andresosinski.com.ar/

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

2013-05-10 Thread Donald Stufft

On May 10, 2013, at 1:00 PM, Simon  wrote:

> Hi,
> 
> When I started using Python a couple of months ago, a quick Google for 
> frameworks turned up a lot of results for Django so I decided to give it a 
> spin.
> 
> I'd like to give some feedback on my experience to date. There are a lot of 
> features I really love, some that are a little quirky and some that are 
> downright inflexible. None of this will be news - it's the same for every 
> framework. That said, I started to have doubts when I was attempting to find 
> solutions/workarounds to the problems I encountered.
> 
> Today was the 5th or 6th time that I've ended up at the ticket system and 
> seen people saying "This would really help me" and a core developer saying "I 
> don't see the need" (rather arbitrarily IMHO) and closing as wontfix. This is 
> invariably followed by people asking for reconsideration which in turn gets a 
> "use the mailing list" with varying degrees of rudeness.
> 
> While I'm sure it's not the real reason, sending people to the mailing lists 
> feels like a way of brushing disagreement under the carpet. There's no 
> obvious way to follow on from the discussion in the ticket to the relevant 
> discussions in the mailing list (if any) and visitors coming by years later 
> now have to go and hunt through an archive to find out if there's any chance 
> of a change.

It's actually the opposite. More people read and participate on the mailing 
list than on the ticket tracker. So posting to the mailing list is actually a 
good way to get _more_ people to see your issue.

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

There was no progress because no one was willing to champion the feature on the 
mailing list.

> 
> Some other tickets I've ended up on have proposed patches and seem to have 
> sat in "Design decision" for years, which again gives the impression that the 
> core team didn't like it so just sort of ignored it until it went away.

If I recall DDN was recently gotten rid of for exactly this problem. It wasn't 
clear who had the right to make said design decision and it often languished 
waiting for Jacob to have time to make a decision.

> 
> So, to be honest, the impression I'm getting WRT new features in Django is 
> "Don't bother proposing it 'cos it's not going to happen".

Proposing features is fine and is useful. However there are a massive number of 
features and bugs that people can work on. You're right in that if you're just 
tossing ideas out there it's unlikely that they will get added because for each 
new feature you need someone willing to do the work to discuss it, champion it, 
and implement it. If these features are important to you then engage the 
process and help shape Django.

> 
> There are StackOverflow questions (another) on the topic and numerous other 
> sources pointing at this particular ticket wondering why it hasn't been 
> implemented. The only reason I can see is that "jacob" wasn't convinced by 
> the (first) use case.

That's why the ticket wasn't accepted immediately. It hasn't gotten past that 
because no ones stepped up to advocate for the feature.

> 
> Now, I admit that I'm probably seeing the worst side of the problem, there 
> are probably hundreds of other features which did get in (which is why 
> there's documentation not tickets for me to find) but that doesn't make the 
> situation I'm seeing better, just smaller.
> 
> Perhaps the fact that people keep posting on closed tickets shows that the 
> current flow to the mailing lists isn't a good one? Maybe either add a "Start 
> a topic about this ticket" link or maybe even just allow discussion to 
> continue on the ticket as many others do?

While using tickets is fine if the project tends to do so but Django does not. 
So a lot of people simply don't pay attention to the ticket tracker while far 
more people are involved in the mailing list.

> 
> I'm unlikely to use Django moving forward. There are a number of reasons and 
> I'd be lying if I said this was the biggest but it was a factor in my 
> decision.
> 
> Anyway, I wanted to take a few minutes and share the impressions I've had to 
> date - perhaps this way, others will have a better experience in future.
> 
> Thanks for reading
> 
> Simon
> 
> -- 
> 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: Perception of attitude in tickets

2013-05-10 Thread Simon
Apologies Daniele, I hadn't realised that had actually posted before I 
finished editing. I've now posted the final verison

On Friday, May 10, 2013 5:57:43 PM UTC+1, Daniele Procida wrote:
>
> On Fri, May 10, 2013, Simon  wrote: 
>
> >Of course, once the ticket has been closed, the only way to appeal is 
> >through the mailing lists. To myself as a newcomer, that just feels like 
> a 
> >way of making further dissent less visible. I'm sure this isn't the case 
> >but that's certainly the feeling I got. 
>
> Surely the process should begin, not end, with the email list? Or better 
> still sometimes, #django-developers on irc.freenode.net. 
>
> Daniele 
>
>

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




Perception of attitude in tickets

2013-05-10 Thread Simon
Hi,

When I started using Python a couple of months ago, a quick Google for 
frameworks turned up a lot of results for Django so I decided to give it a 
spin.

I'd like to give some feedback on my experience to date. There are a lot of 
features I really love, some that are a little quirky and some that are 
downright inflexible. None of this will be news - it's the same for every 
framework. That said, I started to have doubts when I was attempting to 
find solutions/workarounds to the problems I encountered.

Today was the 5th or 6th time that I've ended up at the ticket system and 
seen people saying "This would really help me" and a core developer saying 
"I don't see the need" (rather arbitrarily IMHO) and closing as wontfix. 
This is invariably followed by people asking for reconsideration which in 
turn gets a "use the mailing list" with varying degrees of rudeness.

While I'm sure it's not the real reason, sending people to the mailing 
lists feels like a way of brushing disagreement under the carpet. There's 
no obvious way to follow on from the discussion in the ticket to the 
relevant discussions in the mailing list (if any) and visitors coming by 
years later now have to go and hunt through an archive to find out if 
there's any chance of a change.

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. 

Some other tickets I've ended up on have proposed patches and seem to have 
sat in "Design decision" for years, which again gives the impression that 
the core team didn't like it so just sort of ignored it until it went away.

So, to be honest, the impression I'm getting WRT new features in Django is 
"Don't bother proposing it 'cos it's not going to happen".

There are 
StackOverflow
 
questions
 
(another)
 on 
the topic and numerous other sources pointing at this particular ticket 
wondering why it hasn't been implemented. The only reason I can see is that 
"jacob" wasn't convinced by the (first) use case.

Now, I admit that I'm probably seeing the worst side of the problem, there 
are probably hundreds of other features which did get in (which is why 
there's documentation not tickets for me to find) but that doesn't make the 
situation I'm seeing better, just smaller.

Perhaps the fact that people keep posting on closed tickets shows that the 
current flow to the mailing lists isn't a good one? Maybe either add a 
"Start a topic about this ticket" link or maybe even just allow discussion 
to continue on the ticket as many others do?

I'm unlikely to use Django moving forward. There are a number of reasons 
and I'd be lying if I said this was the biggest but it was a factor in my 
decision.

Anyway, I wanted to take a few minutes and share the impressions I've had 
to date - perhaps this way, others will have a better experience in future.

Thanks for reading

Simon

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

2013-05-10 Thread Daniele Procida
On Fri, May 10, 2013, Simon  wrote:

>Of course, once the ticket has been closed, the only way to appeal is 
>through the mailing lists. To myself as a newcomer, that just feels like a 
>way of making further dissent less visible. I'm sure this isn't the case 
>but that's certainly the feeling I got.

Surely the process should begin, not end, with the email list? Or better still 
sometimes, #django-developers on irc.freenode.net.

Daniele

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




Perception of attitude in tickets

2013-05-10 Thread Simon
Hi.

I'm a newcomer to both Python and Django and just wanted to share my 
experience trying to solve a couple of problems.

When I started coding in Python a month ago, Django was sufficiently common 
in Google searches that it was my first port of call. I've found quite a 
few features which I love and a few which seem a little quirky.

Unfortunately, every time I come across a problem, I seem to end up back at 
the ticket system which almost invariably results in lots of people saying 
"It's important to me" and a core developer saying (rather arbitrarily) "I 
don't see the need" and closing as wontfix.

Of course, once the ticket has been closed, the only way to appeal is 
through the mailing lists. To myself as a newcomer, that just feels like a 
way of making further dissent less visible. I'm sure this isn't the case 
but that's certainly the feeling I got.

The most recent example, which prompted this post is 
https://code.djangoproject.com/ticket/901 but this is the 5th or 6th time 
I've ended up at similar tickets with similar outcomes. I think comment 
#20 demonstrates 
my point perfectly - While the point being made is valid, the tone and 
general attitude is poor to say the least.

In any case, I shall be moving away from Django before I get too tied to 
it. I know this won't impact you in the slightest but I suspect other 
newcomers will be doing the same and not taking the time to post.

All the best

-- 
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: Recommending a Python 3-compatible MySQL connector

2013-05-10 Thread Donald Stufft

On May 10, 2013, at 11:49 AM, Luke Plant  wrote:

> On 10/05/13 14:12, Aymeric Augustin wrote:
>> Hi Mark,
>> 
>> On 10 mai 2013, at 10:16, Mark Hughes  wrote:
>>> Another option to consider could be mysql-connector-python
>>> 
>>> https://pypi.python.org/pypi/mysql-connector-python/1.0.9
>> 
>> Thank you, it's the official library I was missing!
>> 
>> Unfortunately, it's licensed under the GPL. To the best of my
>> understanding, importing modules in the same Python process triggers
>> GPL contamination. Therefore, if Django officially supports this
>> module, anyone distributing code that works with Django should either
>> release it under the GPL or specify that it's illegal to use it with
>> MySQL.
> 
> Can the GPL really do this? My own thoughts on this are here:
> 
> http://lukeplant.me.uk/blog/posts/python-and-copyright/
> 
> I'm not saying that we should use GPL code if there is BSD alternative,
> but as far as I can see, it's impossible for the GPL to say *anything*
> in this situation, because there is nothing a typical Django project
> would be doing with that library that would actually require them to
> accept the terms of the license.
> 
> The GPL allows *using* of the code for any purpose. It's only when a
> project becomes a distributor of the GPL code that it is required to
> abide by the other terms.
> 

http://jacobian.org/writing/gpl-questions/

In particular look at VanL's responses.


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



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Recommending a Python 3-compatible MySQL connector

2013-05-10 Thread Luke Plant
On 10/05/13 14:12, Aymeric Augustin wrote:
> Hi Mark,
> 
> On 10 mai 2013, at 10:16, Mark Hughes  wrote:
>> Another option to consider could be mysql-connector-python
>> 
>> https://pypi.python.org/pypi/mysql-connector-python/1.0.9
> 
> Thank you, it's the official library I was missing!
> 
> Unfortunately, it's licensed under the GPL. To the best of my
> understanding, importing modules in the same Python process triggers
> GPL contamination. Therefore, if Django officially supports this
> module, anyone distributing code that works with Django should either
> release it under the GPL or specify that it's illegal to use it with
> MySQL.

Can the GPL really do this? My own thoughts on this are here:

http://lukeplant.me.uk/blog/posts/python-and-copyright/

I'm not saying that we should use GPL code if there is BSD alternative,
but as far as I can see, it's impossible for the GPL to say *anything*
in this situation, because there is nothing a typical Django project
would be doing with that library that would actually require them to
accept the terms of the license.

The GPL allows *using* of the code for any purpose. It's only when a
project becomes a distributor of the GPL code that it is required to
abide by the other terms.

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.




Re: Recommending a Python 3-compatible MySQL connector

2013-05-10 Thread Aymeric Augustin
Hi Mark,

On 10 mai 2013, at 10:16, Mark Hughes  wrote:
> Another option to consider could be mysql-connector-python
> 
> https://pypi.python.org/pypi/mysql-connector-python/1.0.9

Thank you, it's the official library I was missing!

Unfortunately, it's licensed under the GPL. To the best of my understanding, 
importing modules in the same Python process triggers GPL contamination. 
Therefore, if Django officially supports this module, anyone distributing code 
that works with Django should either release it under the GPL or specify that 
it's illegal to use it with MySQL.

The Django project favors the BSD license to avoid inflicting such questions to 
its community. I'm afraid we won't compromise for such a central piece as a 
database backend.

(NB: Oracle's "FOSS License Exception" doesn't cover this case; it only allows 
the Django Software Foundation to bundle the MySQL client libraries in Django, 
if we wanted to.)

> Also actively developed by @geertjanvdk at Oracle so he may be able to
> help with any issues?


If he has the power to switch to a license that makes it possible to use his 
code, like the LGPL, that would be fantastic. I can't tell if he chose the GPL 
to make a point or by accident; I'm going to ask him.

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




Re: Recommending a Python 3-compatible MySQL connector

2013-05-10 Thread Mark Hughes
On 5 May 2013 19:17, Aymeric Augustin
 wrote:
>
> To claim first-class Python 3 support in Django 1.6, we need to recommend a 
> MySQL connector that works. This was discussed a few times on the mailing 
> list, now's the time to make a decision. Here's a summary of the options.
>

Another option to consider could be mysql-connector-python

https://pypi.python.org/pypi/mysql-connector-python/1.0.9

It claims to support Python 2 and 3

http://dev.mysql.com/doc/refman/5.5/en/connector-python-versions.html

Also actively developed by @geertjanvdk at Oracle so he may be able to
help with any issues?

Mark.

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